NoSQL數據庫在整個數據庫領域的江湖地位已經不言而喻。在大數據時代，雖然RDBMS很優秀，但是面對快速增長的數據規模和日漸復雜的數據模型，RDBMS漸漸力不從心，無法應對很多數據庫處理任務，這時NoSQL憑借易擴展、大數據量和高性能以及靈活的數據模型成功的在數據庫領域站穩了腳跟。

目前大家基本認同將NoSQL數據庫分為四大類：鍵值存儲數據庫，文檔型數據庫，列存儲數據庫和圖形數據庫，其中每一種類型的數據庫都能夠解決關系型數據不能解決的問題。在實際應用中，NoSQL數據庫的分類界限其實沒有那么明顯，往往會是多種類型的組合體，例如OrientDB就是兼具文檔數據庫的靈活性和圖形數據庫管理鏈接能力的文檔-圖形數據庫管理系統，它是圖形數據庫，但其中每個節點又都是文檔。

在正式介紹NoSQL數據庫之前，我們先來看看關系型數據庫，關系型數據庫正努力向規范化看齊，確保每個數據塊只存儲一次，例如你要存儲一個人的信息和他的興趣愛好，這時你需要建立兩個表來分別存儲基本信息和興趣愛好。從下圖我們可以看出，除了這兩個表之外，還需另外建立一個表把這兩個表關聯起來，

信息表和愛好表之間的關系是多對多，一個人可以有多個興趣愛好，一個興趣愛好也可以有多個人來練習。

　　列存儲數據庫

傳統的關系數據庫是行存儲的，每行具有一個行id，并且行中的每個字段存儲在表中。 比方說，如果你要查詢一個人的興趣愛好時，這時你需要將信息表和愛好表關聯起來，如下圖所示，請注意在這種情況下你有輕微的反規范化，因為愛好可以重復。 如果愛好信息只是一個額外的信息，并不是你的用例的必要條件，那么把它作為一列添加到表中也未嘗不可。但如果某個信息的重要性不足以單獨建立一個表，那么它還應該建表存儲嗎?

在基于行存儲的數據庫中查詢時，無論你需要哪一列都需要將每一行掃描完。假設你想要在下圖中的生日列表中查詢9月份生日，數據庫將會從上到下和從左到右掃描表，最終返回生日為9月的列表。

如果給某些特定列建索引，那么可以顯著提高查找速度，但是索引會帶來額外的開銷，數據庫仍在掃描所有列。

而基于列存儲的數據庫可以分別存儲每個列，從而可以在列數較少的情況下更快速地進行掃描;

上圖的布局看起來和行存儲的數據庫很相似，每一列都有一個索引。數據庫索引是一種數據結構，允許以存儲空間和額外寫入(索引更新)為代價快速查找數據。 索引將行號映射到數據，列數據庫將數據映射到行號，采用這種方式計數變得更快，很容易就可以查詢到某個項目的愛好人數，并且每個表都只有一種數據類型，所以單獨存儲列也利于優化壓縮。

那么什么時候適合使用行存儲數據庫，什么時候有適合使用列存儲數據庫呢?列存儲數據庫能夠在其他列不受影響的情況下，輕松添加一列。 在面向列的數據庫中，很容易添加另一列，但是如果要添加一條記錄時那么就需要訪問所有表。所以行存儲數據庫要比列存儲數據庫適合聯機事務處理過程(OLTP)，因為OLTP要頻繁的進行記錄的添加或修改。

列存儲數據庫更適合執行分析操作，如進行匯總或計數。實際交易的事務如銷售類的通常會選擇行存儲數據庫，列存儲數據庫采用高級查詢執行技術以簡化的方法處理列塊(稱為“批處理”)，從而減少CPU使用率，支持MapReduce算法。

鍵值存儲數據庫

鍵值存儲數據庫是NoSQL數據庫中最簡單的，顧名思義，它是一個鍵值對的集合，能夠存儲大量數據，它的這種簡單性也讓它成為NoSQL中最具擴展性的數據庫類型。

▲鍵值存儲將所有內容存儲為鍵和值。

鍵值存儲中的值可以是任何值，字符串、數字，甚至還可以是封裝在對象中的新的鍵值對，下圖是較為復雜的鍵值結構：

▲鍵值嵌套結構。

文檔型數據庫

文檔存儲是鍵值存儲的復雜性的一個步驟：文檔存儲庫可以使用模式來指定某個文檔結構。文檔存儲是NoSQL數據庫類型中出現的最自然的類型，因為它們是按照日常文檔的存儲來設計的，并且允許對這些數據進行復雜的查詢和計算。從關系數據庫存儲方式的角度來看，每一個事物都應該存儲一次，并且通過外鍵連接。而文件存儲不關心規范化，只要數據存儲在一個有意義的結構中就可以，所以文件存儲數據庫有自己的適用范圍。

如果我們要將報紙或雜志中的文章存儲到關系型數據庫中，首先我們要對存儲的信息進行分類，文章放在一個表中，作者和相關信息放在一個表中，文章評論放在一個表中，讀者信息放在一個表中，然后將這四個表連接起來進行查詢。但是文檔存儲可以將文章存儲為單個實體，這樣就降低了用戶對文章數據的認知負擔。

圖形數據庫

圖形數據庫是NoSQL數據庫類型中最復雜的一個，旨在以高效的方式存儲實體來之間的關系。圖形數據庫適用于高度互連的數據，尤其是社交網絡，科學論文引用或是資本資產集群。

圖形或網絡數據有兩個主要組成部分：

節點：實體本身，如果是在社交網絡中，那么代表的就是人。

邊：兩個實體之間的關系，這種關系用線來表示，并具有自己的屬性。另外邊還可以有方向，如果箭頭指向誰，誰就是老板。

如果給定的實體類型和關系很多，那么圖就有可能變得非常復雜。下圖的實體數量已經很少了，但是我們看到它已經比較復雜了。圖形數據庫如Neo4j支持ACID,而文檔存儲和鍵值存儲支持BASE。

DB-Engines 最近發布了 2016年12月份的數據庫排名，我們可以看到排名前十的數據庫關系型數據庫占據了7位，Oracle雖然一直占據首位，但是我們可以看到，與去年同期相比，它的得分下降了93.15，而非關系型數據庫的得分與去年同期相比都有不同程度的提高，所以我們有理由相信NoSQL數據庫的未來是大有可為的。