NoSQL 數據庫權威指南

毫無疑問，Web 應用程序處理數據的方式在過去十年中發生了顯著變化。 正在收集更多的數據，並且有更多的用戶同時訪問這些數據。 這意味著對於基於模式的關係數據庫而言，可伸縮性和性能比以往任何時候都更具挑戰，因此更難擴展。

NoSQL 的演變

SQL 可擴展性問題已被具有龐大且不斷增長的數據和基礎設施需求的 Web 2.0 公司所認識到，例如 Google、Amazon 和 Facebook。 他們提出了自己的解決方案——BigTable、DynamoDB 和 Cassandra 等技術。

這種日益增長的興趣導致了許多 NoSQL 數據庫管理系統 (DBMS)，重點關注性能、可靠性和一致性。 為了提高搜索和讀取性能，許多現有的索引結構被重用和改進。

首先，有大公司為滿足其特定需求而開發的專有（閉源）類型的 NoSQL 數據庫，例如被認為是第一個 NoSQL 系統的 Google 的 BigTable 和 Amazon 的 DynamoDB。

這些專有系統的成功引發了許多類似的開源和專有數據庫系統的開發，其中最流行的是 Hypertable、Cassandra、MongoDB、DynamoDB、HBase 和 Redis。

是什麼讓 NoSQL 與眾不同？

NoSQL 數據庫和傳統關係數據庫之間的一個關鍵區別在於 NoSQL 是一種非結構化存儲形式。

這意味著 NoSQL 數據庫不像關係數據庫中那樣具有固定的表結構。

NoSQL 數據庫的優缺點

優點

與傳統的關係數據庫相比，NoSQL 數據庫具有許多優勢。

一個主要的潛在區別是 NoSQL 數據庫具有簡單而靈活的結構。 它們是無模式的。

與關係數據庫不同，NoSQL 數據庫基於鍵值對。

NoSQL 數據庫的一些存儲類型包括列存儲、文檔存儲、鍵值存儲、圖形存儲、對象存儲、XML 存儲和其他數據存儲模式。

通常，數據庫中的每個值都有一個鍵。 一些 NoSQL 數據庫存儲還允許開發人員將序列化對象存儲到數據庫中，而不僅僅是簡單的字符串值。

開源 NoSQL 數據庫不需要昂貴的許可費用，並且可以在廉價的硬件上運行，從而使其部署具有成本效益。

此外，在使用 NoSQL 數據庫時，無論它們是開源的還是專有的，擴展都比使用關係數據庫時更容易且更便宜。 這是因為它是通過在所有節點上水平擴展和分配負載來完成的，而不是通常使用關係數據庫系統完成的垂直擴展類型，後者正在用更強大的主機替換主主機。

缺點

當然，NoSQL 數據庫並不完美，它們並不總是正確的選擇。

一方面，大多數 NoSQL 數據庫不支持關係數據庫系統本機支持的可靠性特性。 這些可靠性特徵可以概括為原子性、一致性、隔離性和持久性。 這也意味著不支持這些功能的 NoSQL 數據庫會以一致性換取性能和可擴展性。

為了支持可靠性和一致性特性，開發人員必須實現自己的專有代碼，這增加了系統的複雜性。

這可能會限制可以依賴 NoSQL 數據庫進行安全可靠交易的應用程序的數量，例如銀行系統。

在大多數 NoSQL 數據庫中發現的其他形式的複雜性包括與 SQL 查詢的不兼容。 這意味著需要手動或專有查詢語言，從而增加更多時間和復雜性。

NoSQL 與關係數據庫

下表提供了 NoSQL 和關係數據庫之間的簡要功能比較：

應該注意的是，該表顯示了數據庫級別的比較，而不是實現這兩種模型的各種數據庫管理系統。 這些系統提供了他們自己的專有技術來克服這兩個系統中的一些問題和缺點，並且在某些情況下，顯著提高了性能和可靠性。

NoSQL 數據存儲類型

