在學習不同NoSQL系統的特性之前，了解一下NoSQL的發展史總不會錯的;用一句話來說，NoSQL是天生的反派!

天生的反派NoSQL

這里我們不妨把NoSQL比作No SQL，它必須站在RDBMS的對立面，這里不妨通過邏輯流來解釋一下這個觀點：

RDBMS通過匹配關系數據(關系和表格)的數據操作方法定義SQL語言，并且支持ACID特性的事務。

橫向擴展在數據處理前就會進行分配，用以滿足網絡服務的高吞吐量需求。當下RDBMS橫向擴展的更趨向于維護關系模型的作業完整性，這和事務操作構成了RDBMS的核心。

然而在維護完整性的同時進行擴展是非常難得的，而在分配和復制數據時會出現類似的問題。所以在進行橫向擴展之前，必須保證通過DBMS實現的基于ACID事務特性不那么嚴格，當然還有復制完整性也不能那么嚴格。

RDBMS的橫向擴展

對RDBMS進行擴展是很難的。如果只是擴展到幾千規模是很輕松的，類似Oracle 這樣領先的數據庫開發機構在很早之前就發布了一兩個這樣的產品。

這里不妨假設將RDBMS中的表格分配到幾臺主機上，而為了高可用性每份數據都會在存儲前都會被復制。首先，在保證ACID進行擴展時執行分配操作就非常困難。

想實現ACID中的原子性，執行某個事務時，類似2PC這樣的分布事務協議必須在所有系統中使用。

為了滿足ACID特性中的隔離級別，數據通常都會被加鎖。鎖的級別可以是一條記錄，一個表格或者是一個索引。

因此，為了在分布式環境中滿足原子性和隔離需求，因此在分布式事務協議的處理期間，每個系統都會加上所有相關的鎖;系統的負載越大，鎖的競爭越繁重。這就是很難擴展的原因。

另一個橫向擴展中必須面臨的問題就是數據的復制和分配。

事務性復制使用了2PC方法，這里存在的問題就是：當與某個復制事務相關的任何系統出故障時，這個事務就會失敗并變得不可用。此外，當復制事務同時涉及幾個系統時，性能就會降低。

作為替代，將一個DBMS的WAL(Write Ahead Logging，預寫式日志)數據傳送給備份系統并讓它使用。節點可以配置為master-slave或multi-master方式。

當使用master-slave類型時：這也是最常見的復制方法。復制過程的速度與系統中的從節點數量成反比。

當使用multi-master配置時：當同時存在幾個主節點時，處理數據寫入進程間的沖突是非常困難的，并且很難阻止這個情況發生。在《The Danagers of Replication and a Solution》一書中(曾獲1998年圖靈獎)，Jim Gray對這個問題進入了深入研究。

通過開發者分片

通常來說，在滿足ACID特性的數據庫中進行擴展是非常難的。基于這個原因，對數據進行擴展，這個數據庫本身就必須擁有簡單的模型，將數據分割為N片，然后在單獨的片中執行查詢。

數據分割的單元被稱為“shard”。將N片數據分配個M個DBMS進行操作。DBMS并不會去管理數據片，這需由服務開發者自行完成。

分片的方法由開發者決定，這里同樣會有幾個問題：

首先，分片必須被定義。

其次，分片映射：

RDBMS的基本儲存單元是表格。鑒于一個表格可能會包含一個或多個分片，這里需要明白分片需要被映射到的數據庫實例。應用程序也必須知道分片表格對應的位置。

***，分片的分配和重分配：

鑒于吞吐量需求和數據體積，每個分片都不同。所以開發者必須從數據庫中增加或者刪除一個實例，并且手動重分配分片。這個過程非常繁瑣。同時在這個過程中，修改的映射信息必須告知應用程序。數據修改后，還必須做相應的管理(比如，針對復制的配置)。