四種NoSQL數據庫類型比對
筆者也初進大數據公司做中臺項目，關于NoSQL數據這塊覺得以下總結很不錯，一起分享給大家。
NoSQL類型、適用場景及使用公司
在過去幾年，關系型數據庫一直是數據持久化的唯一選擇，數據工作者考慮的也只是在這些傳統數據庫中做篩選，比如SQL Server、Oracle或者是MySQL。甚至是做一些默認的選擇，比如使用.NET的一般會選擇SQL Server;使用Java的可能會偏向Oracle，Ruby是MySQL，Python則是PostgreSQL或MySQL等等。
原因很簡單：過去很長一段時間內，關系數據庫的健壯性已經在多數應用程序中得到證實。我們可以使用這些傳統數據庫良好的控制并發操作、事務等等。然而如果傳統的關系型數據庫一直這么可靠，那么還有NoSQL什么事NoSQL之所以生存并得到發展，是因為它做到了傳統關系型數據庫做不到的事!
關系型數據庫中存在的問題
1. Impedance Mismatch
我們使用Python、Ruby、Java、.Net等語言編寫應用程序，這些語言有一個共同的特性——面向對象。但是我們使用MySQL、PostgreSQL、Oracle以及SQL Server，這些數據庫同樣有一個共同的特性——關系型數據庫。這里就牽扯到了“Impedance Mismatch”這個術語：存儲結構是面向對象的，但是數據庫卻是關系的，所以在每次存儲或者查詢數據時，我們都需要做轉換。類似hibernate、Entity Framework這樣的ORM框架確實可以簡化這個過程，但是在對查詢有高性能需求時，這些ORM框架就捉襟見肘了。
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)
適用的場景：儲存用戶信息，比如會話、配置文件、參數、購物車等等。這些信息一般都和ID(鍵)掛鉤，這種情景下鍵值數據庫是個很好的選擇。
不適用場景：
- 取代通過鍵查詢，而是通過值來查詢。Key-Value數據庫中根本沒有通過值查詢的途徑。
- 需要儲存數據之間的關系。在Key-Value數據庫中不能通過兩個或以上的鍵來關聯數據。
- 事務的支持。在Key-Value數據庫中故障產生時不可以進行回滾。
2. 面向文檔(Document-Oriented)數據庫
面向文檔數據庫會將數據以文檔的形式儲存。每個文檔都是自包含的數據單元，是一系列數據項的集合。每個數據項都有一個名稱與對應的值，值既可以是簡單的數據類型，如字符串、數字和日期等;也可以是復雜的類型，如有序列表和關聯對象。數據存儲的最小單位是文檔，同一個表中存儲的文檔屬性可以是不同的，數據可以使用XML、JSON或者JSONB等多種形式存儲。
產品：MongoDB、CouchDB、RavenDB
有誰在使用：SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)
適用的場景：
- 日志。企業環境下，每個應用程序都有不同的日志信息。Document-Oriented數據庫并沒有固定的模式，所以我們可以使用它儲存不同的信息。
- 分析。鑒于它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。
不適用場景：在不同的文檔上添加事務。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)
適用的場景：
- 日志。因為我們可以將數據儲存在不同的列中，每個應用程序可以將信息寫入自己的列族中。
- 博客平臺。我們儲存每個信息到不同的列族中。舉個例子，標簽可以儲存在一個，類別可以在一個，而文章則在另一個。
不適用場景：
- 如果我們需要ACID事務。Vassandra就不支持事務。
- 原型設計。如果我們分析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)
適用的場景：
- 在一些關系性強的數據中
- 推薦引擎。如果我們將數據以圖的形式表現，那么將會非常有益于推薦的制定
不適用場景：不適合的數據模型。圖數據庫的適用范圍很小，因為很少有操作涉及到整個圖。