鍵值存儲

在鍵值存儲類型中，使用了一個哈希表，其中唯一的鍵指向一個項目。

鍵可以組織成鍵的邏輯組，只要求鍵在它們自己的組中是唯一的。 這允許不同邏輯組中的相同鍵。 下表顯示了一個鍵值存儲的示例，其中鍵是城市的名稱，值是阿爾斯特大學在該城市的地址。

鍵值存儲的一些實現提供了緩存機制，這大大提高了它們的性能。

處理存儲在數據庫中的項目所需的一切都是關鍵。 數據以字符串、JSON 或 BLOB（二進制大對象）的形式存儲。

這種數據庫形式的最大缺陷之一是數據庫級別缺乏一致性。 這可以由開發人員使用他們自己的代碼添加，但如前所述，這會增加更多的工作量、複雜性和時間。

最著名的基於鍵值存儲的 NoSQL 數據庫是 Amazon 的 DynamoDB。

文檔存儲

文檔存儲類似於鍵值存儲，因為它們是無模式的並且基於鍵值模型。 因此，兩者都有許多相同的優點和缺點。 兩者都缺乏數據庫級別的一致性，這為應用程序提供更多的可靠性和一致性功能鋪平了道路。

但是，兩者之間存在關鍵差異。

在文檔存儲中，值（文檔）為存儲的數據提供編碼。 這些編碼可以是 XML、JSON 或 BSON（二進制編碼的 JSON）。

此外，還可以進行基於數據的查詢。

最流行的依賴文檔存儲的數據庫應用程序是 MongoDB。

列商店

在列存儲數據庫中，數據存儲在列中，而不是像大多數關係數據庫管理系統那樣存儲在行中。

列存儲由一個或多個列族組成，這些列族在邏輯上對數據庫中的某些列進行分組。 鍵用於標識和指向數據庫中的許多列，鍵空間屬性定義了該鍵的範圍。 每列包含名稱和值的元組，按順序排列並以逗號分隔。

列存儲對存儲的數據具有快速讀/寫訪問權限。 在列存儲中，對應於單個列的行存儲為單個磁盤條目。 這使得在讀/寫操作期間可以更快地訪問。

使用列存儲的最流行的數據庫包括 Google 的 BigTable、HBase 和 Cassandra。

圖基

在 Graph Base NoSQL 數據庫中，使用有向圖結構來表示數據。 該圖由邊和節點組成。

形式上，圖是一組對象的表示，其中一些對像對通過鏈接連接。 互連的對象由數學抽象表示，稱為頂點，連接一些頂點對的鏈接稱為邊。 一組頂點和連接它們的邊被稱為圖。

這說明了使用邊和節點來表示和存儲數據的圖基礎數據庫的結構。 這些節點是通過相互之間的某種關係組織起來的，這些關係由節點之間的邊表示。 節點和關係都有一些定義的屬性。

圖數據庫最常用於社交網絡應用程序。 圖數據庫允許開發人員更多地關注對象之間的關係，而不是對象本身。 在這種情況下，它們確實允許可擴展且易於使用的環境。

目前，InfoGrid 和 InfiniteGraph 是最流行的圖數據庫。

NoSQL 數據庫管理系統

對於數據庫的簡要比較，下表提供了不同 NoSQL 數據庫管理系統之間的簡要比較。

MongoDB 具有靈活的模式存儲，這意味著存儲的對像不一定需要具有相同的結構或字段。 MongoDB 還具有一些優化功能，可以分散數據集合，從而提高整體性能和更平衡的系統。

其他 NoSQL 數據庫系統，例如 Apache CouchDB，也是文檔存儲類型的數據庫，並且與 MongoDB 共享許多功能，但可以使用 RESTful API 訪問數據庫。

REST 是一種架構風格，由一組協調的架構約束組成，這些約束應用於萬維網中的組件、連接器和數據元素。 它依賴於無狀態、客戶端-服務器、可緩存的通信協議（例如，HTTP 協議）。

