各位老鐵們羊赵，你們有沒有想老張昧捷，最近老張的才華被工作的繁忙所限制了靡挥，所以一直沒時間更博跋破，今兒個時隔數(shù)日我們終于再次見面啦（很開心）毒返！最近有部特別火的宮廷戲舷手，不知道大家有沒有看男窟，劇名叫做《延禧攻略》蝎宇，講述得是一個宮女，一路過關(guān)斬將兔乞，最后成為皇上最寵愛的令貴妃的故事庸追。加上我本人巨愛這類題材淡溯，所以癡迷得不得了咱娶。（好像暴露了自己沒有更博的真正原因哈哈）。宮廷類的劇屈糊，都是后宮嬪妃之間的爾虞吾詐逻锐，勾心斗角昧诱，有你沒我盏档，有我沒你的殘酷事實纲熏。勝者為王局劲，敗者為寇這種思想好像從古代就一直延續(xù)到今日鱼填。非要分出個勝負苹丸，分出個誰好，誰壞才罷休宦言。

在數(shù)據(jù)庫領域也會有此類問題奠旺，老張我混跡開源數(shù)據(jù)庫圈多年响疚。MySQL數(shù)據(jù)庫占領著開源數(shù)據(jù)庫的頭把交椅忿晕，MongoDB占領著NoSQL數(shù)據(jù)庫的第一位践盼。我們來看下數(shù)據(jù)庫的整體排名情況；

兩者都是第一赖淤，所有總會拿來比較。也會經(jīng)常被人問及到諸如此類的問題MongoDB4.0已經(jīng)問世了绷耍，而且支持事務了褂始，是不是將來可以取代MySQL了崎苗。MySQL和MongoDB哪個數(shù)據(jù)庫好用啊舀寓。今天老張想通過這篇文章互墓，帶著大家全方位解讀MySQL與MongoDB的區(qū)別篡撵。讓有困惑的老鐵們明白育谬，沒有誰替代誰膛檀，只有哪個場景更適合誰。

我們從下面四個方向依次闡明兩者的區(qū)別互站。只有更了解彼此胡桃，讓能更好地利用它們的功能性翠胰。

第一部分：數(shù)據(jù)庫概述

我們先來了解一下MySQL這個數(shù)據(jù)庫之景；

再來學習一下MySQL數(shù)據(jù)庫的特點锻狗；

MySQL了解完轻纪，同理我們來了解MongoDB及其特點的介紹刻帚；

MongoDB特點介紹：

學習完第一部分之后掂僵，我們對兩者數(shù)據(jù)庫都有了一定的認識锰蓬；接下來去從運維的角度來檢驗兩者的不同互妓；

第二部分：日常運維管理維度

1. 術(shù)語和概念的差異

結(jié)論可以看出摹芙，關(guān)系型數(shù)據(jù)庫中的表交胚，在MongoDB中叫做集合。行在MongoDB中叫做文檔。所以經(jīng)常管MongoDB叫做文檔型數(shù)據(jù)庫。

2.存儲數(shù)據(jù)結(jié)構(gòu)的差異

在關(guān)系型數(shù)據(jù)庫中設計表，有些信息需要多表記錄田篇。

而在MongoDB中，上面的三張表衣陶，就變成下面的這一段代碼就可以實現(xiàn)了。

{_id:"M416",name:"zhangsu",phone:[1234,5678],.....}

MongoDB表設計的特點

數(shù)據(jù)聚合

數(shù)據(jù)嵌套

數(shù)組結(jié)構(gòu)

3.啟動配置文件格式差異

MySQL數(shù)據(jù)庫的配置叫做my.cnf授翻，我們來看下它的記錄方式淮菠；

MongoDB配置文件使用Yaml格式

4.增刪改查操作的差異

5.事務支持的差異

但隨著MongoDB 4.0的問世低剔，它將支持多文檔事務镀琉，屆時MongoDB將成為唯一能夠同時支持速度替梨，靈活性，JSON文檔模型優(yōu)勢 和ACID數(shù)據(jù)完整性保證的數(shù)據(jù)庫挽鞠。

