筆者也初進(jìn)大數(shù)據(jù)公司做中臺項(xiàng)目，關(guān)于NoSQL數(shù)據(jù)這塊覺得以下總結(jié)很不錯，一起分享給大家。

[[243620]]

NoSQL類型、適用場景及使用公司

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

原因很簡單：過去很長一段時間內(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ù)庫中存在的問題

1. Impedance Mismatch

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

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

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

NoSQL紀(jì)元

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

• 不再使用SQL語言，比如MongoDB、Cassandra就有自己的查詢語言
• 通常是開源項(xiàng)目
• 為集群運(yùn)行而生
• 弱結(jié)構(gòu)化——不會嚴(yán)格的限制數(shù)據(jù)結(jié)構(gòu)類型

NoSQL數(shù)據(jù)庫的類型

NoSQL可以大體上分為4個種類：Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。下面就一覽這些類型的特性：

1. 鍵值(Key-Value)數(shù)據(jù)庫

鍵值數(shù)據(jù)庫就像在傳統(tǒng)語言中使用的哈希表。你可以通過key來添加、查詢或者刪除數(shù)據(jù)，鑒于使用主鍵訪問，所以會獲得不錯的性能及擴(kuò)展性。

產(chǎn)品：Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

有誰在使用：GitHub (Riak)、BestBuy (Riak)、Twitter (Redis和Memcached)、StackOverFlow (Redis)、 Instagram (Redis)、Youtube (Memcached)、Wikipedia(Memcached)

適用的場景：儲存用戶信息，比如會話、配置文件、參數(shù)、購物車等等。這些信息一般都和ID(鍵)掛鉤，這種情景下鍵值數(shù)據(jù)庫是個很好的選擇。

不適用場景：

• 取代通過鍵查詢，而是通過值來查詢。Key-Value數(shù)據(jù)庫中根本沒有通過值查詢的途徑。
• 需要儲存數(shù)據(jù)之間的關(guān)系。在Key-Value數(shù)據(jù)庫中不能通過兩個或以上的鍵來關(guān)聯(lián)數(shù)據(jù)。
• 事務(wù)的支持。在Key-Value數(shù)據(jù)庫中故障產(chǎn)生時不可以進(jìn)行回滾。

2. 面向文檔(Document-Oriented)數(shù)據(jù)庫

面向文檔數(shù)據(jù)庫會將數(shù)據(jù)以文檔的形式儲存。每個文檔都是自包含的數(shù)據(jù)單元，是一系列數(shù)據(jù)項(xiàng)的集合。每個數(shù)據(jù)項(xiàng)都有一個名稱與對應(yīng)的值，值既可以是簡單的數(shù)據(jù)類型，如字符串、數(shù)字和日期等;也可以是復(fù)雜的類型，如有序列表和關(guān)聯(lián)對象。數(shù)據(jù)存儲的最小單位是文檔，同一個表中存儲的文檔屬性可以是不同的，數(shù)據(jù)可以使用XML、JSON或者JSONB等多種形式存儲。

產(chǎn)品：MongoDB、CouchDB、RavenDB

有誰在使用：SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)

適用的場景：

• 日志。企業(yè)環(huán)境下，每個應(yīng)用程序都有不同的日志信息。Document-Oriented數(shù)據(jù)庫并沒有固定的模式，所以我們可以使用它儲存不同的信息。
• 分析。鑒于它的弱模式結(jié)構(gòu)，不改變模式下就可以儲存不同的度量方法及添加新的度量。

不適用場景：在不同的文檔上添加事務(wù)。Document-Oriented數(shù)據(jù)庫并不支持文檔間的事務(wù)，如果對這方面有需求則不應(yīng)該選用這個解決方案。

3. 列存儲(Wide Column Store/Column-Family)數(shù)據(jù)庫

列存儲數(shù)據(jù)庫將數(shù)據(jù)儲存在列族(column family)中，一個列族存儲經(jīng)常被一起查詢的相關(guān)數(shù)據(jù)。舉個例子，如果我們有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列族中，而薪資則在另一個列族中。

產(chǎn)品：Cassandra、HBase

有誰在使用：Ebay (Cassandra)、Instagram (Cassandra)、NASA (Cassandra)、Twitter (Cassandra and HBase)、Facebook (HBase)、Yahoo!(HBase)

適用的場景：

• 日志。因?yàn)槲覀兛梢詫?shù)據(jù)儲存在不同的列中，每個應(yīng)用程序可以將信息寫入自己的列族中。
• 博客平臺。我們儲存每個信息到不同的列族中。舉個例子，標(biāo)簽可以儲存在一個，類別可以在一個，而文章則在另一個。

不適用場景：

• 如果我們需要ACID事務(wù)。Vassandra就不支持事務(wù)。
• 原型設(shè)計(jì)。如果我們分析Cassandra的數(shù)據(jù)結(jié)構(gòu)，我們就會發(fā)現(xiàn)結(jié)構(gòu)是基于我們期望的數(shù)據(jù)查詢方式而定。在模型設(shè)計(jì)之初，我們根本不可能去預(yù)測它的查詢方式，而一旦查詢方式改變，我們就必須重新設(shè)計(jì)列族。

4.  圖(Graph-Oriented)數(shù)據(jù)庫

圖數(shù)據(jù)庫允許我們將數(shù)據(jù)以圖的方式儲存。實(shí)體會被作為頂點(diǎn)，而實(shí)體之間的關(guān)系則會被作為邊。比如我們有三個實(shí)體，Steve Jobs、Apple和Next，則會有兩個“Founded by”的邊將Apple和Next連接到Steve Jobs。

產(chǎn)品：Neo4J、Infinite Graph、OrientDB

有誰在使用：Adobe (Neo4J)、Cisco (Neo4J)、T-Mobile (Neo4J)

適用的場景：

• 在一些關(guān)系性強(qiáng)的數(shù)據(jù)中
• 推薦引擎。如果我們將數(shù)據(jù)以圖的形式表現(xiàn)，那么將會非常有益于推薦的制定

不適用場景：不適合的數(shù)據(jù)模型。圖數(shù)據(jù)庫的適用范圍很小，因?yàn)楹苌儆胁僮魃婕暗秸麄€圖。