RESTful 應用程序使用 HTTP 請求來發布、讀取數據和刪除數據。

對於基於列的數據庫，Hypertable 是用 C++ 編寫的 NoSQL 數據庫，基於 Google 的 BigTable。

Hypertable 支持跨節點分佈數據存儲以最大化可擴展性，就像 MongoDB 和 CouchDB 一樣。

使用最廣泛的 NoSQL 數據庫之一是 Facebook 開發的 Cassandra。

Cassandra 是一個列存儲數據庫，包含許多旨在提高可靠性和容錯性的功能。

Cassandra 和 MongoDB 這兩個最廣泛使用的 NoSQL 數據庫管理系統將在接下來的小節中進行探討，而不是深入了解每個 NoSQL DBMS。

卡桑德拉

Cassandra 是 Facebook 開發的數據庫管理系統。

Cassandra 背後的目標是創建一個沒有單點故障並提供最大可用性的 DBMS。

Cassandra 主要是一個列存儲數據庫。 一些研究將 Cassandra 稱為混合系統，其靈感來自 Google 的 BigTable（列存儲數據庫）和 Amazon 的 DynamoDB（鍵值對數據庫）。

這是通過提供鍵值系統來實現的，但 Cassandra 中的鍵指向一組列族，依賴於 Google 的 BigTable 分佈式文件系統和 Dynamo 的可用性特性（分佈式哈希表）。

Cassandra 旨在存儲分佈在不同節點上的大量數據。 Cassandra 是一種 DBMS，旨在處理分佈在許多服務器上的海量數據，同時提供無單點故障的高可用性服務，這對於 Facebook 這樣的大型服務至關重要。

Cassandra 的主要特點包括：

• 沒有單點故障。 要實現這一點，Cassandra 必須在節點集群上運行，而不是在單台機器上運行。 這並不意味著每個集群上的數據都是一樣的，但管理軟件是一樣的。 當其中一個節點發生故障時，該節點上的數據將無法訪問。 但是，其他節點（和數據）仍然可以訪問。
• 分佈式哈希是一種提供哈希表功能的方案，其方式是添加或刪除一個槽不會顯著改變鍵到槽的映射。 這提供了根據容量將負載分配到服務器或節點的能力，進而最大限度地減少停機時間。
• 客戶端界面比較好用。 Cassandra 使用 Apache Thrift 作為其客戶端界面。 Apache Thrift 提供了一個跨語言的 RPC 客戶端，但大多數開發人員更喜歡構建在 Apple Thrift 之上的開源替代品，例如 Hector。
• 其他可用性功能。 Cassandra 的功能之一是數據複製。 基本上，它將數據鏡像到集群中的其他節點。 例如，複製可以是隨機的，也可以是特定的，以通過放置在不同數據中心的節點中來最大限度地保護數據。 Cassandra 中的另一個特性是分區策略。 分區策略決定將密鑰放置在哪個節點上。 這也可以是隨機的或有序的。 當使用這兩種類型的分區策略時，C​​assandra 可以在負載平衡和查詢性能優化之間取得平衡。
• 一致性。 複製等功能使一致性具有挑戰性。 這是因為所有節點必須在任何時間點以最新值或在觸發讀取操作時保持最新。 但最終，Cassandra 試圖通過向開發人員提供這種可定制性來保持複製操作和讀/寫操作之間的平衡。
• 讀/寫操作。 客戶端向單個 Cassandra 節點發送請求。 節點根據複製策略將數據存儲到集群中。 每個節點首先在提交日誌中執行數據更改，然後隨著更改更新表結構，兩者都是同步完成的。 讀取操作也非常相似，讀取請求被發送到單個節點，該單個節點根據分區/放置策略確定哪個節點保存數據。

MongoDB

MongoDB 是一個用 C++ 編寫的無模式、面向文檔的數據庫。 數據庫是基於文檔存儲的，這意味著它以編碼數據的形式存儲值（稱為文檔）。

