此貓簡介：姓名滴滴，性別男，國籍美國。性格溫順，死宅，喜歡陪主人上班和學數據，主人是大數據文摘非專欄主編Aileen，據主人介紹，滴滴很愿意為大數據文摘“小白學數據”系列代言

　　大數據文摘作品，轉載需授權

作者：薛菲

審稿：張遠園 Aileen

　　寫在前面

這篇是小白學數據系列的NoSQL數據庫的第二篇：進階篇。數據分析方向的從業人員可以從中獲取數據倉庫軟件市場的現狀和分析，以增加自己的知識儲備，為可能的技術轉型打基礎。而工程師可以找到關于NoSQL主流產品的分析介紹以及選擇數據庫的一些準則。NoSQL不是萬能藥，采用技術最好不要跟風，選擇適合自己數據和應用的才是最好的喲~沒有看過NoSQL基礎篇的讀者可以在文末的歷史文章回顧中找到。

小白問：上次問了NoSQL，SQL的區別，好像有點忘了，我們可以溫故而知新一下嗎？

答：。。。好吧，上次我們說了他們主要有兩個區別：第一就是數據建模的方式不同，SQL是采用表格的模型，雖然比較簡潔整齊但是前期建模需要的投入比較大，并且之后如果想要更改這個模型是一件非常困難的事情；第二就是系統的可擴展性不同，NoSQL可以非常簡單的加入新的機器進行分布式運行，而SQL數據庫則需要進行復雜的分片過程，給使用數據庫的應用增加復雜度。

小白問：這幾天聽說了一個叫做數據倉庫的東西，這個和數據庫有什么關系嗎？

答：從技術上講，數據倉庫是數據庫的一種。從功能上講，數據庫分成兩種：一種是實時系統（也叫線上交易處理OLTP），另外一種就是數據倉庫了（也叫線上分析處理OLAP）。

實時系統主要的功能是日常的操作處理。假設我們有一個賣煎餅的電子商務網站，那我們的電子商店應用連接的系統就是實時的OLTP系統，這個數據庫中的信息永遠是最新的，每次有人從我們的網站買煎餅，這個交易都要馬上記錄在數據庫中可以進行發貨客服等服務，關心和操作這些數據的人主要是公司的一線職工比如快遞小哥以及一線的管理人員比如銷售經理。這個系統單個的請求一般來說都比較簡單，而由于買我們煎餅的人數很多，所以要保障這個系統的吞吐量。

然而公司的CEO和高層管理人員對數據有不同的訴求，他們希望可以通過分析數據來了解公司產品銷售和財務的健康狀況，進行分析和決策。有可能通過分析表明，煎餅中的薄脆會很快的售罄，那產品決策者可以增加薄脆原料的采購量。這個時候如果繼續使用我們前面的實時OLTP系統就出現了兩個問題。第一，由于實時系統中的數據建模是根據日常操作的需求來進行的，當需要大規模的復雜查詢和計算的時候就比較捉急了。而數據倉庫OLAP中的建模是專門為這個數據分析的需求而產生的，可以很快的進行聚集類的計算（比如平均日銷售量，年銷售總量等）。第二，由于實時系統對性能的要求很高，如果CEO需要的查詢結果奪取了日常運營的資源，那就得不償失了。數據倉庫的解決方案就是定期將實時系統中新增的信息移到數據倉庫中，也就是同樣的一份信息用不同的方式存了兩遍，這兩個地方的數據模型并不相同，這樣CEO和外賣小哥就不會互相影響了！

小白問：你說數據倉庫中的信息是定時增加的，那就是說這里面的信息不是最全面的嗎？

答：你說的對，數據倉庫的信息會有些滯后，但是我們煎餅公司的決策人員想得到的是銷售趨勢而不是精細的信息，有個那么幾天的延遲一般來說也沒有什么關系。數據科學家的戰場也是在數據倉庫中哦！

小白問：那NoSQL數據庫一般是作為實時的還是數據倉庫呢？

答：在目前來說NoSQL更加常見的應用是實時的OLTP實時數據庫，因為我們上次說了NoSQL的強項主要在于高度可擴展性和靈活的建模，這都是實時系統非常需要的東西，而對于進行聚集的查詢所需要的計算能力還有待提高。新興的大數據技術中最適合OLAP數據倉庫的就是Hadoop相關的技術了，這里我們就不展開說了。

下面這個圖是來自于高德納咨詢公司(Gartner，全球最具權威的IT研究公司)在2015年2月發布的對數據倉庫OLAP的市場分析。我們可以看到，在領導者(Leaders)的這個象限中仍然只有傳統的大型公司，比如大家都熟悉的甲骨文(Oracle)，微軟(Microsoft)和IBM。而新興的技術進入這個名單的只有寥寥不多的幾家，其中包括：亞馬遜云服務 (Amazon Web Services)提供的數據分析服務，提供Hadoop相關軟件的Cloudera和MapR公司以及提供文檔型NoSQL數據庫的MarkLogic公司。等會我們會看到，在高德納公司提供的實時數據庫的分析報告中則是百花齊放和群雄爭霸的一個場面。而在數據倉庫這個方面，還是傳統公司占據主要的市場份額，而新興的大數據分析系統還有待進一步的成熟。

