国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

問答專欄Q & A COLUMN

想用MongoDB取代MySQL可以嗎?

Kerr1GanKerr1Gan 回答0 收藏2
問題描述:有可能會出現哪些問題?
收藏問題

10條回答

hatlonely

hatlonely

回答于2022-06-28 16:03

已采納

謝謝邀請。


我現在帶的項目用到了MongoDB,本人對MongoDB也有一定的了解,下面我談談自己的看法。

先一句話概括:MongoDB和MySQL(關系型數據庫)各有特點,它們適合的場景不同;而企業(yè)級應用的大部分場景,MongoDB是無法完全取代MySQL的。


MongoDB是什么

在分析這個問題之前,我們還是看看MongoDB的定義:MongoDB是一個數據庫;再稍微詳細一點兒,它是一個開源的、基于分布式文件存儲的、非關系型數據庫。

說到非關系型數據庫,最有名的可能就是Redis了,它是一種Key-Value類型的數據庫;而MongoDB,它是文檔型數據庫的一種,它的存儲方式類似于JSON。


MongoDB的特性

MongoDB更多適用于大數據量、高并發(fā)、弱事務、不確定數據類型的應用;特別是這里的“不確定數據類型”,也是MongoDB最大的特點之一。

大家在用關系型數據庫的時候,如果表中的數據量很大,想要給表添加一個字段,是一件很痛苦的事情;而MongoDB是無需事先創(chuàng)建表結構或修改表結構,所有的改變都是動態(tài)的。


MongoDB能否取代MySQL(關系型數據庫)?

MongoDB不適用于高度事務性的系統(tǒng),如果系統(tǒng)對數據的事務性要求很高,還是用關系型數據庫比較合適。(MongoDB3.6對單集合的事務支持不錯,據說4.0之后,對多集合的事務支持也可以,不過我沒有深入研究過)

MongoDB的多集合關聯也沒有關系型數據庫強大,不過MongoDB更擅長把幾個表的信息,放在一個集合里面。


所以總結來說,關系型數據庫和MongoDB是不存在誰替代誰的問題,他們應該是各有優(yōu)勢,相互補充的。就好像我們平時用的無線鍵盤和機械鍵盤一樣,無線鍵盤靈活輕便、外觀比較時尚,而機械鍵盤手感出色、跪著舒服,不傷膝蓋,各有優(yōu)勢。


希望我的回答,能夠幫助到你!我將持續(xù)分享Java開發(fā)、架構設計、職業(yè)發(fā)展等方面的見解,希望能得到你的關注;另外,關注我后私信【資料】兩個字,可獲取架構、大數據、面試等相關資料。

評論0 贊同4
  •  加載中...
why_rookie

why_rookie

回答于2022-06-28 16:03

Mongodb作為最靠近關系數據庫的Nosql存儲,取代MySQL可以嗎?

從功能角度看,是可以取代的。

關系數據庫應該有的核心功能它都有了:B樹索引,事務(4.0)。

一些比較重要的小更新,比如Decimal128(3.4)的添加都讓它的功能更加完善。

你在Mysql里面用的復雜查詢基本上都可以用管道或者MapReduce實現。

我在好幾個項目中完全使用的Mongodb,經驗如下:

* 關聯查詢麻煩,所以Mongodb在設計模型的時候傾向于數據都內聯,配合少量的In 查詢。這樣也會導致數據冗余后一致性更新的問題。

* 設計動態(tài)表格時,Mongodb的體驗時非常好的。

* 4.0之前的沒有事務,碰到金錢相關的服務,需要自己在服務中構造事務環(huán)境,否則一旦失敗無法回滾。這也會造成這塊代碼膨脹。

* 編寫復雜腳本查詢數據庫時,編寫腳本或者服務時難度更大,更花時間。統(tǒng)計服務較多的時候,更加傷腦子。

* 由于協(xié)議設計的原因,命令太多,導致不常用命令的需要經常查詢文檔。

推薦使用Mongodb的場合:

* 在Demo期間使用Mongodb做數據存儲。

* 處于前期的互聯網產品,適應快速迭代。

* 配合MySql使用,完成一些動態(tài)數據處理的功能。不用設計冗余列,輕松構建查詢的感覺就是好。

* 作為一些熱數據或者中間數據(比如統(tǒng)計需要的中間表)的緩存使用。

Mongdob的官方文檔很完善,你要使用,建議把文檔瀏覽一遍。尤其是聚合管道查詢,花點時間好好理解,這個是你寫復雜查詢的基礎。


復雜的業(yè)務系統(tǒng),盡量避免,它會影響你的開發(fā)效率。


