各位老鐵們，你們有沒有想老張，最近老張的才華被工作的繁忙所限制了，所以一直沒時(shí)間更博，今兒個(gè)時(shí)隔數(shù)日我們終于再次見面啦（很開心）！最近有部特別火的宮廷戲，不知道大家有沒有看，劇名叫做《延禧攻略》，講述得是一個(gè)宮女，一路過關(guān)斬將，最后成為皇上最寵愛的令貴妃的故事。加上我本人巨愛這類題材，所以癡迷得不得了。（好像暴露了自己沒有更博的真正原因哈哈）。宮廷類的劇，都是后宮嬪妃之間的爾虞吾詐，勾心斗角，有你沒我，有我沒你的殘酷事實(shí)。勝者為王，敗者為寇這種思想好像從古代就一直延續(xù)到今日。非要分出個(gè)勝負(fù)，分出個(gè)誰好，誰壞才罷休。
創(chuàng)新互聯(lián)公司，為您提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、網(wǎng)站營銷推廣、網(wǎng)站開發(fā)設(shè)計(jì)，對服務(wù)圍欄護(hù)欄等多個(gè)行業(yè)擁有豐富的網(wǎng)站建設(shè)及推廣經(jīng)驗(yàn)。創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司成立于2013年,提供專業(yè)網(wǎng)站制作報(bào)價(jià)服務(wù),我們深知市場的競爭激烈，認(rèn)真對待每位客戶，為客戶提供賞心悅目的作品。 與客戶共同發(fā)展進(jìn)步，是我們永遠(yuǎn)的責(zé)任！
在數(shù)據(jù)庫領(lǐng)域也會(huì)有此類問題，老張我混跡開源數(shù)據(jù)庫圈多年。MySQL數(shù)據(jù)庫占領(lǐng)著開源數(shù)據(jù)庫的頭把交椅，MongoDB占領(lǐng)著NoSql數(shù)據(jù)庫的第一位。我們來看下數(shù)據(jù)庫的整體排名情況；
兩者都是第一，所有總會(huì)拿來比較。也會(huì)經(jīng)常被人問及到諸如此類的問題MongoDB4.0已經(jīng)問世了，而且支持事務(wù)了，是不是將來可以取代MySQL了。MySQL和MongoDB哪個(gè)數(shù)據(jù)庫好用啊。今天老張想通過這篇文章，帶著大家全方位解讀MySQL與MongoDB的區(qū)別。讓有困惑的老鐵們明白，沒有誰替代誰，只有哪個(gè)場景更適合誰。
我們從下面四個(gè)方向依次闡明兩者的區(qū)別。只有更了解彼此，讓能更好地利用它們的功能性。
我們先來了解一下MySQL這個(gè)數(shù)據(jù)庫；
再來學(xué)習(xí)一下MySQL數(shù)據(jù)庫的特點(diǎn)；
MySQL了解完，同理我們來了解MongoDB及其特點(diǎn)的介紹；
MongoDB特點(diǎn)介紹：
學(xué)習(xí)完第一部分之后，我們對兩者數(shù)據(jù)庫都有了一定的認(rèn)識(shí)；接下來去從運(yùn)維的角度來檢驗(yàn)兩者的不同；
結(jié)論可以看出，關(guān)系型數(shù)據(jù)庫中的表，在MongoDB中叫做集合。行在MongoDB中叫做文檔。所以經(jīng)常管MongoDB叫做文檔型數(shù)據(jù)庫。
在關(guān)系型數(shù)據(jù)庫中設(shè)計(jì)表，有些信息需要多表記錄。
而在MongoDB中，上面的三張表，就變成下面的這一段代碼就可以實(shí)現(xiàn)了。
重慶分公司
重慶分公司
{
_id:"M416",
name:"zhangsu",
phone:[1234,5678],
.....
}MongoDB表設(shè)計(jì)的特點(diǎn)
MySQL數(shù)據(jù)庫的配置叫做my.cnf，我們來看下它的記錄方式；
[client]
port = 3306
socket = /data/mysql/mysql.sock
[mysql]
prompt="\u@db \R:\m:\s [\d]> "
no-auto-rehash
[mysqld]
user = mysql
port = 3306
basedir = /usr/local/mysql
datadir = /data/mysql/
socket = /data/mysql/mysql.sock
pid-file = db.pid
character-set-server = utf8mb4
skip_name_resolve = 1
open_files_limit = 65535
back_log = 1024
max_connections = 512
max_connect_errors = 1000000
table_open_cache = 1024
table_definition_cache = 1024
table_open_cache_instances = 64
thread_stack = 512K
external-locking = FALSE
max_allowed_packet = 32M
sort_buffer_size = 4M
join_buffer_size = 4M
thread_cache_size = 768
#query_cache_size = 0
#query_cache_type = 0
interactive_timeout = 600
wait_timeout = 600
tmp_table_size = 32M
max_heap_table_size = 32M
slow_query_log = 1
slow_query_log_file = /data/mysql/slow.log
log-error = /data/mysql/error.log
long_query_time = 0.1
server-id = 3306101
log-bin = /data/mysql/mybinlog
sync_binlog = 1
binlog_cache_size = 4M
max_binlog_cache_size = 1G
max_binlog_size = 1G
expire_logs_days = 7
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates=1
binlog_format = row
relay_log_recovery = 1
relay-log-purge = 1
key_buffer_size = 32M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
bulk_insert_buffer_size = 64M
#myisam_sort_buffer_size = 128M
#myisam_max_sort_file_size = 10G
#myisam_repair_threads = 1
lock_wait_timeout = 3600
explicit_defaults_for_timestamp = 1
innodb_thread_concurrency = 0
innodb_sync_spin_loops = 100
innodb_spin_wait_delay = 30
secure_file_priv=''
super_read_only=0
transaction_isolation = REPEATABLE-READ
#innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 8
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_data_file_path = ibdata1:100M:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 32M
innodb_log_file_size = 2G
innodb_log_files_in_group = 2
innodb_max_undo_log_size = 4G
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_flush_neighbors = 0
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_purge_threads = 4
innodb_page_cleaners = 4
innodb_open_files = 65535
innodb_max_dirty_pages_pct = 50
innodb_flush_method = O_DIRECT
innodb_lru_scan_depth = 4000
innodb_checksum_algorithm = crc32
#innodb_file_format = Barracuda
#innodb_file_format_max = Barracuda
innodb_lock_wait_timeout = 10
innodb_rollback_on_timeout = 1
innodb_print_all_deadlocks = 1
innodb_file_per_table = 1
innodb_online_alter_log_max_size = 4G
internal_tmp_disk_storage_engine = InnoDB
innodb_stats_on_metadata = 0
innodb_status_file = 1
[mysqldump]
quick
max_allowed_packet = 32M
MongoDB配置文件使用Yaml格式
但隨著MongoDB 4.0的問世，它將支持多文檔事務(wù)，屆時(shí)MongoDB將成為唯一能夠同時(shí)支持速度，靈活性，JSON文檔模型優(yōu)勢 和ACID數(shù)據(jù)完整性保證的數(shù)據(jù)庫。
所謂的多文檔事務(wù)，可以理解為關(guān)系型數(shù)據(jù)庫的多行事務(wù)。在關(guān)系型的事務(wù)支持中，大家?guī)缀鯚o一例外支持同一事務(wù)內(nèi)操作的原子性，即要么全部提交，要么全部回滾。這個(gè)同一事務(wù)內(nèi)可以有多個(gè)操作，針對于多個(gè)表，或者是同一個(gè)表內(nèi)的多行數(shù)據(jù)。
總結(jié)：隨著事務(wù)支持的增加，MongoDB功能上更接近于關(guān)系型數(shù)據(jù)庫，但是和關(guān)系型還是有本質(zhì)上的區(qū)別：MySQL是基于關(guān)系模型的數(shù)據(jù)庫，對各種數(shù)據(jù)多變的場景如物聯(lián)網(wǎng)或社交化并沒有MongoDB支持得好。MongoDB的JSON模型則具有動(dòng)態(tài)靈活，數(shù)據(jù)庫無須下線就可以進(jìn)行模式變遷升級，在這種場景下面，選擇MongoDB會(huì)特別合適。
MySQL備份方式：
MongoDB備份方式：
邏輯備份與恢復(fù)
1.mongodump
2.mongorestore
3.mongoexport
4.mongoimport
注：MongoDB目前為止還沒有像xtrabackup這種好用的備份工具。所以一般來說，都是使用邏輯備份方式來進(jìn)行操作
從運(yùn)維角度我們對它們有了更深的認(rèn)識(shí)之后，我們來從集群架構(gòu)的維度出發(fā)，去探究其更深的不同之處。
我們先從MySQL復(fù)制的角度入手；然后再介紹MySQL高可用集群架構(gòu)
MySQL主從復(fù)制原理圖
MySQL復(fù)制種類總結(jié)；
異步復(fù)制：
通常沒說明指的都是異步，即主庫執(zhí)行完Commit后，在主庫寫入Binlog日志后即可成功返回客戶端，無需等Binlog日志傳送給從庫，一旦主庫宕機(jī)，有可能會(huì)丟失日志。
半同步復(fù)制：MySQL5.5版本之后引入了半同步復(fù)制功能，主從服務(wù)器必須同時(shí)安裝半同步復(fù)制插件，才能開啟該復(fù)制功能。在該功能下，確保從庫接收完主庫傳遞過來的binlog內(nèi)容已經(jīng)寫入到自己的relay log里面了，才會(huì)通知主庫上面的等待線程，該操作完畢。如果等待超時(shí)，超過rpl_semi_sync_master_timeout參數(shù)設(shè)置的時(shí)間，則關(guān)閉半同步復(fù)制，并自動(dòng)轉(zhuǎn)換為異步復(fù)制模式，直到至少有一臺(tái)從庫通知主庫已經(jīng)接收到binlog信息了為止。
多源復(fù)制：
所謂多源復(fù)制，就是把多臺(tái)主庫的數(shù)據(jù)同步到一臺(tái)從庫服務(wù)器上，從庫會(huì)創(chuàng)建通往每個(gè)主庫的管道。在MySQL5.7之前的版本中，只能實(shí)現(xiàn)一主一從、一主多從或者多主多從的復(fù)制架構(gòu)，如果想要實(shí)現(xiàn)多主一從的復(fù)制，只能使用MariaDB。MySQL 5.7版本已經(jīng)可以實(shí)現(xiàn)多主一從的復(fù)制。
并行復(fù)制：
使用MySQL5.7的并行復(fù)制功能。在5.6版本中就有了并行的概念，但其中的并行復(fù)制是基于庫級別的，即slave_parallel_type=database。但在這種模式下，只是基于多庫少表的情況，并不適用于真實(shí)的生產(chǎn)環(huán)境下。在MySQL 5.7版本中，真正實(shí)現(xiàn)了基于組提交的并行復(fù)制，簡單說就是主庫并行執(zhí)行SQL語句，從庫也可以通過多個(gè)workers線程并發(fā)執(zhí)行relay log中主庫提交的事務(wù)。想要開啟MySQL5.7的并行復(fù)制可以在從庫設(shè)置參數(shù)slave_parallel_workers>0，并把5.7版本中新添加的slave_parallel_type參數(shù)設(shè)置為LOGICAL_CLOCK。該參數(shù)有DATABASE和 LOGICAL_CLOCK兩個(gè)值。MySQL5.6默認(rèn)是database。
MySQL高可用集群架構(gòu)分類圖；
MHA：
MHA的目的在于維持MySQL Replication中master庫的高可用性，其最大特點(diǎn)是可以修復(fù)多個(gè)slave之間的差異日志，最終使所有slave保持?jǐn)?shù)據(jù)一致，然后從中選擇一個(gè)充當(dāng)新的master，并將其他slave指向它。當(dāng)master出現(xiàn)故障時(shí)，可以通過對比slave之間I/O thread 讀取主庫binlog的position號(hào)，選取最接近的slave作為備選主庫（備胎）。其他的從庫可以通過與備選主庫對比生成差異的中繼日志。在備選主庫上應(yīng)用從原來master保存的binlog，同時(shí)將備選主庫提升為master。最后在其他slave上應(yīng)用相應(yīng)的差異中繼日志并從新的master開始復(fù)制。
雙主+keepalived
中小型規(guī)模的時(shí)候，采用這種架構(gòu)是最省事的。
兩個(gè)節(jié)點(diǎn)可以采用簡單的一主一從模式，或者雙主模式，并且放置于同一個(gè)VLAN中，在master節(jié)點(diǎn)發(fā)生故障后，利用keepalived/heartbeat的高可用機(jī)制實(shí)現(xiàn)快速切換到slave節(jié)點(diǎn)。
PXC集群：
PXC是基于Galera協(xié)議的MySQL高可用集群架構(gòu)。Galera產(chǎn)品是以Galera Cluster方式為MySQL提供高可用集群解決方案的。Galera Cluster就是集成了Galera插件的MySQL集群。Galera replication是Codership提供的MySQL數(shù)據(jù)同步方案，具有高可用性，方便擴(kuò)展，并且可以實(shí)現(xiàn)多個(gè)MySQL節(jié)點(diǎn)間的數(shù)據(jù)同步復(fù)制與讀寫，可保障數(shù)據(jù)庫的服務(wù)高可用及數(shù)據(jù)強(qiáng)一致性。
MGR架構(gòu):
MySQL官方在5.7.17版本正式推出組復(fù)制（MySQL Group Replication，簡稱MGR）。master1，master2，master3，所有成員獨(dú)立完成各自的事務(wù)。當(dāng)客戶端先發(fā)起一個(gè)更新事務(wù)，該事務(wù)先在本地執(zhí)行，執(zhí)行完成之后就要發(fā)起對事務(wù)的提交操作了。在還沒有真正提交之前需要將產(chǎn)生的復(fù)制寫集廣播出去，復(fù)制到其他成員。如果沖突檢測成功，組內(nèi)決定該事務(wù)可以提交，其他成員可以應(yīng)用，否則就回滾。最終，這意味著所有組內(nèi)成員以相同的順序接收同一組事務(wù)。因此組內(nèi)成員以相同的順序應(yīng)用相同的修改，保證組內(nèi)數(shù)據(jù)強(qiáng)一致性。
接下來介紹MongoDB的復(fù)制情況；
MongoDB復(fù)制集：
三副本架構(gòu)是最基礎(chǔ)的復(fù)制集的架構(gòu)，一主兩備模式。主節(jié)點(diǎn)接受外界的讀寫請求，向備節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步。當(dāng)主節(jié)點(diǎn)宕掉，會(huì)自動(dòng)切換到備節(jié)點(diǎn)，不影響線上業(yè)務(wù)，防止單點(diǎn)故障。
MongoDB復(fù)制集自動(dòng)切換
副本集的所有成員都可以接受讀取操作。 但是，默認(rèn)情況下，應(yīng)用程序?qū)⑵渥x取操作指向primary。
副本集可以有至多一個(gè)primary節(jié)點(diǎn)，primary節(jié)點(diǎn)宕機(jī)后，集群會(huì)觸發(fā)選舉以選出新的primary節(jié)點(diǎn)
在以下三成員節(jié)點(diǎn)副本集架構(gòu)中，primary宕機(jī)后，觸發(fā)了一次選舉，從剩下的兩個(gè)secondary節(jié)點(diǎn)里，選舉出了一個(gè)新的primary節(jié)點(diǎn)。
MongoDB復(fù)制集讀寫分離設(shè)置
read preference 決定MongoDB客戶端從哪個(gè)節(jié)點(diǎn)上讀取數(shù)據(jù)。
默認(rèn)情況下，應(yīng)用程序?qū)⑵渥x取操作指向副本集中的primary節(jié)點(diǎn)。
指定read preference 選項(xiàng)時(shí)要注意：因?yàn)槭褂卯惒綇?fù)制，復(fù)制延遲會(huì)導(dǎo)致secondary上的數(shù)據(jù)可能不是最新的。
默認(rèn)情況下，復(fù)制集的所有讀請求都發(fā)到Primary，Driver可通過設(shè)置Read Preference來將讀請求路由到其他的節(jié)點(diǎn)。
primary： 默認(rèn)規(guī)則，所有讀請求發(fā)到Primary
primaryPreferred： Primary優(yōu)先，如果Primary不可達(dá)，請求Secondary
secondary： 所有的讀請求都發(fā)到secondary
secondaryPreferred：Secondary優(yōu)先，當(dāng)所有Secondary不可達(dá)時(shí)，請求Primary
nearest：讀請求發(fā)送到最近的可達(dá)節(jié)點(diǎn)上（通過ping探測得出最近的節(jié)點(diǎn)）
MongoDB分片架構(gòu)
分片是一種在多臺(tái)機(jī)器上分配數(shù)據(jù)的方法。 MongoDB使用分片架構(gòu)有助于您去管理非常大數(shù)量的數(shù)據(jù)集和高吞吐量操作的集群。
大數(shù)據(jù)量和高吞吐量的業(yè)務(wù)情況對單臺(tái)服務(wù)器來講是具備很大的挑戰(zhàn)性的。例如，高查詢率可能耗盡服務(wù)器的CPU容量。工作集大小超過系統(tǒng)內(nèi)存，那么壓力則會(huì)給到磁盤上，這對IO來講不是我們所希望看到的。
MongoDB支持通過分片進(jìn)行水平縮放。
總結(jié)：MySQL的復(fù)制種類很多，集群架構(gòu)在選擇性上來說也比較多。但橫向擴(kuò)展能力上，沒有MongoDB的分片架構(gòu)擴(kuò)展能力強(qiáng)。
最后一部分，我們來通過MySQL與MongoDB的不同應(yīng)用場景；來對兩種數(shù)據(jù)庫做一個(gè)最后的總結(jié)；
正如開篇介紹MySQL特點(diǎn)時(shí)說的，MySQL使用得覆蓋率已經(jīng)接近100%。從大型BAT，電商平臺(tái)，游戲公司，甚至諸多傳統(tǒng)行業(yè)也無不例外都在往MySQL數(shù)據(jù)庫方向靠攏，達(dá)到逐漸壟斷的趨勢。對于MongoDB 的應(yīng)用也已經(jīng)×××到各個(gè)領(lǐng)域，比如游戲、物流、電商、內(nèi)容管理、社交、物聯(lián)網(wǎng)、視頻直播等。
2.物流場景：使用MongoDB存儲(chǔ)訂單信息，訂單狀態(tài)在運(yùn)送過程中會(huì)不斷更新，以MongoDB內(nèi)嵌數(shù)組的形式來存儲(chǔ)，一次查詢就能將訂單所有的變更讀取出來。
3.社交場景：使用MongoDB存儲(chǔ)用戶信息，以及用戶發(fā)表的朋友圈信息，通過地理位置索引實(shí)現(xiàn)附近的人、地點(diǎn)等功能
4.物聯(lián)網(wǎng)場景：使用MongoDB存儲(chǔ)所有接入的智能設(shè)備信息，以及設(shè)備匯報(bào)的日志信息，并對這些信息進(jìn)行多維度的分析
對我而言，2009年開始接觸MySQL，我在2012年接觸的MongoDB的第一個(gè)版本2.1，對于這兩個(gè)數(shù)據(jù)庫真是手心手背都是肉。在我孤獨(dú)寂寞的時(shí)候，都是它們一直陪伴著我，感謝技術(shù)給我們帶來的簡單快樂。無論未來發(fā)展如何，沒有所謂的誰會(huì)替代誰，只是說它們各自都有不同的特點(diǎn)，促使在不同的應(yīng)用場景下，我們使用誰更合適而已。這里沒有宮廷內(nèi)斗，沒有爾虞我詐，只有那份最簡單地做技術(shù)的心，是現(xiàn)實(shí)版的延禧攻略！
對老張而言，寫篇文章很簡單，但真得希望可以幫助到那些剛?cè)腴T或者想深入學(xué)習(xí)數(shù)據(jù)庫的同學(xué)們。能力有限，水平一般，哪里有介紹不到的地方，還望大家海涵！
在我們最愛的51CTO 13歲生日之際，作為51CTO專家博主，數(shù)據(jù)庫專家，我推出了自己的訂閱專欄十年老兵教你練一套正宗的MySQL降龍十八掌
