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

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

水平縮放

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

MySQL分片和限制

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

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

進入NoSQL

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

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

模式和分片

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

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

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

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

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