再補充幾點:

客戶端工具可以使用navicate或者NoSql manager,推薦使用navicate,順手。

如果服務端不是nodejs之類的動態(tài)語言服務,最好寫一些命令的擴展,驅動在表達式轉換方面做得還不夠。

評論0 贊同0
  •  加載中...
Drinkey

Drinkey

回答于2022-06-28 16:03

脫離業(yè)務場景,空談技術架構都是耍流氓。

我們公司同一個項目就同時在用Mysql和MongoDB,希望通過下面介紹可以幫助你真正了解到Mysql和MongoDB優(yōu)劣對比及實際業(yè)務應用場景。

數據庫人氣排行

以下來自最新的db-engines的數據庫人氣排行榜


接下來我們看一下前十名的趨勢變化圖:


關系數據庫前10名如下:


文檔數據庫前10名如下:


通過上面可以看出MongoDB雖說分數一直保持著穩(wěn)定上升的趨勢,但和 Mysql相比依然有一定的差距。不過,MongoDB 在2018年的表現是非常不錯的,至少一直都在進步,這個表現也是 MongoDB 獨一份。

數據結構

MySQL:MySQL將數據存儲在表中,并使用結構化查詢語言(SQL)訪問數據。MySQL使用模式來定義數據庫結構,要求表中的所有行具有相同的結構,并且值由特定的數據類型表示。

MongoDB:在MongoDB中,數據存儲在類似JSON的文檔中,這些文檔可以有不同的結構。為了提高查詢速度,MongoDB可以將相關數據存儲在一起,這些數據可以使用MongoDB查詢語言訪問。

在MongoDB中,文檔能夠擁有自己獨特的結構。新字段可以隨時添加并包含任何類型的值。

優(yōu)缺點

MySQL是關系型數據庫。

優(yōu)勢:

在不同的引擎上有不同的存儲方式。

查詢語句是使用傳統(tǒng)的sql語句,擁有較為成熟的體系,成熟度很高。

開源數據庫的份額在不斷增加,mysql的份額頁在持續(xù)增長。

缺點:

在海量數據處理的時候效率會顯著變慢。


Mongodb是非關系型數據庫(nosql ),屬于文檔型數據庫。

存儲方式:虛擬內存+持久化。

查詢語句:是獨特的Mongodb的查詢方式。

適合場景:事件的記錄,內容管理或者博客平臺等等。

架構特點:可以通過副本集,以及分片來實現高可用。

數據處理:數據是存儲在硬盤上的,只不過需要經常讀取的數據會被加載到內存中,將數據存儲在物理內存中,從而達到高速讀寫。

成熟度與廣泛度:新興數據庫,成熟度較低,Nosql數據庫中最為接近關系型數據庫,比較完善的DB之一,適用人群不斷在增長。

優(yōu)點:

快速!在適量級的內存的Mongodb的性能是非常迅速的,它將熱數據存儲在物理內存中,使得熱數據的讀寫變得十分快。高擴展性,存儲的數據格式是json格式!

缺點:

事務關系支持薄弱。這也是所有NoSQL數據庫共同的缺陷,不過NoSQL并不是為了事務關系而設計的,具體應用還是根據需求。而且開發(fā)文檔不是很完全、完善。

應用場景

關系型數據庫適合存儲結構化數據,如用戶的帳號、地址

1)這些數據通常需要做結構化查詢,比如join,這時候,關系型數據庫就要勝出一籌

2)這些數據的規(guī)模、增長的速度通常是可以預期的

3)事務性、一致性

NoSQL適合存儲非結構化數據,如文章、評論:

1)這些數據通常用于模糊處理,如全文搜索、機器學習

2)這些數據是海量的,而且增長的速度是難以預期的,

3)根據數據的特點,NoSQL數據庫通常具有無限(至少接近)伸縮性

4)按key獲取數據效率很高,但是對join或其他結構化查詢的支持就比較差


什么場景MongoDB更適用

更高的寫入負載

默認情況下,MongoDB更側重高數據寫入性能,而非事務安全,MongoDB很適合業(yè)務系統(tǒng)中有大量“低價值”數據的場景。但是應當避免在高事務安全性的系統(tǒng)中使用MongoDB,除非能從架構設計上保證事務安全。

高可用性

MongoDB的復副集(Master-Slave)配置非常簡潔方便,此外,MongoDB可以快速響應的處理單節(jié)點故障,自動、安全的完成故障轉移。這些特性使得MongoDB能在一個相對不穩(wěn)定(如云主機)的環(huán)境中,保持高可用性。

