NoSQL生態系統——相似Bigtable列存儲，或者Dynamo的key存儲（kv存儲如BDB，結構化存儲如redis，文檔存儲如mongoDB）

摘自：http://www.ituring.com.cn/article/4002#

NoSQL系統的數據操做接口應該是非SQL類型的。但在NoSQL社區，NoSQL被賦予了更具備包容性的含義，其意爲Not Only SQL，即NoSQL提供了一種與傳統關係型數據庫不太同樣的存儲模式，這爲開發者提供了在關係型數據庫以外的另外一種選擇。

在關聯型的數據模型中，在現實世界中的不一樣類型的個體被存儲在不一樣的表裏。好比有一個專門存員工的員工表，有一個專門存部門的部門表。簡單的查詢操做，好比查詢符合某個條件的全部行（例：employeeid = 3, 或者 salary > $20000）。更復雜一些的任務會讓數據庫作一些額外的工做，好比跨表的聯合查詢（例：查出3號員的部門名稱是什麼）。一些複雜的查詢，好比統計操做（例：算出全部員工的平均工資），甚至可能會致使全表掃描。

表結構的定義規定了表中每一行數據的存儲內容。若是你的數據結構化並無那麼強，或者對每一行數據的要求比較靈活，那可能關聯型的數據模型就太過嚴格了。

NoSQL運動受到了不少相關研究論文的啓示，這全部論文中，最核心的有兩個。 Google的BigTable[CDG+06]提出了一種頗有趣的數據模型，它將各列數據進行排序存儲。數據值按範圍分佈在多臺機器，數據更新操做有嚴格的一致性保證。 Amazon的Dynamo[DHJ+07]使用的是另一種分佈式模型。Dynamo的模型更簡單，它將數據按key進行hash存儲。其數據分片模型有比較強的容災性，所以它實現的是相對鬆散的弱一致性：最終一致性。 接下來咱們會深刻介紹這些設計思想，而實際上在現實中這些思想常常是混搭使用的。好比像HBase及其它一些NoSQL系統他們在設計上更接受BigTable的模型，而像Voldemort 系統它就和Dynamo更像。同時還有像Cassandra這種兩種特性都具有的實現（它的數據模型和BigTable相似，分片策略和一致性機制和Dynamo相似）。

NoSQL系統捨棄了一些SQL標準中的功能，取而代之的是一些簡單靈活的功能。NoSQL 的構建思想就是儘可能簡化數據操做，儘可能讓操做的執行效率可預估。在不少NoSQL系統裏，複雜的操做都是留給應用層來作的，這樣的結果就是咱們對數據層進行的操做獲得簡化，讓操做效率可預知。 NoSQL系統不只捨棄了不少關係數據庫中的操做。它還可能不具有關係數據庫如下的一些特性：好比一般銀行系統中要求的事務保證，一致性保證以及數據可靠性的保證等。事務機制提供了在執行多個命令時的all-or-nothing保證。一致性保證了若是一個數據更新後，那麼在其以後的操做中都能看到這個更新。可靠性保證若是一個數據被更新，它就會被寫到持久化的存儲設備上（好比說磁盤），而且保證在數據庫崩潰後數據可恢復。 經過放寬對上述幾點特性的要求，NoSQL系統能夠爲一些非銀行類的業務提供以性能換穩定的策略。而同時，對這幾點要求的放寬，又使得NoSQL系統可以輕鬆的實現分片策略，將遠遠超出單機容量的大量數據分佈在多臺機器上的。

數據庫的數據模型指的是數據在數據庫中的組織方式，數據庫的操做模型指的是存取這些數據的方式。一般數據模型包括關係模型、鍵值模型以及各類圖結構模型。操做語言可能包括SQL、鍵值查詢及MapReduce等。

13.2.1 基於key值存儲的NoSQL數據模型

Key-Value 存儲

Key-Value存儲能夠說是最簡單的NoSQL存儲。每一個key值對應一個任意的數據值。對NoSQL 系統來講，這個任意的數據值是什麼，它並不關心。好比在員工信念數據庫裏，exployee:30 這個key對應的可能就是一段包含員工全部信息的二進制數據。這個二進制的格式多是Protocol Buffer、Thrift或者Avro都無所謂。 若是你使用上面說的Key-Value存儲來保存你的結構化數據，那麼你就得在應用層來處理具體的數據結構：單純的Key-Value存儲是不提供針對數據中特定的某個屬性值來進行操做。一般它只提供像set、get和delete這樣的操做。以Dynamo爲原型的Voldemort數據庫，就只提供了分佈式的Key-Value存儲功能。BDB 是一個提供Key-Value操做的持久化數據存儲引擎。

Key - 結構化數據 存儲

Key - 結構化數據存儲，其典型表明是Redis，Redis將Key-Value存儲的Value變成告終構化的數據類型。Value的類型包括數字、字符串、列表、集合以及有序集合。除了set/get/delete 操做覺得，Redis還提供了不少針對以上數據類型的特殊操做，好比針對數字能夠執行增、減操做，對list能夠執行 push/pop 操做，而這些對特定數據類型的特定操做並無對性能形成多大的影響。經過提供這種針對單個Value進行的特定類型的操做，Redis能夠說實現了功能與性能的平衡。

Key - 文檔 存儲

Key - 文檔存儲的表明有CouchDB、MongoDB和Riak。這種存儲方式下Key-Value的Value是結構化的文檔，一般這些文檔是被轉換成JSON或者相似於JSON的結構進行存儲。文檔能夠存儲列表，鍵值對以及層次結構複雜的文檔。 MongoDB 將Key按業務分到各個collection裏，這樣以collection做爲命名空間，員工信息和部門信息的Key就被隔開了。CouchDB和Riak把類型跟蹤這種事留給了開發者去完成。文檔型存儲的靈活性和複雜性是一把雙刃劍：一方面，開發者能夠任意組織文檔的結構，另外一方面，應用層的查詢需求會變得比較複雜。

BigTable 的列簇式存儲

HBase和Cassandra的數據模型都借鑑自Google 的BigTable。這種數據模型的特色是列式存儲，每一行數據的各項被存儲在不一樣的列中（這些列的集合稱做列簇）。而每一列中每個數據都包含一個時間戳屬性，這樣列中的同一個數據項的多個版本都能保存下來。 列式存儲能夠理解成這樣，將行ID、列簇號，列號以及時間戳一塊兒，組成一個Key，而後將Value按Key的順序進行存儲。Key值的結構化使這種數據結構可以實現一些特別的功能。最經常使用的就是將一個數據的多個版本存成時間戳不一樣的幾個值，這樣就能很方便的保存歷史數據。這種結構也能自然地進行高效的鬆散列數據（在不少行中並無某列的數據）存儲。固然，另外一方面，對於那些不多有某一行有NULL值的列，因爲每個數據必須包含列標識，這又會形成空間的浪費。 這些NoSQL系統對BigTable數據模型的實現多少有些差異，這其中以Cassandra進行的變動最爲顯著。Cassandra引入了超級列（supercolumn）的概念，經過將列組織到相應的超級列中，能夠在更高層級上進行數據的組織，索引等。這一作法也取代了locality groups的概念（這一律唸的實現可讓相關的幾個行的數據存儲在一塊兒，以提升存取性能）。

13.2.2 圖結構存儲

圖結構存儲是NoSQL的另外一種存儲實現。圖結構存儲的一個指導思想是：數據並不是對等的，關係型的存儲或者鍵值對的存儲，可能都不是最好的存儲方式。圖結構是計算機科學的基礎結構之一，Neo4j和HyperGraphDB是當前最流行的圖結構數據庫。

 

未完待續！