一網(wǎng)打盡當(dāng)下NoSQL類型、適用場景及使用公司

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

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

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

Impedance Mismatch

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

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

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

NoSQL紀(jì)元

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

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

通常是開源項(xiàng)目

為集群運(yùn)行而生

弱結(jié)構(gòu)化——不會(huì)嚴(yán)格的限制數(shù)據(jù)結(jié)構(gòu)類型