NoSQL是什麼？NoSQL提供了新的資料管理技術，旨在應對資料數量、速度和種類與日俱增的態勢。它可以儲存和檢索資料，能夠以關係資料庫中所用的表格式關係之外的方式來建立模型。

NoSQL系統又叫“Not only SQL”，強調這一事實：它們還支援類似SQL的查詢語言。

我們為什麼需要NoSQL？

關係資料庫面臨下列挑戰：

• 並不適用於資料型別多樣化（比如影象、視訊和文字）的大量（PB級）資料。

• 無法擴充套件、支援龐大的資料量。

• 無法縱向擴充套件，受制於記憶體和處理器的功能。

• 無法橫向擴充套件，受制於依賴快取的讀取和寫入操作。

• 分片（將資料庫分成幾個部分，儲存在不同的節點）引起操作問題（比如管理共享式故障）。

• 複雜的RDBMS模型

• 一致性限制了RDBMS的可擴充套件性。

相比關係資料庫，NoSQL更具有可擴充套件性，並提供了出色的效能。NoSQL資料庫提供了下列解決方案，從而克服了關係模型無法克服的挑戰：

• 橫向擴充套件、什麼都不共享的架構，能夠在大量節點上執行。

• 非鎖定併發性控制機制，那樣實時讀取不會與寫入產生衝突。

• 可擴充套件的複製和分發――成千上萬個機器擁有分散式資料。

• 每個節點提供的效能高於RDBMS的架構。

• 無模式（schema-less）資料模型。

HBase：

寬列式資料庫，基於Apache Hadoop和BigTable的概念。

Apache HBase是一種NoSQL鍵/值儲存系統，它在Hadoop分散式檔案系統（HDFS）上執行。不像Hive，HBase操作在資料庫上，而不是MapReduce作業上實時執行。HBase分成表，表又細分成列族（column family）。列族必須在模式中加以宣告，它將某一組列（列不需要模式定義）分為小組。比如說，“message”列族可能包括以下這幾列：“to”、“from”、“date”、“subject”和“body”。HBase中的每個鍵/值對被定義為一個單元（cell），每個鍵含有行鍵、列族和時間戳。HBase中的行是一組鍵/值對映，由行鍵來識別。HBase可以使用Hadoop的基礎設施，並使用現成伺服器實現橫向擴充套件。

HBase的工作方式是，將資料儲存為鍵/值。它支援四種主要的操作：新增或更新行的put，檢索一組單元的scan，返回某個指定行的單元的get，以及從表上刪除行、列或列版本的delete。擁有版本控制功能，那樣可以獲取資料的之前值（歷史記錄可以通過HBase壓縮時不時刪除，以釋放空間）。雖然HBase包括表，但只有表和列族才需要模式，列不需要模式，它還包括增量/計數器功能。

HBase查詢用一種需要學習的自定義語言來編寫。可以通過Apache Phoenix，獲得類似SQL的功能，不過其代價是需要維護模式。此外，HBase並不完全符合ACID，不過它確實支援某些屬性。最後但並非最不重要的是，為了執行HBase，就需要ZooKeeper――這是面向分散式協調的伺服器，比如配置、維護和命名。

HBase最適合大資料的實時查詢。Facebook將它用於訊息傳遞和實時分析。Facebook甚至將它用於計數Facebook點贊。

Hbase有集中式架構， Master伺服器負責監控叢集中的所有RegionServer（負責服務和管理區域）例項，它也是檢視所有元資料變化的介面。它提供了CAP原理中的CP（一致性和可用性）。

HBase針對讀取操作進行了優化，得到單次寫入master的支援，支援因而獲得的嚴格一致性模型，以及使用支援行掃描的順序分割槽（Ordered Partitioning）。HBase很適合執行基於範圍的掃描。

• 線性可擴充套件性，支援大表和範圍掃描－－由於順序分割槽，HBase很容易橫向擴充套件，同時仍支援行鍵範圍掃描。

• 輔助索引－－Hbase並不直接支援輔助索引，但觸發器的一個使用場合是，“put”方面的觸發器會自動確保輔助索引是最新版本，因而並不給應用程式（客戶端）新增負擔。

• 簡單聚合－－Hbase Co Processors支援HBase中的即開即用的簡單聚合。SUM、MIN、MAX、AVG和STD。如果定義java類，就可以構建其他聚合，從而執行聚合操作。

實際應用：Facebook Messanger

Cassandra:

寬列式資料庫，基於BigTable和DynamoDB的概念。