數據量很大或者未來會變得很大

依賴數據庫(MySQL)自身的特性,完成數據的擴展是較困難的事,在MySQL中,當一個單達表到5-10GB時會出現明顯的性能降級,此時需要通過數據的水平和垂直拆分、庫的拆分完成擴展,使用MySQL通常需要借助驅動層或代理層完成這類需求。而MongoDB內建了多種數據分片的特性,可以很好的適應大數據量的需求。

基于位置的數據查詢

MongoDB支持二維空間索引,因此可以快速及精確的從指定位置獲取數據。

表結構不明確,且數據在不斷變大

在一些傳統(tǒng)RDBMS中,增加一個字段會鎖住整個數據庫/表,或者在執(zhí)行一個重負載的請求時會明顯造成其它請求的性能降級。通常發(fā)生在數據表大于1G的時候(當大于1TB時更甚)。 因MongoDB是文檔型數據庫,為非結構貨的文檔增加一個新字段是很快速的操作,并且不會影響到已有數據。另外一個好處當業(yè)務數據發(fā)生變化時,是將不在需要由DBA修改表結構。

沒有DBA支持

如果沒有專職的DBA,并且準備不使用標準的關系型思想(結構化、連接等)來處理數據,那么MongoDB將會是你的首選。MongoDB對于對像數據的存儲非常方便,類可以直接序列化成JSON存儲到MongoDB中。 但是需要先了解一些最佳實踐,避免當數據變大后,由于文檔設計問題而造成的性能缺陷。

實際業(yè)務應用

BillRun – 基于MongoDB的帳單系統(tǒng) (來自oc666)

BillRun是由Ofer Cohen推出開源賬單系統(tǒng),采用MongoDB做為數據存儲。這套賬單系統(tǒng)被以色列一家增速最快的電信運營商采用,每月處理5億條通信記錄,Ofer在Slideshare上說明了具體利到了MongoDB的哪些特性:

弱數據結構的特點,使得BillRun能很快的支持新的CDR(通訊記錄)類型。這個特性使文檔型數據庫很適用于快速發(fā)展、業(yè)務需求不確定的系統(tǒng)中。

BillRun僅使用了一個Collection,已經管理了數TB的文檔數據,并且沒有遇到由結構變更、數據爆發(fā)式增長的帶來的限制和問題

replicaSet副本集特性使建立更多的數據中心DRP變得更輕松。

內建的Sharding分片特性避免系統(tǒng)在數據增長的過程中遇到性能瓶頸。

每秒鐘2000條通信記錄的插入,MongoDB在架構設計上很好的支持了高負載的數據寫入。并且可以使用findAndModify(相對緩慢)完成基礎的事務特性,并且通過應用層面的支持,實現雙段式提交。

查詢方式相比SQL,更加易讀、易懂,開發(fā)相對輕松。

基于位置允許更好的分析用戶使用情況,從而更好地制定移動電話基礎設施的投入點。


以上,如果對你有幫助幫忙點個贊吧

專注于Java領域優(yōu)質技術號,歡迎關注

評論0 贊同0
  •  加載中...
boredream

boredream

回答于2022-06-28 16:03

粘貼那么多介紹干嘛,一句話:不同業(yè)務場景,選用就不一樣。mysql針對業(yè)務結構復雜的用,mongodb反之。兩者結合,mongodb可以拿來做高級緩存或者提供查詢性能來存儲。mysql就出來業(yè)務結構復雜的數據存儲,還有事務回滾。mongodb是沒有事務回滾的

評論0 贊同0
  •  加載中...
zzzmh

zzzmh

回答于2022-06-28 16:03

完全取代是必然的,只是一個時間問題,關系型數據庫或者說所有基于二維數據表的數據庫都應該被淘汰了。

淺而易見的道理,二維數據表能做的哈希數據集(姑且稱之為三維數據集)都能做到,可以說后者包含前者,而如果要反過來那就不是那么簡單了,需要多個二維數據表才能實現一個哈希樹形數據集的目標。

二維表中為了多表關系導致大量字段數據重復,開發(fā)模塊的邏輯層進行數據對象組織所需要的轉換變得繁鎖,設計毫無低技術含量又臃腫,高開銷低效率,不參與檢索的大量字段暴露在頂層數據中顯得無趣又無意義。

而這些二維表罄竹難書的缺點,哈希樹形數據結構的NoSQL數據集數據庫具備先天性的優(yōu)勢。

MongoDB4.0以后,事物問題被徹底解決,實在找不出還要舍Mongodb而抱MySql的理由,其次MySql被甲骨文收購之后,前途未卜,畢竟它們還是要靠Oracle賺錢的。