MongoDB 中編碼格式的選擇是 JSON。 這很強大，因為即使數據嵌套在 JSON 文檔中，它仍然是可查詢和可索引的。

以下小節描述了 MongoDB 中可用的一些關鍵特性。

碎片

分片是跨多台機器（節點）對數據進行分區和分佈。 分片是 MongoDB 節點的集合，而 Cassandra 的節點是對稱分佈的。 使用分片還意味著能夠跨多個節點進行水平擴展。 如果有一個應用程序使用單個數據庫服務器，它可以轉換為分片集群，只需對原始應用程序代碼進行很少的更改，因為分片的方式是由 MongoDB 完成的。 經常軟件幾乎完全與暴露給客戶端的公共 API 解耦。

Mongo 查詢語言

如前所述，MongoDB 使用 RESTful API。 要從 db 集合中檢索某些文檔，需要創建一個查詢文檔，其中包含所需文檔應匹配的字段。

行動

在 MongoDB 中，有一組稱為路由器的服務器。 每個都充當一個或多個客戶端的服務器。 同樣，集群包含一組稱為配置服務器的服務器。 每個人都擁有一份元數據副本，指示哪個分片包含哪些數據。 讀取或寫入操作從客戶端發送到集群中的一個路由器服務器，並由該服務器在配置服務器的幫助下自動路由到包含數據的適當分片。

與 Cassandra 類似，MongoDB 中的分片具有數​​據複製方案，該方案為每個分片創建一個副本集，其中包含完全相同的數據。 MongoDB中有兩種副本方案：Master-Slave複製和Replica-Set複製。 Replica-Set 提供了更多的自動化和更好的故障處理，而 Master-Slave 有時需要管理員干預。 無論複製方案如何，在副本集中的任何時間點，只有一個分片充當主分片，所有其他副本分片都是輔助分片。 所有寫入和讀取操作都轉到主分片，然後均勻分佈（如果需要）到集合中的其他輔助分片。

在下圖中，我們看到了上面解釋的 MongoDB 架構，以綠色顯示路由器服務器，以藍色顯示配置服務器，以及包含 MongoDB 節點的分片。

需要注意的是，MongoDB 中的分片（或在分片之間共享數據）是完全自動化的，這降低了故障率，使 MongoDB 成為一個高度可擴展的數據庫管理系統。

NoSQL 數據庫的索引結構

索引是將鍵與 DBMS 中相應數據記錄的位置相關聯的過程。 NoSQL 數據庫中使用了許多索引數據結構。 以下部分將簡要討論一些更常見的方法； 即B-Tree索引、T-Tree索引和O2-Tree索引。

B樹索引

B-Tree 是 DBMS 中最常見的索引結構之一。

在 B 樹中，內部節點可以在某個預定義範圍內具有可變數量的子節點。

與其他樹結構（例如 AVL）的一個主要區別是 B-Tree 允許節點具有可變數量的子節點，這意味著更少的樹平衡但更多的空間浪費。

B+-Tree 是 B-Tree 最流行的變體之一。 B+-Tree 是對 B-Tree 的改進，它要求所有的鍵都駐留在葉子中。

T-樹索引

T-Trees 的數據結構是結合 AVL-Trees 和 B-Trees 的特徵設計的。

AVL-Trees 是一種自平衡二叉搜索樹，而 B-Trees 是不平衡的，每個節點可以有不同數量的子節點。

在 T-Tree 中，其結構與 AVL-Tree 和 B-Tree 非常相似。

每個節點存儲多個 {key-value, pointer} 元組。 此外，二進制搜索與多元組節點結合使用以產生更好的存儲和性能。

T-Tree 具有三種類型的節點：具有左右子節點的 T-Node、沒有子節點的葉節點和只有一個子節點的半葉節點。

相信 T-Trees 比 AVL-Trees 具有更好的整體性能。

O2-樹索引

