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

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

水平縮放

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

MySQL分片和限制

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

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

進入NoSQL

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

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

模式和分片

MongoDB是無模式的（或無模式的），這意味著它不需要在數(shù)據(jù)庫級別定義組織結構。該模式是在應用程序級別內置到我們的代碼中的，這為我們提供了很大的靈活性，可以在以后更改結構同時保留我們的數(shù)據(jù)。雖然它們缺乏符合ACID的SQL數(shù)據(jù)庫的嚴格強制一致性，但 MongoDB和其他NoSQL數(shù)據(jù)庫在可用性和分區(qū)容錯性方面表現(xiàn)出色。

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

從這里，我們可以立即看到NoSQL數(shù)據(jù)庫為可擴展性所做的讓步。NoSQL數(shù)據(jù)庫通常使用比SQL數(shù)據(jù)庫多得多的存儲，因為在大型水平部署中實現(xiàn)可用性需要大量冗余數(shù)據(jù)。NoSQL寫入速度往往優(yōu)于 SQL 數(shù)據(jù)庫，但查詢速度較慢。由于缺乏定義的結構，NoSQL數(shù)據(jù)庫本質上不符合 ACID，這使得它們不太適合處理大量金融交易的應用程序。或者，我們可以配置保持性能的大規(guī)模分布式NoSQL集群，使其成為大數(shù)據(jù)和分析的理想候選者。 

那么SQL數(shù)據(jù)庫什么時候不夠用呢？正如我們所料，答案并不簡單，但我們在設計應用程序時可以考慮一些通用準則。我們的應用程序需要做什么，它需要多大？從那里，我們可以決定我們的第一要務。說“SQL 垂直擴展而 NoSQL 水平擴展”是不正確的，但我們可以說“大多數(shù) SQL 數(shù)據(jù)庫在設計時都考慮了一致性，而大多數(shù)NoSQL數(shù)據(jù)庫在設計時都考慮了擴展性。”  

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