Apache Cassandra是一種主要的NoSQL分散式資料庫管理系統，它支撐著如今的許多現代商務應用系統，它提供了持續可用性、高擴充套件性和高效能、強安全性和操作簡單性，同時降低了總體擁有成本。

Cassandra擁有分散式架構。任何節點都能執行任何操作。它提供了CAP原理中的AP（可用性和分割槽可容忍性）。

Cassandra擁有出色的單行讀取效能，只要最終的一致性語義足以滿足使用場合的需要。Cassandra quorum讀取是嚴格一致性所需要的，它自然不如Hbase讀取來得快。Cassandra不支援基於範圍的行掃描，這在某些使用場合可能具有侷限性。Cassandra很適合支援單行查詢，或者基於列值索引選擇多行。

如果資料儲存在Cassandra中的列裡面以支援範圍掃描，Cassandra中行大小的實際限制是10MB。大於這個數的行會在壓縮開銷和時間方面引起問題。

Cassandra支援列族輔助索引，其中列的名稱已知（但不支援動態列）。

• Cassandra中的聚合並不受到Cassandra節點的支援――客戶端必須提供聚合機制。聚合需求橫跨多個行時，隨機分割槽（Random Partitioning）使得聚合對客戶端來說很難。建議使用Storm或Hadoop用於聚合。

實際應用：Twitter

MongoDB：

最流行的文件資料庫之一。

它是一種面向文件的資料庫。Mongodb中的所有資料以JSON/BSON格式來處理。它是一種無模式資料庫，資料庫中的資料量超過TB級。它還支援主從複製方法，以便在伺服器上覆制資料的多個副本，從而使得某些應用系統中的資料整合來得更容易、更快速。

MongoDB結合了關係資料庫的優點和NoSQL技術的創新，讓工程師能夠構建現代應用。

MongoDB保留了關係資料庫最寶貴的功能特性：強一致性、表示式查詢語言和輔助索引。因而，開發人員能夠以比NoSQL資料庫更快的速度來構建高度實用的應用程式。

MongoDB提供了NoSQL資料庫的資料模型靈活性、彈性可擴充套件性以及高效能。因而，工程師可以不斷改進應用，並且可以在商用硬體上實現幾乎無限制的可擴充套件性。

支援全索引，以實現高效能

實際應用：FourSquare

HBase、Cassandra和MongoDB三大NoSQL資料庫的比較

HBase：

主要特點：

• 分散式和可擴充套件的龐大資料儲存系統

• 強一致性

• 建立在Hadoop HDFS的基礎上

• CAP中的CP

適合於：

• 針對讀取進行了優化

• 很適合基於範圍的掃描

• 嚴格一致性

• 快速讀取和寫入，具有可擴充套件性

不適合於：

• 典型的事務型應用程式或甚至關係分析

• 應用程式需要全表掃描

• 資料需要跨聚合、累積以及跨行分析。

使用場合：Facebook訊息

Cassandra:

主要特點：

• 高可用性

• 逐步可擴充套件性

• 最終一致性

• 兼顧一致性和延遲

• 最小化管理

• 沒有單一故障點――Cassandra中所有節點都一樣

• CAP中的AP

適合於：

• 簡單的安裝，維護節點

• 快速隨機性讀取/寫入

• 靈活的解析/寬列需求

• 不需要多個輔助索引

不適合於：

• 輔助索引

• 關係資料

• 事務型操作（回滾和提交）

• 主記錄/財務記錄

• 對資料需要嚴格的授權

• 針對列資料的動態查詢/搜尋

• 低延遲

使用場合：Twitter和Travel入口網站

MongoDB：

主要特點：

• 應用程式完善後，模式隨之變化（無模式）

• 支援全索引，實現高效能

• 複製和故障切換，實現高可用性

• 自動分片，易於擴充套件

• 基於豐富文件的查詢，易於讀取

• 主從模式

• CAP中的CP

適合於：

• 取代Web應用的RDBMS

• 半結構化內容管理

• 實時分析和高速日誌、快取和高擴充套件性

• Web 2.0、媒體、SaaS和遊戲

不適合：

• 高度事務型系統

• 存在傳統資料庫需求的應用程式，比如外來鍵約束。

使用場合：Craigslist和Foursquare

效能基準測試：

結論

沒有結論。本博文不是要評選誰是最佳NoSQL資料庫，而是重在比較這三款資料庫。它們各有優缺點，想真正比較一番，你就需要在生產環境下，在負載相當大的情況下長期執行一番，才會有實際感受。