幾十年來，使用SQL的關(guān)系數(shù)據(jù)庫管理系統(tǒng) ( RBDMS )一直用于存儲(chǔ)應(yīng)用程序信息。作為醫(yī)療保健和金融等主要行業(yè)的支柱，將數(shù)據(jù)組織到表格中的關(guān)系模型被證明是可靠和高效的，表格的每一行都有一個(gè)識(shí)別鍵。包括MySQL和PostgreSQL在內(nèi)的現(xiàn)代SQL數(shù)據(jù)庫 仍然是當(dāng)今最流行的數(shù)據(jù)庫之一。但是SQL數(shù)據(jù)庫什么時(shí)候不夠用呢？

從2000年代后期開始的NoSQL（不僅僅是SQL）數(shù)據(jù)庫的興起與許多其他進(jìn)步同時(shí)發(fā)生。在多核處理器和虛擬化變得司空見慣的同時(shí)，云正在起飛，全球數(shù)百萬用戶首次使用智能手機(jī)上網(wǎng)。一切都需要增長(zhǎng)，而實(shí)現(xiàn)這種急需的規(guī)模的最實(shí)用方法是水平擴(kuò)展。我們經(jīng)?？吹綄QL與NoSQL過分簡(jiǎn)化為“SQL 可以垂直擴(kuò)展，NoSQL可以水平擴(kuò)展”，但這是不完整和不正確的。

水平縮放

當(dāng)我們談?wù)撍綌U(kuò)展時(shí)，我們的意思是通過添加更多節(jié)點(diǎn)或機(jī)器來擴(kuò)展我們的環(huán)境。雖然SQL數(shù)據(jù)庫可以通過向單個(gè)節(jié)點(diǎn)添加更多RAM 和計(jì)算來相對(duì)輕松地垂直擴(kuò)展，但將數(shù)據(jù)集分布到多個(gè)節(jié)點(diǎn)更具挑戰(zhàn)性。這可以通過稱為分片的技術(shù)來完成。在處理大型數(shù)據(jù)集和高吞吐量時(shí)，分片有助于減少單個(gè)服務(wù)器上的負(fù)載，并根據(jù)需要通過添加或刪除服務(wù)器來實(shí)現(xiàn)擴(kuò)展。

MySQL分片和限制

SQL數(shù)據(jù)庫可以通過分片進(jìn)行水平擴(kuò)展。方法和支持的功能在數(shù)據(jù)庫之間會(huì)有很大差異，但需要考慮一些注意事項(xiàng)。讓我們關(guān)注一個(gè)更常見的例子——使用NDB存儲(chǔ)引擎的MySQL。MySQL支持NDB集群，可以將單個(gè)大表拆分為多個(gè)較小的表，拆分表的過程稱為分區(qū)。當(dāng)存儲(chǔ)在多個(gè)服務(wù)器上時(shí)，這些較小的表構(gòu)成了分片。集群中的每個(gè)數(shù)據(jù)庫都存儲(chǔ)一個(gè)分片，集群中的數(shù)據(jù)庫共同構(gòu)成了完整的數(shù)據(jù)集。 

在SQL數(shù)據(jù)庫中使用分片可以提供非常高的數(shù)據(jù)集大小擴(kuò)展，但它也會(huì)使您的應(yīng)用程序邏輯更加復(fù)雜。我們需要仔細(xì)配置如何將數(shù)據(jù)劃分為多個(gè)分片，因?yàn)榇藳Q定會(huì)影響整體數(shù)據(jù)庫性能。除了復(fù)雜性和高時(shí)間要求外，還需要考慮技術(shù)障礙。為了應(yīng)對(duì)一個(gè)常見的限制，可以將 MySQL配置為跨多個(gè)分片執(zhí)行連接操作，但以犧牲更大規(guī)模的性能為代價(jià)。這會(huì)使分析功能在這些環(huán)境中變得不切實(shí)際。

進(jìn)入NoSQL

