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、Mybatis、Entity Framework這樣的ORM框架確實能夠簡化這個過程，可是在對查詢有高性能需求時，這些ORM框架就捉襟見肘了。

應用程序規模的變大

網絡應用程序的規模日漸變大，咱們須要儲存更多的數據、服務更多的用戶以及需求更多的計算能力。爲了應對這種情形，咱們須要不停的擴展。

擴展分爲兩類：

1） 縱向擴展，即購買更好的機器，更多的磁盤、更多的內存等等；

2） 橫向擴展，即購買更多的機器組成集羣。在巨大的規模下，縱向擴展發揮的做用並非很大。

首先單個機器性能提高須要鉅額的開銷而且有着性能的上限，在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。

1、 鍵值（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）

1. 適用的場景

儲存用戶信息，好比會話、配置文件、參數、購物車等等。這些信息通常都和ID（鍵）掛鉤，這種情景下鍵值數據庫是個很好的選擇。

2. 不適用場景

1） 取代經過鍵查詢，而是經過值來查詢。Key-Value數據庫中根本沒有經過值查詢的途徑。

2） 須要儲存數據之間的關係。在Key-Value數據庫中不能經過兩個或以上的鍵來關聯數據。

3） 事務的支持。在Key-Value數據庫中故障產生時不能夠進行回滾。

 

2、 面向文檔（Document-Oriented）數據庫

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

產品：MongoDB、CouchDB、RavenDB

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

1. 適用的場景

1） 日誌。企業環境下，每一個應用程序都有不一樣的日誌信息。Document-Oriented數據庫並無固定的模式，因此咱們可使用它儲存不一樣的信息。

2） 分析。鑑於它的弱模式結構，不改變模式下就能夠儲存不一樣的度量方法及添加新的度量。

2. 不適用場景

在不一樣的文檔上添加事務。Document-Oriented數據庫並不支持文檔間的事務，若是對這方面有需求則不該該選用這個解決方案。

 

3、 列存儲（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. 適用的場景

1） 日誌。由於咱們能夠將數據儲存在不一樣的列中，每一個應用程序能夠將信息寫入本身的列族中。

2） 博客平臺。咱們儲存每一個信息到不一樣的列族中。舉個例子，標籤能夠儲存在一個，類別能夠在一個，而文章則在另外一個。

2. 不適用場景

1） 若是咱們須要ACID事務。Vassandra就不支持事務。

2） 原型設計。若是咱們分析Cassandra的數據結構，咱們就會發現結構是基於咱們指望的數據查詢方式而定。在模型設計之初，咱們根本不可能去預測它的查詢方式，而一旦查詢方式改變，咱們就必須從新設計列族。

 

4、 圖（Graph-Oriented）數據庫

圖數據庫容許咱們將數據以圖的方式儲存。實體會被做爲頂點，而實體之間的關係則會被做爲邊。好比咱們有三個實體，Steve Jobs、Apple和Next，則會有兩個「Founded by」的邊將Apple和Next鏈接到Steve Jobs。

產品：Neo4J、Infinite Graph、OrientDB

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

1. 適用的場景

1） 在一些關係性強的數據中

2） 推薦引擎。若是咱們將數據以圖的形式表現，那麼將會很是有益於推薦的制定

2. 不適用場景

不適合的數據模型。圖數據庫的適用範圍很小，由於不多有操做涉及到整個圖。

 

英文原文： NoSQL Databases, why we should use, and which one we should choose

 

參考推薦：

一網打盡當下NoSQL類型、適用場景及使用公司

全球著名互聯網企業背後的開源力量