柯----
我現在帶的項目用到了MongoDB,本人對MongoDB也有一定的瞭解,下面我談談自己的看法。
先一句話概括:MongoDB和MySQL(關係型數據庫)各有特點,它們適合的場景不同;而企業級應用的大部分場景,MongoDB是無法完全取代MySQL的。
MongoDB是什麼
在分析這個問題之前,我們還是看看MongoDB的定義:MongoDB是一個數據庫;再稍微詳細一點兒,它是一個開源的、基於分佈式文件存儲的、非關係型數據庫。
說到非關係型數據庫,最有名的可能就是Redis了,它是一種Key-Value類型的數據庫;而MongoDB,它是文檔型數據庫的一種,它的存儲方式類似於JSON。
MongoDB的特性
MongoDB更多適用於大數據量、高併發、弱事務、不確定數據類型的應用;特別是這裡的“不確定數據類型”,也是MongoDB最大的特點之一。
大家在用關係型數據庫的時候,如果表中的數據量很大,想要給表添加一個字段,是一件很痛苦的事情;而MongoDB是無需事先創建表結構或修改表結構,所有的改變都是動態的。
MongoDB能否取代MySQL(關係型數據庫)?
MongoDB不適用於高度事務性的系統,如果系統對數據的事務性要求很高,還是用關係型數據庫比較合適。(MongoDB3.6對單集合的事務支持不錯,據說4.0之後,對多集合的事務支持也可以,不過我沒有深入研究過)
MongoDB的多集合關聯也沒有關係型數據庫強大,不過MongoDB更擅長把幾個表的信息,放在一個集合裡面。
所以總結來說,關係型數據庫和MongoDB是不存在誰替代誰的問題,他們應該是各有優勢,相互補充的。就好像我們平時用的無線鍵盤和機械鍵盤一樣,無線鍵盤靈活輕便、外觀比較時尚,而機械鍵盤手感出色、跪著舒服,不傷膝蓋,各有優勢。
希望我的回答,能夠幫助到你!我將持續分享Java開發、架構設計、職業發展等方面的見解,希望能得到你的關注;另外,關注我後私信【資料】兩個字,可獲取架構、大數據、面試等相關資料。
會點代碼的大叔
這個問題其實就好像問關係型數據庫可以取代非關係型數據庫一樣。
要說完全取代,肯定是不可能的。
但是某些小項目中,你可以選擇使用mongodb而不用mysql。至少我經常這麼幹。
當然,在一些特殊的大型項目裡面,你也可以完全拋棄關係型數據庫,mongodb會是你一個很好的選擇,什麼樣的項目?怎麼使用呢?我最後來告訴大家。
Mongodb確實非常好用,它的特點是高性能、易部署、易使用,存儲數據非常方便。
我們在使用的時候,不用再去考慮數據庫的設計,字段等等。
我們可以輕鬆的建立好實體,然後CRUD。
當然,它還能夠支持查詢和索引,這樣就讓我們在使用中更加的方便,只要不是複雜的表關係邏輯,我們都可以使用mongodb來完成。
但是缺點就就是上面說的,如果非常複雜的邏輯關係,那用mongodb就有點力不從心了。
因為mongodb在複雜的關係邏輯處理和事務控制方面就比較弱了。
曾經,我研究過一段時間領域驅動設計,也就是DDD。
當DDD和CQRS(命令與查詢職責分離)結合使用的時候(當然,很多時候說DDD都是結合了CQRS的),你就會發現,你是不是使用關係型數據庫已經不太重要了。
先說說底層,如果你使用DDD+CQRS,你可以有兩個數據庫,一個Command庫,一個Query庫,也就是讀庫和寫庫。
當DDD+CQRS使用時,寫庫裡面寫入的只是一個個對象的操作命令,所以可以簡單的說,一個命令就是一條記錄,而且寫庫裡面只有Insert。當然,最後的時候,寫庫裡面會有海量的數據,當數據量過大時,就會用到快照,這個就不說了。
這個時候我們就會發現,一個只有insert的單表庫,用關係型數據庫貌似沒啥意義。我用mongodb,redis都可以完成。
那我們再看看讀庫,讀庫其實是將所有的命令執行後的最終結果呈現出來,那讀庫應該是關係型的,因為我們的業務邏輯肯定是有關係的。
但是我們仔細體會後會發現,DDD的聚合,聚合根,實體對象,值對象這些概念,將本來複雜的關係整理得非常明晰(有興趣的可以去看看DDD,這些概念有點抽象,這裡就不介紹了)。
你會發現,我不使用關係型數據庫,我就是用一個緩存,或者mongodb就可以進行存儲了,因為我的查詢都是通過聚合根來實現的,我的命令也都是通過聚合根來完成的,聚合根是什麼?其實也就是一個實體類,整個聚合也就是一個複雜關係的實體類,聚合與聚合之間其實不會有聯繫,這個也就是DDD裡面的關於邊界的劃分。
那在實現這一的項目時,我就可以寫庫用Redis,讀庫用Mongodb,MySQL?可以不用了。
會技術的葛大爺
先給出結論:不可以取代!
能提出這樣的問題,肯定是對Mongodb不是很瞭解,來看看MongoDB是什麼,能做什麼,不能做什麼吧。
MongoDB
mongoDB是一個介於關係數據庫和非關係數據庫之間的產品,是非關係數據庫當中功能最豐富,最像關係數據庫的。他支持的數據結構非常鬆散,是類似json的bson格式,因此可以存儲比較複雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大,其語法有點類似於面向對象的查詢語言,幾乎可以實現類似關係數據庫單表查詢的絕大部分功能,而且還支持對數據建立索引。
特點:
- 面向集合存儲,易存儲對象類型的數據。
- 模式自由。
- 支持動態查詢。
- 支持完全索引,包含內部對象。
- 支持查詢。
- 支持複製和故障恢復。
- 使用高效的二進制數據存儲,包括大型對象(如視頻等)。
- 自動處理碎片,以支持雲計算層次的擴展性。
- 支持RUBY,PYTHON,JAVA,C++,PHP,C#等多種語言。
- 文件存儲格式為BSON(一種JSON的擴展)。
- 可通過網絡訪問。
使用原理
不適用的場景如下:
1)要求高度事務性的系統。
3)複雜的跨文檔(表)級聯查詢。
結論
從MongoDB不適用場景就可以看出其不可能替代MySQL.
用Java打醬油
MongoDB作為新一代的數據庫平臺,具備了智能操作數據平臺的特點:
1、易於開發,上手快,開發效率快;
2、天生的高可用性(副本集),天生的可擴展性(分片技術)滿足企業級的需求;
3、隨處部署的能力,可以和雲技術、容器技術深度集成,符合當前devops、微服務等技術發展趨勢。
正是因為上述原因,很多應用都已經或者正在考慮使用MongoDB替代MySQL。特別是在MongoDB 4.0之後,應用使用MongoDB替代MySQL順利成章,主要原因是:
1. MongoDB 4.0 提供了多文檔事務,支持完整的ACID操作;
2. MongoDB 4.0 優化了副本集的從節點的讀能力,從性能上更好的支撐分析型應用;
3. MongoDB 4.0 優化了聚合框架,從功能上更好的支撐分析型應用。
誠然,在使用MongoDB替代MySQL過程中也會有一些挑戰,這些挑戰從個人的經驗來看主要集中在:
1. 對MongoDB的“反範式”建模理解不夠;“反範式”建模作為一種創新的建模方式,以應用使用數據為導向,而不是過去以“實體”和“關係”為導向;
2. 對現有的基於MySQL的應用的數據遷移到MongoDB。這種數據遷移中挑戰比較大的地方在於如何實現實時遷移,MongoDB 3.6的Change Stream可以幫助實現數據實時遷移。
上述是個人的一些理解,供參考指正!
四の海
自己也是程序員,分享一些觀點給你,其實不管是MongoDB還是Mysql,它們都是用來存儲數據用的,只不過存儲數據的方式不同,MySQL主要用於存儲關係類的數據,而MongoDB主要用於存儲鍵值類的數據,也就是我們常說的NOSQL,曾經一段時間,NOSQL是很多中小互聯網公司追求的東西。
那麼既然都是存儲數據用的,那麼肯定也可以相互替換,但是一個重要的問題就是,怎麼樣將MongoDB裡面的數據存儲到MySQL裡面或者相反方向有怎麼存儲?這才是整個業務代碼非常複雜的實現部分,比如你要將MySQL的數據存儲到MongoDB裡面去,那麼你需要做的事情就是理清MySQL數據表裡面的各種關係,然後將這些關係轉換為鍵值對存儲到MongoDB裡面去,想象一下這個工作量我們就應該知道,不是那麼的簡單,尤其是數據表非常多,並且數據表關係非常複雜的時候,這項遷移工程是需要後端程序員、數據庫DBA、運維人員等等一起才能夠完成的事情。
所以得出結論,雖然兩種數據庫可以相互替換,但是替換的成本非常高,很多企業是不會這樣做的,除非現在項目性能已經嚴重影響到目標用戶。
互聯網知天下
Mongodb作為最靠近關係數據庫的Nosql存儲,取代MySQL可以嗎?
從功能角度看,是可以取代的。
關係數據庫應該有的核心功能它都有了:B樹索引,事務(4.0)。
一些比較重要的小更新,比如Decimal128(3.4)的添加都讓它的功能更加完善。
你在Mysql裡面用的複雜查詢基本上都可以用管道或者MapReduce實現。
我在好幾個項目中完全使用的Mongodb,經驗如下:
* 關聯查詢麻煩,所以Mongodb在設計模型的時候傾向於數據都內聯,配合少量的In 查詢。這樣也會導致數據冗餘後一致性更新的問題。
* 設計動態表格時,Mongodb的體驗時非常好的。
* 4.0之前的沒有事務,碰到金錢相關的服務,需要自己在服務中構造事務環境,否則一旦失敗無法回滾。這也會造成這塊代碼膨脹。
* 編寫複雜腳本查詢數據庫時,編寫腳本或者服務時難度更大,更花時間。統計服務較多的時候,更加傷腦子。
* 由於協議設計的原因,命令太多,導致不常用命令的需要經常查詢文檔。
推薦使用Mongodb的場合:
* 在Demo期間使用Mongodb做數據存儲。
* 處於前期的互聯網產品,適應快速迭代。
* 配合MySql使用,完成一些動態數據處理的功能。不用設計冗餘列,輕鬆構建查詢的感覺就是好。
* 作為一些熱數據或者中間數據(比如統計需要的中間表)的緩存使用。
Mongdob的官方文檔很完善,你要使用,建議把文檔瀏覽一遍。尤其是聚合管道查詢,花點時間好好理解,這個是你寫複雜查詢的基礎。
複雜的業務系統,儘量避免,它會影響你的開發效率。
再補充幾點:
客戶端工具可以使用navicate或者NoSql manager,推薦使用navicate,順手。
如果服務端不是nodejs之類的動態語言服務,最好寫一些命令的擴展,驅動在表達式轉換方面做得還不夠。
遷徙de麻雀
其實每個產品都有其特長的短板,可能會在一定程度上存在功能重複,但不可能完全取代。舉個不太恰當的例子來說:貓和狗都可以當寵物,貓能取代狗嗎?答案肯定是不能。但作為寵物,兩者確實都能做到惹人喜愛,也都能在主人寂寞或無聊的時候陪伴主人,作為寵物,它們甚至有更多相同的作用,但兩者永遠無法取代對方。不得不說在這個技術類產品滿天飛的時代,總有些對技術不深入瞭解的人或企業做著用貓來取代狗的白日夢,希望大家保持對技術的敬畏之心,可以大膽假設,但要謹慎求證,最終作出正確的選擇。
閆鋒同學
粘貼那麼多介紹幹嘛,一句話:不同業務場景,選用就不一樣。mysql針對業務結構複雜的用,mongodb反之。兩者結合,mongodb可以拿來做高級緩存或者提供查詢性能來存儲。mysql就出來業務結構複雜的數據存儲,還有事務回滾。mongodb是沒有事務回滾的
程序弈說
一種是關係數據庫,一種是非關係數據庫,他們的共同地方就是都是數據庫,都是用來存儲項目數據的,所以從理論上來說是可以相互替代的,但是,有一個實際問題,就是兩種數據的保存方式不同,也就是應用程序寫入數據的方式不同,所以相互替換時,需要熟悉兩個程序的保存方式和業務邏輯。