所謂的多文檔事務，可以理解為關(guān)系型數(shù)據(jù)庫的多行事務。在關(guān)系型的事務支持中，大家?guī)缀鯚o一例外支持同一事務內(nèi)操作的原子性攘乒，即要么全部提交负饲，要么全部回滾。這個同一事務內(nèi)可以有多個操作，針對于多個表刽沾，或者是同一個表內(nèi)的多行數(shù)據(jù)。

總結(jié)：隨著事務支持的增加，MongoDB功能上更接近于關(guān)系型數(shù)據(jù)庫顿乒，但是和關(guān)系型還是有本質(zhì)上的區(qū)別：MySQL是基于關(guān)系模型的數(shù)據(jù)庫吧雹，對各種數(shù)據(jù)多變的場景如物聯(lián)網(wǎng)或社交化并沒有MongoDB支持得好访得。MongoDB的JSON模型則具有動態(tài)靈活鳄炉，數(shù)據(jù)庫無須下線就可以進行模式變遷升級记靡，在這種場景下面，選擇MongoDB會特別合適呀洲。

6.備份上的差異

MySQL備份方式：

MongoDB備份方式：

邏輯備份與恢復

1.mongodump

2.mongorestore

3.mongoexport

4.mongoimport

注：MongoDB目前為止還沒有像xtrabackup這種好用的備份工具滓窍。所以一般來說，都是使用邏輯備份方式來進行操作

從運維角度我們對它們有了更深的認識之后舶替，我們來從集群架構(gòu)的維度出發(fā)抛蚁，去探究其更深的不同之處。

第三部分：集群架構(gòu)層面

1.集群架構(gòu)層面上的差異

我們先從MySQL復制的角度入手；然后再介紹MySQL高可用集群架構(gòu)

MySQL主從復制原理圖

MySQL復制種類總結(jié)；

異步復制：

通常沒說明指的都是異步血当，即主庫執(zhí)行完Commit后箩退，在主庫寫入Binlog日志后即可成功返回客戶端吠昭，無需等Binlog日志傳送給從庫府喳，一旦主庫宕機，有可能會丟失日志孔轴。

半同步復制：MySQL5.5版本之后引入了半同步復制功能收厨，主從服務器必須同時安裝半同步復制插件，才能開啟該復制功能碑诉。在該功能下漫仆，確保從庫接收完主庫傳遞過來的binlog內(nèi)容已經(jīng)寫入到自己的relay log里面了，才會通知主庫上面的等待線程建芙，該操作完畢。如果等待超時，超過rpl_semi_sync_master_timeout參數(shù)設置的時間，則關(guān)閉半同步復制竹宋，并自動轉(zhuǎn)換為異步復制模式宪潮，直到至少有一臺從庫通知主庫已經(jīng)接收到binlog信息了為止。

多源復制：

所謂多源復制，就是把多臺主庫的數(shù)據(jù)同步到一臺從庫服務器上，從庫會創(chuàng)建通往每個主庫的管道回官。在MySQL5.7之前的版本中区转，只能實現(xiàn)一主一從、一主多從或者多主多從的復制架構(gòu)侄泽，如果想要實現(xiàn)多主一從的復制悼尾，只能使用MariaDB。MySQL 5.7版本已經(jīng)可以實現(xiàn)多主一從的復制窄刘。

并行復制：

使用MySQL5.7的并行復制功能娩践。在5.6版本中就有了并行的概念翻伺，但其中的并行復制是基于庫級別的沮焕，即slave_parallel_type=database峦树。但在這種模式下，只是基于多庫少表的情況葬馋，并不適用于真實的生產(chǎn)環(huán)境下。在MySQL 5.7版本中条摸，真正實現(xiàn)了基于組提交的并行復制踏枣，簡單說就是主庫并行執(zhí)行SQL語句鸿捧，從庫也可以通過多個workers線程并發(fā)執(zhí)行relay log中主庫提交的事務啦租。想要開啟MySQL5.7的并行復制可以在從庫設置參數(shù)slave_parallel_workers>0，并把5.7版本中新添加的slave_parallel_type參數(shù)設置為LOGICAL_CLOCK荆针。該參數(shù)有DATABASE和 LOGICAL_CLOCK兩個值。MySQL5.6默認是database。

MySQL高可用集群架構(gòu)分類圖袁波；

MHA：

