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

在過去幾年，關系型數(shù)據(jù)庫一直是數(shù)據(jù)持久化的選擇，數(shù)據(jù)工作者考慮的也只是在這些傳統(tǒng)數(shù)據(jù)庫中做篩選，比如SQL Server、Oracle或者是MySQL。甚至是做一些默認的選擇，比如使用.NET的一般會選擇SQL Server;使用Java的可能會偏向Oracle，Ruby是MySQL，Python則是PostgreSQL或MySQL等等。

原因很簡單：過去很長一段時間內，關系數(shù)據(jù)庫的健壯性已經在多數(shù)應用程序中得到證實。我們可以使用這些傳統(tǒng)數(shù)據(jù)庫良好的控制并發(fā)操作、事務等等。然而如果傳統(tǒng)的關系型數(shù)據(jù)庫一直這么可靠，那么還有NoSQL什么事NoSQL之所以生存并得到發(fā)展，是因為它做到了傳統(tǒng)關系型數(shù)據(jù)庫做不到的事!

關系型數(shù)據(jù)庫中存在的問題

Impedance Mismatch

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

應用程序規(guī)模的變大

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

NoSQL紀元

當下已經存在很多的NoSQL數(shù)據(jù)庫，比如MongoDB、Redis、Riak、Hbase、Cassandra等等。每一個都擁有以下幾個特性中的一個：

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

通常是開源項目

為集群運行而生

弱結構化——不會嚴格的限制數(shù)據(jù)結構類型