本文摘自 Introducing Data Science，我們將向您介紹四大NoSQL數據庫類型。

有四大NoSQL類型：鍵值存儲(key-value store)，文件存儲(document store)，列導向的數據庫(Column-Oriented Database)和圖形數據庫(graph database)。每種類型都解決了傳統關系數據庫無法解決的問題。實際的實現往往是這些組合的組合。例如，結合NoSQL類型，Orientdb是一個多模式的數據庫。Orientdb是圖形數據庫，每個節點都是一個文檔。

在進入不同的NoSQL數據庫之前，讓我們看看與關系數據庫之間的比較。傳統關系數據庫正在努力的走向規范化：確保每一個數據都只存儲一次。正規化標志著他們的結構設置。舉個例子來說，如果你想把一個人和他的愛好存儲為數據，那么你就可以建兩個表：一個表存儲為人，一個表存儲他們的愛好。如圖1所示，一個附加的表是必要的，因為他們存在著很多關系：一個人可以有多個愛好，然而一個愛好也可以有很多人喜歡。


一個全面的關系數據庫可以由許多實體和聯系表。現在讓我們看看NoSQL不同的類型的數據庫之間的比較。

Column databases store列存儲數據庫
行數據庫實際上就是傳統的關系數據庫，每一行有一行id，并在一個表中存儲的行中的每個字段。假設，關于愛好，沒有額外的表來存儲并且你只有一個表來描述人，如圖2所示。注意，在這種情況下，你有輕微的反規范化，因為愛好是可以重復的。如果愛好這個信息是一個額外的信息，但在你使用時并不是必不可少的，添加它作為一個列表內的愛好列是可以接受的方法。但是如果這些信息對一個單獨的表來說是不夠的，它應該被存儲在所有的？


每次你在行存據庫中尋找某個數據，進行每行掃描，不管你需要哪列。假設你只需要生日在9月的列表。數據庫將在表中從上到下和從左到右掃描所有數據，如圖3所示，最終返回生日列表。


索引數據在某些列可以顯著提高查詢速度，但索引每一列帶來額外的開銷和數據庫仍然是掃描所有列。

Column databases store分別存儲每一列，允許更快的掃描時，只涉及一小部分列。見圖4。


這個布局看起來很像一個以行為導向的數據庫，每一列都有一個索引。一個數據庫索引是一種數據結構，允許在存儲空間上快速查找數據和額外的寫(索引更新)。索引映射到數據的行數，而一個列數據庫將數據映射到行數，這樣計算變得更快，所以很容易看到有多少人喜歡射箭。例如，單獨存儲的列也可以優化壓縮，因為只有一個數據類型的表。

那么，何時該使用Row-Oriented Database和Column-Oriented Database呢？在Column-Oriented Database中，很容易添加另一個列，因為不受它的影響。但添加整個完整記錄需要調整所有的表。這使得Row-Oriented Database更好于Column-Oriented Database在聯機事務處理(OLTP)方面，因為他可以不斷地添加或更改記錄。

Column-Oriented Database在執行分析和報告時的表現: 求和值和計算條目。Row-Oriented Database通常是實際交易的操作數據庫(如銷售)。夜間批處理作業將用于數據庫更新，支持客戶快速查找和聚合使用MapReduce算法報告。例如column-family stores are Apache HBase、Facebook的Cassandra、Hypertable和the grandfather of wide-column stores、谷歌的 BigTable。

KEY-VALUE STORES 鍵值存儲
鍵值存儲是最復雜的NoSQL數據庫。顧名思義，鍵值對的集合，如圖5所示，這種簡單性使得他們成為最可伸縮的NoSQL數據庫類型，能夠存儲大量的數據。


鍵值存儲的值可以是任何東西：一個字符串，一個數字，而且也是一個新的鍵值對封裝在一個對象。如圖6顯示了一個稍微復雜鍵值結構。關鍵值存儲的例子有Redis、Voldemort、Riak和Amazon’s Dynamo。

{"internal data":[{"entities":[         {"customer":[            {"id:1,"name":"Freddy"},            {"id:2,"name":"Fritz"}          }],          {"legal entities":[               {"id":1,"company":"Maiton"}           ]}]},{"Products":[     {"furniture":[         {"id" :1,"name":"Octopus Table","stock":1}      ]}]}]}                   

DOCUMENT STORES 文檔存儲
文檔存儲是鍵值存儲的復雜性的一個步驟：一個文檔存儲庫確實假定一個特定的文檔結構，可以用一個模式來指定。文檔存儲出現最自然的NoSQL數據庫類型中，因為它們用于存儲日常文檔，并且他們允許復雜的查詢和計算，這往往已經成為聚合形式的數據。在關系數據庫中存儲的方式是從一個正常化的角度來看，所有的一切都應該存儲一次，并通過外鍵連接。文件存儲的關心小的正常化，只要數據是在一個結構是有意義的。關系數據模型并不總是適合某些業務案例。

報紙或雜志，例如，包含文章。要把這些存儲在關系數據庫中，首先要把它們切碎：這篇文章正文在一個表中，作者和作者所有的信息，以及在一個網站上發表的文章的評論。如圖7所示，報紙上一篇文章也可以存儲為一個單一的實體，這降低了對于習慣看到文章內容所消耗的時間。文檔存儲以MongoDB和CouchDB為例子。


GRAPH DATABASES 圖數據庫
最后一個大的NoSQL數據庫類型是最復雜的一個，為了高效地存儲實體之間的關系。數據是高度互聯的，如社會網絡，科學論文引用，或資本資產集群，圖形數據庫的答案。圖或網絡數據主要有2個組成部分：

節點：實體本身。在社交網絡中，這可能是人。

邊：實體間的關系。這種關系用一條線來表示，并且有它自己的特性。邊可以有一個方向，例如，如果箭頭表示誰是誰的老板。

圖可以變的非常復雜來給定足夠的關系和實體類型。圖8已經表明了復雜性，只有有限數量的實體。圖數據庫像Neo4j還聲稱堅持ACID，而文檔存儲和鍵值存儲堅持BASE。


這個可能性是無限的，因為世界正變得越來越互聯，Graph databases可能會贏過其他類型的數據庫，包括如今仍然占主導地位的關系數據庫。排名最受歡迎的數據庫和他們是如何進展可以點擊：最新數據庫排名

原文鏈接：NoSQL Database Types