這篇文章的內容是摘自《Introducing Data Science》，我們在這裏將要想大家介紹四種NoSQL數據庫的類型，堅持讀下去你會獲得更多有用的信息。
目前對於非關係型數據庫主要有四種數據存儲類型：鍵值對存儲（key-value），文檔存儲（document store），基於列的數據庫（column-oriented），還有就是圖形數據庫（graph database）。每一種都會解決相應的問題，這些問題是關係型數據庫所不能解決的。而在實際應用中都會將這幾種情況結合起來實現相應的功能。例如：OrientDB就是一種多類型的數據庫，它整合了NoSQL的幾種存儲類型。OrientDB是一個圖形數據庫其每個節點都是一個文本。
在開始介紹NoSQL數據庫之前，我們先來回顧一下關係型數據庫，這樣我們可以對非關係數據庫和關係型數據庫做一個深入的比較。在數據建模上面，很多方法都是有可能被使用的。關係型數據庫會嚴格的按照標準化去建模（也就是常說的第一範式、第二範式、第三範式等等）：確保每一條數據都只被存儲一次。標準化是其結構設置的規範。例如：如果你想存儲一個人的信息和這個人的愛好這樣的數據，你可以創建兩個表：一個用來存儲這個人的信息，另一個表用來存儲這個人的愛好。正如你在圖一中看到的，你必須有一張額外的映射表，這張表將人的信息表和愛好表建立其對應的關係。這是因爲他們的關係是多對多的關係，一個人可以有多個愛好，並且多個人可能會有相同的愛好。
圖一
一個完整的關係型數據庫會由很多的實體表和關係映射表構成，現在你已經有了和NoSQL數據庫進行比較的東西了，下面讓我們看看這些不同的存儲類型。
基於列的數據庫（column-oriented）
傳統的關係型數據庫時基於行（row-oriented）的，每一行都帶有一個行id並且行中的每一個字段都存儲在一張表中。假如說上面的例子中沒有單獨用一張表來存儲人的愛好，我們僅用一張表來存儲個人信息和愛好，如圖二所示。這裏你就需要注意了，這種請款下你已經有一點違反關係型數據庫嚴格遵循的標準化了，因爲愛好是有重複的。如果愛好是描述一個人很好的一條額外信息但是對你的用例沒有什麼重要性，那你可以將其列在Hobbies這一列中，這是可以接受的一種方法。但是如果這條信息對你根本不重要，那這些數據還有沒有必要存呢？
圖二
在基於行的數據庫中進行查找的時候，每次都會對每一行進行遍歷，不管某一列數據是否是你需要的都會進行遍歷。假如你只需要生日是九月的人的數據，基於行的數據庫會對這張表從上到下從左至右遍歷一遍，正像你在圖三中看到的那樣，最後再返回你需要的那些數據。
圖三
對特定列的數據進行索引能有效的提高查找速度，但是索引每一列同樣會帶來額外的負載，並且數據庫同樣也是會遍歷所有的列來取得要查找的數據。
基於列的數據庫會將每一列分開單獨存放，當查找一個數量較小的列的時候其查找速度是很快的。其結構如圖四所示
圖四
這種設計看起來很像基於行的數據庫在每一列上都加了索引一樣。數據庫索引這種數據結構以犧牲存儲空間和更多的寫文件（索引更新）爲代價使查找速度得到提升。索引是將行號映射到數據上，而基於列數據庫是將數據映射到行號上面，這樣的方式用於計算是很簡單的。例如上面的例子，查找有多少人的愛好包含archery（箭術）是很容易計算出來的。除此之外將每一列單獨存放可以優化壓縮因爲每張表中只存一類數據。
說了這麼多，那應該在什麼時候使用基於行的數據庫，在什麼時候使用基於列的數據庫呢？在基於列的數據庫中要想增加一列新的數據是很容易的，因爲現有的那些列是不會受新增列的影響的。但是要想增加一整條記錄就需要適應所有的表，防止各個表的數據之間對應關係出現錯誤。因此這使得基於行的數據庫在事務處理的時候要優勝於基於列的數據庫，因爲它很好的實現了數據的實時更新。
基於列的數據庫的優勢在於分析數據和對數據形成一個報告方面，例如對值求和、計算整條記錄等。基於行的數據庫經常被應用於實際交易中（例如銷售業務）。夜間批處理作業就可以使基於列數據庫更新，並且還支持快速查找還有使用MapReduce技術聚合數據形成報告。現在使用基於列的數據庫存儲數據的有Apache HBase，Facebook’s Cassandra，Hypertable和grandfather of wide-column stores，Google BigTable。
鍵值對存儲（Key-Value Stores）
鍵值對的存儲方式在NoSQL數據庫中是最簡單的一種，其結構就像其名字所示，是一個key-value的集合。如圖五所示的那樣。這種方式在NoSQL數據庫類型中是最可擴展的一種類型，並且可以存儲大量的數據。
圖五
鍵值對中存儲的數據的類型是不受限制的，可以是一個字符串，也可以是一個數字，甚至是由一系列的鍵值對封裝成的對象等。圖六向我們展示了一個比較複雜的鍵值對結構。使用價值對存儲的數據庫有Redis，Voldemort，Riak，和Amazon’s Dynamo。
圖六
文檔存儲（Document Stores）
文檔存儲是基於鍵值對存儲的，其結構較之於鍵值對存儲更爲複雜，可以說在鍵值對的基礎上更深入了一步。文檔存儲是假定一個特定文檔的結構可以使用一種特定的模式來說明，它的出現較之於其他的NoSQL數據庫類型來說是最自然的，因爲設計這種方式的最初的目的就是用來存儲日常文檔的，並且這種方式支持對於那些通常已經聚合的數據進行復雜的查詢和計算。使用關係型數據庫存儲數據的方式在標準化的角度看是很有意義的：每條數據只被存儲一次並且通過外鍵來進行聯繫。文檔存儲不會去關心那些所謂的標準化，只要數據在該結構下是有意義的就可以。所以說關係型數據庫不能很好的適應特定企業的案例，只能用來做那些比較通用的案例。
例如：報紙和雜誌包含有文章，如果想在關係型數據庫中存儲這些文章，首先你需要將這些文章給拆分開來，文章的內容在一個表中，文章的作者以及關於作者的信息要存在另一張表中，對於發佈在網絡上的文章的評論也需要額外的一張表來存儲。正如圖七所展示的那樣，報紙上的一篇文章可以被存儲爲一個實例，這樣在處理那些總是被查看的數據時可以減少查找的時間。使用文檔存儲的NoSQL數據庫包含MongoDB和CouchDB。
圖七
圖形數據庫（Graph Database）
現在剩下的是最後一個NoSQL數據庫存儲類型，也是最複雜的一個，主要使用一種高效的方式來存儲各個實體之間的關係。當數據之間是緊密聯繫的，例如社會關係、科學論文的引文抑或是資本資產定價模型等等，使用圖形數據庫時最好的選擇。圖形或者網絡數據有兩部分組成：
Node-：實體本身，在一個社會關係中可以認爲是一個人。
Edge-：實體之間的關係。這個關係可以用一條線來表示，這條線有它自己的屬性。這條線可以有方向，箭頭可以表明誰是誰的上級。
如果給予足夠的關係和實體類型，圖形會變得非常的複雜，其發雜程度簡直難以置信。圖八已經展示了僅有有限幾個實體的複雜圖形。像Neo4j圖形數據庫聲稱支持ACID，然而文檔存儲數據庫和鍵值對數據庫堅持BASE。
圖八
非關係型數據庫的潛力是無限的，當今世界關係正變得越來越緊密，圖形存儲類型很可能會在地理上勝過其他的存儲類型數據庫，包括現在仍然佔絕對優勢的關係型數據庫。當今最流行的數據庫的排名和他們是如何發展的在http://db-engines.com/en/ranking中都可以找到。
圖九
圖九列出了在九條記錄中，關係型數據庫在寫這本書的時候在前15中仍然占主導地位。並且隨着NewSQL的出現，我們還沒有重新計算排名。Neo4j——當下最流行的圖形存儲數據庫，在寫本書的時候可以發現其處在23名的位置上，而Titan在53的位置上。