自2000年代后期出現(xiàn)以來，許多不同類型的NoSQL數(shù)據(jù)庫的使用呈爆炸式增長(zhǎng)。對(duì)于此示例，我們將重點(diǎn)關(guān)注最流行的NoSQL數(shù)據(jù)庫MongoDB。MongoDB（源自“humongous”一詞）是面向文檔的。數(shù)據(jù)存儲(chǔ)在類似于JSON對(duì)象的文檔中，每個(gè)文檔都包含成對(duì)的字段和值。這與使用表和行來格式化數(shù)據(jù)的SQL數(shù)據(jù)庫相反。我們可能已經(jīng)讀到，像MongoDB這樣的NoSQL數(shù)據(jù)庫通常更適合水平擴(kuò)展，但讓我們深入了解為什么會(huì)這樣。

請(qǐng)注意，MongoDB專門使用一種稱為BSON的格式，它源自JSON，但這會(huì)因每個(gè)數(shù)據(jù)庫而異。

模式和分片

MongoDB是無模式的（或無模式的），這意味著它不需要在數(shù)據(jù)庫級(jí)別定義組織結(jié)構(gòu)。該模式是在應(yīng)用程序級(jí)別內(nèi)置到我們的代碼中的，這為我們提供了很大的靈活性，可以在以后更改結(jié)構(gòu)同時(shí)保留我們的數(shù)據(jù)。雖然它們?nèi)狈Ψ螦CID的SQL數(shù)據(jù)庫的嚴(yán)格強(qiáng)制一致性，但 MongoDB和其他NoSQL數(shù)據(jù)庫在可用性和分區(qū)容錯(cuò)性方面表現(xiàn)出色。

當(dāng)我們研究水平擴(kuò)展SQL數(shù)據(jù)庫時(shí)，我們回顧了將表拆分為碎片的過程。雖然可能，但由于數(shù)據(jù)庫中內(nèi)置的剛性結(jié)構(gòu)，它帶來了很多限制。另一方面，MongoDB和其他NoSQL數(shù)據(jù)庫旨在適應(yīng)結(jié)構(gòu)級(jí)別的分片。分片是數(shù)據(jù)的一個(gè)子集，MongoDB允許我們通過將分片部署為副本集來水平擴(kuò)展。副本集是至少三個(gè)節(jié)點(diǎn)的集群，具有相同數(shù)據(jù)的冗余副本。當(dāng)它們分布在大型環(huán)境中并且不受預(yù)定方案的限制時(shí)，它們提供可用性和冗余。

從這里，我們可以立即看到NoSQL數(shù)據(jù)庫為可擴(kuò)展性所做的讓步。NoSQL數(shù)據(jù)庫通常使用比SQL數(shù)據(jù)庫多得多的存儲(chǔ)，因?yàn)樵诖笮退讲渴鹬袑?shí)現(xiàn)可用性需要大量冗余數(shù)據(jù)。NoSQL寫入速度往往優(yōu)于 SQL 數(shù)據(jù)庫，但查詢速度較慢。由于缺乏定義的結(jié)構(gòu)，NoSQL數(shù)據(jù)庫本質(zhì)上不符合 ACID，這使得它們不太適合處理大量金融交易的應(yīng)用程序?；蛘撸覀兛梢耘渲帽３中阅艿拇笠?guī)模分布式NoSQL集群，使其成為大數(shù)據(jù)和分析的理想候選者。 

那么SQL數(shù)據(jù)庫什么時(shí)候不夠用呢？正如我們所料，答案并不簡(jiǎn)單，但我們?cè)谠O(shè)計(jì)應(yīng)用程序時(shí)可以考慮一些通用準(zhǔn)則。我們的應(yīng)用程序需要做什么，它需要多大？從那里，我們可以決定我們的第一要?jiǎng)?wù)。說“SQL 垂直擴(kuò)展而 NoSQL 水平擴(kuò)展”是不正確的，但我們可以說“大多數(shù) SQL 數(shù)據(jù)庫在設(shè)計(jì)時(shí)都考慮了一致性，而大多數(shù)NoSQL數(shù)據(jù)庫在設(shè)計(jì)時(shí)都考慮了擴(kuò)展性?！?nbsp; 

總結(jié)：我們可以水平擴(kuò)展MySQL，MongoDB開始支持多文檔ACID事務(wù)。我們對(duì)這些數(shù)據(jù)庫的設(shè)計(jì)方式了解得越多，我們就越有洞察力來選擇最適合工作的工具。