NoSQL類型概述

對比傳統關系型資料庫，NoSQL有着更為複雜的分類——鍵值、面向文檔、列存儲以及圖資料庫。這裡就帶你一覽NoSQL各種類型的适用場景及一些知名公司的方案選擇。

在過去幾年，關系型資料庫一直是資料持久化的唯一選擇，資料工作者考慮的也隻是在這些傳統資料庫中做篩選，比如SQL Server、Oracle或者是MySQL。甚至是做一些預設的選擇，比如使用.NET的一般會選擇SQL Server；使用Java的可能會偏向Oracle，Ruby是MySQL，Python則是PostgreSQL或MySQL等等。

原因很簡單：過去很長一段時間内，關系資料庫的健壯性已經在多數應用程式中得到證明。我們可以使用這些傳統資料庫良好的控制并發操作、事務等等。然而如果傳統的關系型資料庫一直這麼可靠，那麼還有NoSQL什麼事？NoSQL之是以生存并得到發展，是因為它做到了傳統關系型資料庫做不到的事！

關系型資料庫中存在的問題

Impedance Mismatch

我們使用Python、Ruby、Java、.Net等語言編寫應用程式，這些語言有一個共同的特性——面向對象。但是我們使用MySQL、PostgreSQL、Oracle以及SQL Server，這些資料庫同樣有一個共同的特性——關系型資料庫。這裡就牽扯到了“Impedance Mismatch”這個術語：存儲結構是面向對象的，但是資料庫卻是關系的，是以在每次存儲或者查詢資料時，我們都需要做轉換。類似Hibernate、Entity Framework這樣的ORM架構确實可以簡化這個過程，但是在對查詢有高性能需求時，這些ORM架構就捉襟見肘了。

應用程式規模的變大

網絡應用程式的規模日漸變大，我們需要儲存更多的資料、服務更多的使用者以及需求更多的計算能力。為了應對這種情形，我們需要不停的擴充。擴充分為兩類：一種是縱向擴充，即購買更好的機器，更多的磁盤、更多的記憶體等等；另一種是橫向擴充，即購買更多的機器組成叢集。在巨大的規模下，縱向擴充發揮的作用并不是很大。首先單機器性能提升需要巨額的開銷并且有着性能的上限，在Google和Facebook這種規模下，永遠不可能使用一台機器支撐所有的負載。鑒于這種情況，我們需要新的資料庫，因為關系資料庫并不能很好的運作在叢集上。不錯你也可能會去搭建關系資料庫叢集，但是他們使用的是共享存儲，這并不是我們想要的類型。于是就有了以Google、Facebook、Amazon這些試圖處理更多傳輸所引領的NoSQL紀元。

NoSQL紀元

當下已經存在很多的NoSQL資料庫，比如MongoDB、Redis、Riak、HBase、Cassandra等等。每一個都擁有以下幾個特性中的一個：

不再使用SQL語言，比如MongoDB、Cassandra就有自己的查詢語言

通常是開源項目

為叢集運作而生

弱結構化——不會嚴格的限制資料結構類型

NoSQL資料庫的類型

NoSQL可以大體上分為4個種類：Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。下面就一覽這些類型的特性：

一、 鍵值（Key-Value）資料庫

鍵值資料庫就像在傳統語言中使用的哈希表。你可以通過key來添加、查詢或者删除資料，鑒于使用主鍵通路，是以會獲得不錯的性能及擴充性。

産品：Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

有誰在使用：GitHub （Riak）、BestBuy （Riak）、Twitter （Redis和Memcached）、StackOverFlow （Redis）、 Instagram （Redis）、Youtube （Memcached）、Wikipedia（Memcached）

适用的場景

儲存使用者資訊，比如會話、配置檔案、參數、購物車等等。這些資訊一般都和ID（鍵）挂鈎，這種情景下鍵值資料庫是個很好的選擇。

不适用場景

1.取代通過鍵查詢，而是通過值來查詢。Key-Value資料庫中根本沒有通過值查詢的途徑。

2.需要儲存資料之間的關系。在Key-Value資料庫中不能通過兩個或以上的鍵來關聯資料。

3.事務的支援。在Key-Value資料庫中故障産生時不可以進行復原。

二、 面向文檔（Document-Oriented）資料庫

面向文檔資料庫會将資料以文檔的形式儲存。每個文檔都是自包含的資料單元，是一系列資料項的集合。每個資料項都有一個名稱與對應的值，值既可以是簡單的資料類型，如字元串、數字和日期等；也可以是複雜的類型，如有序清單和關聯對象。資料存儲的最小機關是文檔，同一個表中存儲的文檔屬性可以是不同的，資料可以使用XML、JSON或者JSONB等多種形式存儲。

産品：MongoDB、CouchDB、RavenDB

有誰在使用：SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）

适用的場景

1.日志。企業環境下，每個應用程式都有不同的日志資訊。Document-Oriented資料庫并沒有固定的模式，是以我們可以使用它儲存不同的資訊。

2.分析。鑒于它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。

不适用場景

在不同的文檔上添加事務。Document-Oriented資料庫并不支援文檔間的事務，如果對這方面有需求則不應該選用這個解決方案。

三、 列存儲（Wide Column Store/Column-Family）資料庫

列存儲資料庫将資料儲存在列族（column family）中，一個列族存儲經常被一起查詢的相關資料。舉個例子，如果我們有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列族中，而薪資則在另一個列族中。

産品：Cassandra、HBase

有誰在使用：Ebay （Cassandra）、Instagram （Cassandra）、NASA （Cassandra）、Twitter （Cassandra and HBase）、Facebook （HBase）、Yahoo!（HBase）

适用的場景

1.日志。因為我們可以将資料儲存在不同的列中，每個應用程式可以将資訊寫入自己的列族中。

2.部落格平台。我們儲存每個資訊到不同的列族中。舉個例子，标簽可以儲存在一個，類别可以在一個，而文章則在另一個。

不适用場景

1.如果我們需要ACID事務。Vassandra就不支援事務。

2.原型設計。如果我們分析Cassandra的資料結構，我們就會發現結構是基于我們期望的資料查詢方式而定。在模型設計之初，我們根本不可能去預測它的查詢方式，而一旦查詢方式改變，我們就必須重新設計列族。

四、 圖（Graph-Oriented）資料庫

圖資料庫允許我們将資料以圖的方式儲存。實體會被作為頂點，而實體之間的關系則會被作為邊。比如我們有三個實體，Steve Jobs、Apple和Next，則會有兩個“Founded by”的邊将Apple和Next連接配接到Steve Jobs。

産品：Neo4J、Infinite Graph、OrientDB

有誰在使用：Adobe （Neo4J）、Cisco （Neo4J）、T-Mobile （Neo4J）

适用的場景

1.在一些關系性強的資料中

2.推薦引擎。如果我們将資料以圖的形式表現，那麼将會非常有益于推薦的制定

不适用場景

不适合的資料模型。圖資料庫的适用範圍很小，因為很少有操作涉及到整個圖。