柯----
Mongodb作為最靠近關係數據庫的Nosql存儲，取代MySQL可以嗎？
從功能角度看，是可以取代的。
關係數據庫應該有的核心功能它都有了：B樹索引，事務（4.0）。
一些比較重要的小更新，比如Decimal128（3.4）的添加都讓它的功能更加完善。
你在Mysql裡面用的複雜查詢基本上都可以用管道或者MapReduce實現。
我在好幾個項目中完全使用的Mongodb，經驗如下：
* 關聯查詢麻煩，所以Mongodb在設計模型的時候傾向於數據都內聯，配合少量的In 查詢。這樣也會導致數據冗餘後一致性更新的問題。
* 設計動態表格時，Mongodb的體驗時非常好的。
* 4.0之前的沒有事務，碰到金錢相關的服務，需要自己在服務中構造事務環境，否則一旦失敗無法回滾。這也會造成這塊代碼膨脹。
* 編寫複雜腳本查詢數據庫時，編寫腳本或者服務時難度更大，更花時間。統計服務較多的時候，更加傷腦子。
* 協議設計方面，指令數量太多，這個導致需要經常查詢文檔。
推薦使用Mongodb的場合：
* 在Demo期間使用Mongodb做數據存儲。
* 處於前期的互聯網產品，適應快速迭代。
* 配合MySql使用，完成一些動態數據處理的功能。不用設計冗餘列，輕鬆構建查詢的感覺就是好。
* 作為一些熱數據或者中間數據的緩存使用。
Mongdob的官方文檔很完善，你要使用，建議把文檔瀏覽一遍。尤其是聚合管道查詢，花點時間好好理解，這個是你寫複雜查詢的基礎。
複雜的業務系統，儘量避免，它會影響你的開發效率。
遷徙的麻雀zzz
這個問題其實就好像問關係型數據庫可以取代非關係型數據庫一樣。
要說完全取代，肯定是不可能的。
但是某些小項目中，你可以選擇使用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還是Mysql,它們都是用來存儲數據用的，只不過存儲數據的方式不同，MySQL主要用於存儲關係類的數據，而MongoDB主要用於存儲鍵值類的數據，也就是我們常說的NOSQL，曾經一段時間，NOSQL是很多中小互聯網公司追求的東西。
那麼既然都是存儲數據用的，那麼肯定也可以相互替換，但是一個重要的問題就是，怎麼樣將MongoDB裡面的數據存儲到MySQL裡面或者相反方向有怎麼存儲？這才是整個業務代碼非常複雜的實現部分，比如你要將MySQL的數據存儲到MongoDB裡面去，那麼你需要做的事情就是理清MySQL數據表裡面的各種關係，然後將這些關係轉換為鍵值對存儲到MongoDB裡面去，想象一下這個工作量我們就應該知道，不是那麼的簡單，尤其是數據表非常多，並且數據表關係非常複雜的時候，這項遷移工程是需要後端程序員、數據庫DBA、運維人員等等一起才能夠完成的事情。
所以得出結論，雖然兩種數據庫可以相互替換，但是替換的成本非常高，很多企業是不會這樣做的，除非現在項目性能已經嚴重影響到目標用戶。
互聯網知天下
一種是關係數據庫，一種是非關係數據庫，他們的共同地方就是都是數據庫，都是用來存儲項目數據的，所以從理論上來說是可以相互替代的，但是，有一個實際問題，就是兩種數據的保存方式不同，也就是應用程序寫入數據的方式不同，所以相互替換時，需要熟悉兩個程序的保存方式和業務邏輯。
