當下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等等。 每一個都擁有以下幾個特性中的一個：

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. 推薦引擎。 如果我們將資料以圖的形式表現，那麼將會非常有益於推薦的制定

不適用場景

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

原文連結：