MHA的目的在于維持MySQL Replication中master庫的高可用性吆倦，其最大特點是可以修復多個slave之間的差異日志，最終使所有slave保持數(shù)據(jù)一致绰更，然后從中選擇一個充當新的master，并將其他slave指向它。當master出現(xiàn)故障時瘦赫，可以通過對比slave之間I/O thread 讀取主庫binlog的position號，選取最接近的slave作為備選主庫（備胎）。其他的從庫可以通過與備選主庫對比生成差異的中繼日志峰搪。在備選主庫上應用從原來master保存的binlog，同時將備選主庫提升為master。最后在其他slave上應用相應的差異中繼日志并從新的master開始復制。

雙主+keepalived

中小型規(guī)模的時候灯谣，采用這種架構(gòu)是最省事的胎许。

兩個節(jié)點可以采用簡單的一主一從模式，或者雙主模式北秽，并且放置于同一個VLAN中扬蕊，在master節(jié)點發(fā)生故障后檐春，利用keepalived/heartbeat的高可用機制實現(xiàn)快速切換到slave節(jié)點俐巴。

PXC集群：

PXC是基于Galera協(xié)議的MySQL高可用集群架構(gòu)欣舵。Galera產(chǎn)品是以Galera Cluster方式為MySQL提供高可用集群解決方案的缘圈。Galera Cluster就是集成了Galera插件的MySQL集群袜蚕。Galera replication是Codership提供的MySQL數(shù)據(jù)同步方案牲剃，具有高可用性，方便擴展缠犀，并且可以實現(xiàn)多個MySQL節(jié)點間的數(shù)據(jù)同步復制與讀寫夭坪，可保障數(shù)據(jù)庫的服務高可用及數(shù)據(jù)強一致性室梅。

MGR架構(gòu):

MySQL官方在5.7.17版本正式推出組復制（MySQL Group Replication亡鼠，簡稱MGR）。master1仁热，master2抗蠢，master3迅矛，所有成員獨立完成各自的事務潜叛。當客戶端先發(fā)起一個更新事務威兜，該事務先在本地執(zhí)行，執(zhí)行完成之后就要發(fā)起對事務的提交操作了蚂踊。在還沒有真正提交之前需要將產(chǎn)生的復制寫集廣播出去悴势，復制到其他成員特纤。如果沖突檢測成功侥加，組內(nèi)決定該事務可以提交，其他成員可以應用昔穴，否則就回滾吗货。最終宙搬，這意味著所有組內(nèi)成員以相同的順序接收同一組事務。因此組內(nèi)成員以相同的順序應用相同的修改脖母，保證組內(nèi)數(shù)據(jù)強一致性闲孤。

接下來介紹MongoDB的復制情況讼积；

MongoDB復制集：

三副本架構(gòu)是最基礎的復制集的架構(gòu)勤众，一主兩備模式决摧。主節(jié)點接受外界的讀寫請求凑兰，向備節(jié)點進行數(shù)據(jù)同步姑食。當主節(jié)點宕掉，會自動切換到備節(jié)點则拷，不影響線上業(yè)務煌茬，防止單點故障坛善。

MongoDB復制集自動切換

副本集的所有成員都可以接受讀取操作眠屎。 但是肆饶，默認情況下驯镊，應用程序?qū)⑵渥x取操作指向primary竭鞍。

副本集可以有至多一個primary節(jié)點笼蛛，primary節(jié)點宕機后滨砍，集群會觸發(fā)選舉以選出新的primary節(jié)點

在以下三成員節(jié)點副本集架構(gòu)中，primary宕機后惋戏，觸發(fā)了一次選舉响逢，從剩下的兩個secondary節(jié)點里棕孙，選舉出了一個新的primary節(jié)點。

MongoDB復制集讀寫分離設置

read preference 決定MongoDB客戶端從哪個節(jié)點上讀取數(shù)據(jù)。

默認情況下肢预，應用程序?qū)⑵渥x取操作指向副本集中的primary節(jié)點烫映。

指定read preference 選項時要注意：因為使用異步復制，復制延遲會導致secondary上的數(shù)據(jù)可能不是最新的抽兆。

默認情況下族淮，復制集的所有讀請求都發(fā)到Primary瞧筛，Driver可通過設置Read Preference來將讀請求路由到其他的節(jié)點。