　　圖注：高德納2015OLAP數據倉庫系統市場分析

　　深入聊聊

小白問：NoSQL的數據建模方式有哪幾種呢？我記得上次提到文檔和圖，還有別的嗎？

答：記性不錯！主要有下面的四種：

1.鍵值型（Key-Value）

2.列存儲型 （Wide-Column）

3.文檔型

4.圖型

下面我就簡單介紹一下這四種數據庫的建模方式，你可以參照下面高德納的實時系統OLTP報告來對號入座，我會給一些這個圖中的例子，給他們分到不同的類別中：

　　圖注：高德納2015OLTP實時數據庫系統市場分析

1.鍵值型數據庫

這是NoSQL中數據模型中最簡單的一個了，主要就是用哈希表，通過對于鍵(Key)的查找來找到特定的數據。鍵值型數據庫最大的優勢其實就是它非常簡單，很容易部署在應用中。而缺點就是這個模型過于簡單，對于數據沒有任何結構化的認知，只是知道返回了一坨數據，里面是什么完全沒有概念。這種NoSQL數據庫最典型的應用就是作為緩存，用來增加查詢的性能，其實已經不能算作一個數據庫了。可以在上面圖中的領導象限看到Redis Lab，這個公司提供的產品Redis已經是風靡一時的緩存產品了，各大公司都用它！

　　2.列存儲型數據庫

這個數據模型其實和SQL的數據模型很像，都是存儲在一個表格形狀中的，但是有幾個很重要的不同點。首先，在將數據放入列存儲NoSQL數據庫之前是不需要知道有那些列和列的具體信息的，而SQL是必須要這些信息才可以用的。另外每一行并不是在每一列都是有數據的，這是一個非常稀疏的表格。這種產品的可擴展性都很不錯，上面表中就有在領導象限中DataStax公司所提供的產品Cassandra。

　　3.文檔型數據庫

我們上一篇文章中用JSON的例子就是文檔型數據庫，這些產品的優勢在于數據建模非常的靈活，而且可以對數據的結構有所了解進行更加精確的查詢。但是目前由于沒有統一的查詢語法，不同的產品的查詢語言非常不一樣。這個類型中的代表性產品有：MongoDB和MarkLogic，這兩個公司都已經成為了市場的領導者之一。

　　4.圖型數據庫

圖型數據庫可以實用靈活的模型，對于社交網絡方向的要求非常適合，只要是圖結構的應用都是圖型數據庫的強項。這個類型的代表產品是Neo科技公司的Neo4j。

小白問：這么多不一樣的NoSQL數據庫我都暈了，我有選擇障礙癥啊，求問怎么選數據庫？

答：這個當然是方方面面的了，需要考慮和公司已有的人才和技術資源的兼容性，以及產品價格和擁有產品后的支出，即使采用的是開源的產品也要考慮公司花大錢請來的程序員在這維護和建立系統方面花的時間，計算擁有系統的總支出。

如果從技術方面考慮的話就更多了，最主要就是要理解需求，下面有幾個關鍵的點：

1. 如果你需要的是一個分析系統，而建模不需要太靈活的話，SQL數據庫仍然是最好的選擇。

2. 如果需要靈活的建模以及分析大規模的數據的話，可以考慮Hadoop或者Spark的解決方案。

3. 如果你需要的是一個實時系統，要考慮對已經擁有的數據，怎樣建模最適合（文檔，圖型還是稀疏表格）。

4. 實時系統要考慮對事務的需求。所謂事務就是有一系列的數據庫操作，這些操作要么都做要么都不做。比如你給小灰支付寶轉賬10塊錢，最后要么成功了：你少10塊，小灰多10塊；要么你余額不足失敗了，這時候兩個人的余額都不變。不能出現別的可能性。SQL數據庫是支持事務的，但是很遺憾很多的NoSQL是不支持事務的（比如MongoDB）。如果應用對這些方面有要求，注意選擇有相關功能的數據庫。

5.除此之外還要考慮如果集群中有機器宕機了會發生什么，備份是怎樣進行的，如何檢測系統的性能并調式性能等等等等......

俗話說的好，欲善其事必先利其器。選好了數據庫系統可以讓你的應用開發和數據分析事半功倍喲！

小白問：NoSQL是一個新興的科技，你覺得在未來的一段時間會朝怎樣的方向發展呢？

答：這個問題好，我覺得這幾個發展方向是值得關注的：

1.對于數據倉庫的應用會出現性能更加好的解決方案，畢竟是CEO時常需要的東西呢。比如和BI工具的連接也會加強的。

2.目前采用NoSQL系統的企業主要分布在金融和電信等行業，應該會出現針對于這些行業特定應用（比如CRM和金融中的風控）的整體解決方案打包產品。

3.技術方面更加成熟，更多的產品會支持事務等其他企業需要的功能。