評論0 贊同0
  •  加載中...
Allen

Allen

回答于2022-06-28 16:03

就好像再問,戰(zhàn)斗力可以替換為民航客機么?

評論0 贊同0
  •  加載中...
3fuyu

3fuyu

回答于2022-06-28 16:03

MongoDB作為新一代的數據庫平臺,具備了智能操作數據平臺的特點:

1、易于開發(fā),上手快,開發(fā)效率快;

2、天生的高可用性(副本集),天生的可擴展性(分片技術)滿足企業(yè)級的需求;

3、隨處部署的能力,可以和云技術、容器技術深度集成,符合當前devops、微服務等技術發(fā)展趨勢。


正是因為上述原因,很多應用都已經或者正在考慮使用MongoDB替代MySQL。特別是在MongoDB 4.0之后,應用使用MongoDB替代MySQL順利成章,主要原因是:

1. MongoDB 4.0 提供了多文檔事務,支持完整的ACID操作

2. MongoDB 4.0 優(yōu)化了副本集的從節(jié)點的讀能力,從性能上更好的支撐分析型應用;

3. MongoDB 4.0 優(yōu)化了聚合框架,從功能上更好的支撐分析型應用


誠然,在使用MongoDB替代MySQL過程中也會有一些挑戰(zhàn),這些挑戰(zhàn)從個人的經驗來看主要集中在:

1. 對MongoDB的“反范式”建模理解不夠;“反范式”建模作為一種創(chuàng)新的建模方式,以應用使用數據為導向,而不是過去以“實體”和“關系”為導向;

2. 對現有的基于MySQL的應用的數據遷移到MongoDB。這種數據遷移中挑戰(zhàn)比較大的地方在于如何實現實時遷移,MongoDB 3.6的Change Stream可以幫助實現數據實時遷移。


上述是個人的一些理解,供參考指正!

評論0 贊同0
  •  加載中...
pepperwang

pepperwang

回答于2022-06-28 16:03

自己也是程序員,分享一些觀點給你,其實不管是MongoDB還是Mysql,它們都是用來存儲數據用的,只不過存儲數據的方式不同,MySQL主要用于存儲關系類的數據,而MongoDB主要用于存儲鍵值類的數據,也就是我們常說的NOSQL,曾經一段時間,NOSQL是很多中小互聯網公司追求的東西。

那么既然都是存儲數據用的,那么肯定也可以相互替換,但是一個重要的問題就是,怎么樣將MongoDB里面的數據存儲到MySQL里面或者相反方向有怎么存儲?這才是整個業(yè)務代碼非常復雜的實現部分,比如你要將MySQL的數據存儲到MongoDB里面去,那么你需要做的事情就是理清MySQL數據表里面的各種關系,然后將這些關系轉換為鍵值對存儲到MongoDB里面去,想象一下這個工作量我們就應該知道,不是那么的簡單,尤其是數據表非常多,并且數據表關系非常復雜的時候,這項遷移工程是需要后端程序員、數據庫DBA、運維人員等等一起才能夠完成的事情。

所以得出結論,雖然兩種數據庫可以相互替換,但是替換的成本非常高,很多企業(yè)是不會這樣做的,除非現在項目性能已經嚴重影響到目標用戶。

評論0 贊同0
  •  加載中...
Martin91

Martin91

回答于2022-06-28 16:03

其實每個產品都有其特長的短板,可能會在一定程度上存在功能重復,但不可能完全取代。舉個不太恰當的例子來說:貓和狗都可以當寵物,貓能取代狗嗎?答案肯定是不能。但作為寵物,兩者確實都能做到惹人喜愛,也都能在主人寂寞或無聊的時候陪伴主人,作為寵物,它們甚至有更多相同的作用,但兩者永遠無法取代對方。不得不說在這個技術類產品滿天飛的時代,總有些對技術不深入了解的人或企業(yè)做著用貓來取代狗的白日夢,希望大家保持對技術的敬畏之心,可以大膽假設,但要謹慎求證,最終作出正確的選擇。

評論0 贊同0
  •  加載中...
fantix

fantix

回答于2022-06-28 16:03

看業(yè)務場景,沒有必要非a既b

評論0 贊同0
  •  加載中...

相關問題

最新活動

您已邀請0人回答 查看邀請

我的邀請列表

  • 擅長該話題
  • 回答過該話題
  • 我關注的人
向幫助了您的網友說句感謝的話吧!
付費偷看金額在0.1-10元之間
<