primary： 默認規(guī)則揍瑟，所有讀請求發(fā)到Primary

primaryPreferred： Primary優(yōu)先绢片，如果Primary不可達，請求Secondary

secondary： 所有的讀請求都發(fā)到secondary

secondaryPreferred：Secondary優(yōu)先巢株，當所有Secondary不可達時熙涤，請求Primary

nearest：讀請求發(fā)送到最近的可達節(jié)點上（通過ping探測得出最近的節(jié)點）

MongoDB分片架構(gòu)

分片是一種在多臺機器上分配數(shù)據(jù)的方法祠挫。 MongoDB使用分片架構(gòu)有助于您去管理非常大數(shù)量的數(shù)據(jù)集和高吞吐量操作的集群等舔。

大數(shù)據(jù)量和高吞吐量的業(yè)務情況對單臺服務器來講是具備很大的挑戰(zhàn)性的。例如甚牲，高查詢率可能耗盡服務器的CPU容量丈钙。工作集大小超過系統(tǒng)內(nèi)存著恩，那么壓力則會給到磁盤上蜻展，這對IO來講不是我們所希望看到的邀摆。

MongoDB支持通過分片進行水平縮放栋盹。

總結(jié)：MySQL的復制種類很多例获，集群架構(gòu)在選擇性上來說也比較多。但橫向擴展能力上蠕搜，沒有MongoDB的分片架構(gòu)擴展能力強妓灌。

最后一部分，我們來通過MySQL與MongoDB的不同應用場景虫埂；來對兩種數(shù)據(jù)庫做一個最后的總結(jié)；

第四部分：應用場景角度

正如開篇介紹MySQL特點時說的缝呕，MySQL使用得覆蓋率已經(jīng)接近100%斧散。從大型BAT颅湘，電商平臺闯参，游戲公司，甚至諸多傳統(tǒng)行業(yè)也無不例外都在往MySQL數(shù)據(jù)庫方向靠攏新博，達到逐漸壟斷的趨勢赫悄。對于MongoDB 的應用也已經(jīng)×××到各個領域埂淮，比如游戲写隶、物流慕趴、電商冕房、內(nèi)容管理、社交给僵、物聯(lián)網(wǎng)想际、視頻直播等。

游戲領域：游戲場景牌柄，使用 MongoDB 存儲游戲用戶信息珊佣，用戶的裝備披粟、積分等直接以內(nèi)嵌文檔的形式存儲，方便查詢守屉、更新拇泛。

2.物流場景：使用MongoDB存儲訂單信息，訂單狀態(tài)在運送過程中會不斷更新恭取，以MongoDB內(nèi)嵌數(shù)組的形式來存儲熄守，一次查詢就能將訂單所有的變更讀取出來裕照。

3.社交場景：使用MongoDB存儲用戶信息晨继，以及用戶發(fā)表的朋友圈信息搬俊，通過地理位置索引實現(xiàn)附近的人唉擂、地點等功能

4.物聯(lián)網(wǎng)場景：使用MongoDB存儲所有接入的智能設備信息玩祟，以及設備匯報的日志信息屿聋，并對這些信息進行多維度的分析

對我而言，2009年開始接觸MySQL盘寡，我在2012年接觸的MongoDB的第一個版本2.1竿痰，對于這兩個數(shù)據(jù)庫真是手心手背都是肉影涉。在我孤獨寂寞的時候蟹倾，都是它們一直陪伴著我喊式，感謝技術(shù)給我們帶來的簡單快樂岔留。無論未來發(fā)展如何，沒有所謂的誰會替代誰检柬，只是說它們各自都有不同的特點献联，促使在不同的應用場景下，我們使用誰更合適而已何址。這里沒有宮廷內(nèi)斗里逆，沒有爾虞我詐，只有那份最簡單地做技術(shù)的心用爪，是現(xiàn)實版的延禧攻略原押！

對老張而言，寫篇文章很簡單偎血，但真得希望可以幫助到那些剛?cè)腴T或者想深入學習數(shù)據(jù)庫的同學們诸衔。能力有限笨农，水平一般，哪里有介紹不到的地方切揭，還望大家海涵！

轉(zhuǎn)載：http://blog.51cto.com/sumongodb/2164678