O2-Tree 基本上是對紅黑樹的改進，紅黑樹是二叉搜索樹的一種形式，其中葉節點包含 {key value, pointer} 元組。

O2-Tree 被提出來提高當前索引方法的性能。 一個 m 階 (m ≥ 2) 的 O2-Tree，其中 m 是樹的最小度數，滿足以下性質：

• 每個節點不是紅色就是黑色。 根是黑色的。
• 每個葉節點都是黑色的，由一個包含“鍵值，記錄指針”對的塊或頁面組成。
• 如果一個節點是紅色的，那麼它的兩個子節點都是黑色的。
• 對於每個內部節點，從節點到後代葉節點的所有簡單路徑都包含相同數量的黑色節點。 每個內部節點都有一個鍵值。
• 葉節點是具有 ⌈m/2⌉ 和 m 個“鍵值、記錄指針”對的塊。
• 如果一棵樹只有一個節點，那麼它一定是葉子，它是樹的根，它可以有 1 到 m 個關鍵數據項。
• 葉節點在向前和向後方向上是雙重鏈接的。

在這裡，我們看到了 O2-Tree、T-Tree、B+-Tree、AVL-Tree 和 Red-Black Tree 之間的直接性能比較：

使用的 T-Tree、B+-Tree 和 O2-Tree 的順序是 m = 512。

記錄搜索、插入和刪除操作的時間，對於 50M 記錄的索引，更新率在 0%-100% 之間變化，這些操作導致向索引添加另外 50M 記錄。

很明顯，在 0-10% 的更新率下，B-Tree 和 T-Tree 的性能優於 O2-Tree。 然而，隨著更新率的增加，O2-Tree 索引的性能明顯優於大多數其他數據結構，其中 B-Tree 和 Red-Black Tree 結構受到的影響最大。

NoSQL 的案例？

快速介紹 NoSQL 數據庫，重點介紹傳統關係數據庫的不足之處，引出第一個要點：

雖然關係數據庫提供了一致性，但它們並未針對頻繁存儲和處理大量數據的應用程序的高性能進行優化。

NoSQL 數據庫因其高性能、高可擴展性和易於訪問而廣受歡迎； 但是，它們仍然缺乏提供一致性和可靠性的功能。

幸運的是，許多 NoSQL DBMS 通過提供新功能來增強可擴展性和可靠性來應對這些挑戰。

並非所有 NoSQL 數據庫系統的性能都比關係數據庫好。

MongoDB 和 Cassandra 在寫入和刪除操作方面的性能與關係數據庫相似，並且在大多數情況下更好。

存儲類型與 NoSQL DBMS 的性能之間沒有直接關聯。 NoSQL 實現會發生變化，因此性能可能會有所不同。

因此，應始終使用最新版本的數據庫軟件更新不同研究中跨數據庫類型的性能測量，以使這些數字準確。

雖然我無法對性能做出明確的判斷，但請記住以下幾點：

• 傳統的 B-Tree 和 T-Tree 索引在傳統數據庫中普遍使用。
• 一項研究通過結合多個索引結構的特徵來提出 O2-Tree，從而提供了改進和增強。
• 在大多數測試中，O2-Tree 的性能都優於其他結構，尤其是在具有龐大數據集和高更新率的情況下。
• 在本文介紹的所有索引結構中，B-Tree 結構的性能最差。

可以而且應該做進一步的工作來增強 NoSQL DBMS 的一致性。 NoSQL 和關係數據庫這兩個系統的集成是一個需要進一步探索的領域。

最後，重要的是要注意 NoSQL 是對現有數據庫標準的一個很好的補充，但有一些重要的警告。 NoSQL 以可靠性和一致性特性換取純粹的性能和可擴展性。 這使它成為一個專門的解決方案，因為可以依賴 NoSQL 數據庫的應用程序數量仍然有限。

好處？ 專業化可能不會提供太多的靈活性，但是當您想盡可能快速有效地完成專業化工作時，您不需要瑞士軍刀。 你需要 NoSQL。