隨著近幾年互聯網IT的發展，非關系型數據庫（NoSQL）得到了極大的發展和應用。和傳統的關系型數據庫相比，NoSQL數據庫為軟件開發人員提供了高運算速度和更大的靈活性。
NoSQL數據庫的數據結構一般有：
-
鍵值對（key-value），代表數據庫：Redis
-
列存儲（Wide Column），代表數據庫：Cassandra，HBase
-
圖（graph），代表數據庫：Neo4J
-
文檔（document）,代表數據庫：MongoDB
這些數據結構和關系型數據庫表格式的數據結構都有非常大的區別，它們都是為了適應特定的業務場景而設計的。在某個業務場景下應該選擇關系型數據庫還是非關系數據庫、選擇哪種類型的非關系數據庫是非常重要的，今天我們就一起來看看針對不同的業務場景應該如何選擇NoSQL數據庫。
鍵值對（key-value）數據庫
redis數據庫
鍵值數據庫就像在傳統語言中使用的哈希表。你可以通過key來添加、查詢或者刪除數據，鑒于使用主鍵訪問，所以會獲得不錯的性能及擴展性。
適用的場景：
-
通過鍵來定位查找而不是通過值來查找的業務。
-
緩存。
不適用的場景：
-
需要通過值來查找的業務，Key-Value數據庫中根本沒有通過值查詢的途徑。
-
需要儲存數據之間的關系。在Key-Value數據庫中不能通過兩個或以上的鍵來關聯數據。
-
需要事務的支持。在Key-Value數據庫中故障產生時不可以進行回滾。
列存儲（Wide Column Store）數據庫
HBase數據庫
列存儲數據庫將數據儲存在列族（column family）中，一個列族存儲經常被一起查詢的相關數據。舉個例子，如果我們有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列族中，而薪資則在另一個列族中。
適用的場景
-
日志。因為我們可以將數據儲存在不同的列中，每個應用程序可以將信息寫入自己的列族中。
-
博客平臺。我們儲存每個信息到不同的列族中。舉個例子，標簽可以儲存在一個，類別可以在一個，而文章則在另一個。
不適用場景
-
如果我們需要ACID事務。Cassandra就不支持事務。
-
原型設計。如果我們分析Cassandra的數據結構，我們就會發現結構是基于我們期望的數據查詢方式而定。在模型設計之初，我們根本不可能去預測它的查詢方式，而一旦查詢方式改變，我們就必須重新設計列族。
圖（Graph）數據庫
Neo4j數據庫
圖數據庫允許我們將數據以圖的方式儲存。實體會被作為頂點，而實體之間的關系則會被作為邊。
適用的場景
-
在一些關系性強的數據中
-
推薦引擎。如果我們將數據以圖的形式表現，那么將會非常有益于推薦的制定
不適用場景
-
不適合的數據模型。圖數據庫的適用范圍很小，因為很少有操作涉及到整個圖。
文檔（Document）數據庫
mongoDB數據庫
文檔數據庫會將數據以文檔的形式儲存。每個文檔都是自包含的數據單元，是一系列數據項的集合。每個數據項都有一個名稱與對應的值，值既可以是簡單的數據類型，如字符串、數字和日期等；也可以是復雜的類型，如有序列表和關聯對象。數據存儲的最小單位是文檔，同一個表中存儲的文檔屬性可以是不同的，數據可以使用XML、JSON或者JSONB等多種形式存儲。
適用的場景
-
日志。企業環境下，每個應用程序都有不同的日志信息。Document-Oriented數據庫并沒有固定的模式，所以我們可以使用它儲存不同的信息。
-
分析。鑒于它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。
不適用場景
-
在不同的文檔上添加事務。Document-Oriented數據庫并不支持文檔間的事務，如果對這方面有需求則不應該選用這個解決方案。
