全面梳理關系型數據庫和NoSQL的使用情景

數據庫場景比較

</div>

1、如果你的應用對數據的完整性和嚴肅性要求不高，但是追求處理的高速度。例如論壇和社區，你應該使用MySQL。

2、如果你的應用是一個嚴肅的商業應用，對數據完整性要求很高，而且你希望對一些商業數據邏輯進行很好的封裝，例如網上銀行，你應該使用PostgreSQL。

3、你的應用處理的是地理數據，由于R-TREES的存在，你應該使用PostgreSQL。

1、MongoDB適用案例

1）事件記錄

應用程序對事件記錄各有需求。在企業級解決方案中，許多不同的應用程序都需要記錄事件。文檔數據庫可以把所有這些不同類型的事件都存起來，并作為事件存儲的”中心數據庫”使用。如果事件捕獲的數據類型一直在變，那么就更應該用文檔數據庫了。可以按照觸發事件的應用程序名”分片”，也可以按照order_processed(表示訂單已處理)或customer_logged(表示客戶已記錄)等事件類型”分片”。

2）內容管理系統及博客平臺

由于文檔數據沒有”預設模式”，而且通常支持JSON文檔，所以它們很適合在用”內容管理系統”及網站發布程序上，也可以用來管理用戶評論、用戶注冊、用戶配置和面向Web文檔。

3）網站分析與實時分析

文檔數據庫可存儲實時分析數據。由于可以只更新部分文檔內容，所以用它來存儲”頁面瀏覽量”(page view)或”獨立訪問數”會非常方便，而且無需改變模式即可新增度量標準。分析：鑒于它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。

4）電子商務應用程序

電子商務類應用程序通常需要采用較為靈活的模式，以存儲產品和訂單。同時，它們需要在不做高成本數據庫重構及數據遷移的前提下進行其數據模型。

5）日志

企業環境下，每個應用程序都有不同的日志信息。Document-Oriented數據庫并沒有固定的模式，所以我們可以使用它儲存不同的信息。

2、MongoDB不適用的場合

1）目前對于事務型業務、以及關聯操作業務不適合。

2）在不同的文檔上添加事務。Document-Oriented數據庫并不支持文檔間的事務，如果對這方面有需求則不應該選擇這個解決方案。

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

1、鍵值（Key-Value）數據庫適用的場景

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

2、鍵值（Key-Value）數據庫不適用場景

• 通過值來查詢，而非 通過鍵查詢。Key-Value數據庫中根本沒有通過值查詢的途徑。

• 需要儲存數據之間的關系。在Key-Value數據庫中不能通過兩個或以上的鍵來關聯數據。

• 事務的支持。在Key-Value數據庫中故障產生時不可以進行回滾。

1、Cassandra使用場景

1）事件記錄

由于列族數據庫可存放任意數據結構，所以它很適合用來保存應用程序狀態或運行中遇到的錯誤等事件信息。在企業級環境下，所有應用程序都可以把事件寫入Cassandra數據庫。它們可以用appname:timestamp(應用程序名：時間戳)作為行鍵，并使用自己需要的列。由于Cassandra的寫入能力可擴展，所以在事件記錄系統中使用它效果會很好。

2）內容管理系統與博客平臺

使用列族，可以把博文的”標簽”(tag)、”類別”(category)、”鏈接”(link)和”trackback”（俗稱引用告知，是一種網志工具，它可以讓文章作者知道該文讀者中有哪些人撰寫了哪些與之有關的文章）等屬性放在不同的列中。評論信息即可以與上述內容放在同一行，也可以移到另一個”鍵空間”。同理，博客用戶與實際博文亦可存于不同列族中。博客平臺：我們儲存每個信息到不同的列族中。舉個例子，標簽、類別、文章分別儲存在不同列族。

3）計數器

在網絡應用程序中，通常要統計某頁面的訪問人數并對其分類，以算出分析數據。此時可使用ConterColumnType來創建列族。

創建好列族后，可以使用任意列記錄網絡應用程序中每個用戶訪問每一頁面的次數。

也可以使用CQL增加計數器的值：

4）限期使用

我們可能需要向用戶提供試用版，或是在網站上讓某個廣告條顯示一定時間。這些功能可以通過”帶過期時限的列”(expiring column)來完成。這種列過了給定時限后，就會又Cassandra自動刪除。這個時限叫做TTL(Time To Live，生存時間)，以秒為單位。經過TTL指定的時長后，這種列就被刪掉了。程序若檢測到此列不存在，則可收回用戶訪問權限或移除廣告條。

5）日志

因為我們可以將數據儲存在不同的列中，每個應用程序可以將信息寫入自己的列族中。

2、Cassandra不適合場合

有些問題用列族數據庫來解決并不是最佳選擇，比如說需要以”ACID事務”執行寫入及讀取操作的系統。如果想讓數據庫根據查詢結果來聚合數據(例如sum求和)或avg(求平均值)，那么得把每一行數據都讀到客戶端，并在此執行操作。

在開發早期原型或開始試探某個技術方案時，不太適合用Cassandra。因為開發初期無法確定查詢模式的變化情況，而查詢模式一旦改變，列族的設計也要隨之修改。這將阻礙產品創新團隊的工作并降低開發者的生產能力。

在關系型數據庫中，數據模式的修改成本很高，但是這卻降低了查詢模式的修改成本。Cassandra則與之相反，改變其查詢模式要比改變數據模式代價更高。

簡單說來：

• 如果我們需要ACID事務。Cassandra就不支持事務。

• 原型設計。如果我們分析Cassandra的數據結構，我們就會發現結構是基于我們期望的數據查詢方式而定。在模型設計之初，我們根本不可能去預測它的查詢方式，而一旦查詢方式改變，我們就必須重新設計列族。

1、圖數據庫(Neo4j)適用案例

1）互聯數據

部署并使用圖數據庫來處理社交網絡非常高效。社交圖里并不是只能有”朋友”這種關系，例如也可以用它們表示雇員、雇員的學識，以及這些雇員與其他雇員在不同項目中的工作位置。任何富含鏈接關系的領域都很適合用圖數據庫表示。

假如同一個數據庫含有不同領域(像社交領域、空間領域、商務領域等)的領域實體，而這些實體之間又有關系，那么圖數據庫提供的跨領域遍歷功能，可以讓這些關系變得更有價值。

2）安排運輸路線、分派貨物和基于位置的服務

投遞過程中的每個地點或地址都是一個節點，可以把送貨員投遞貨物時所經全部節點建模為一張節點圖。節點間關系可帶有距離屬性，以便高效投遞貨物。距離與位置屬性也可用在名勝圖(graph of places of interest)中，這樣應用程序就可向用戶推薦其附近的好餐館及娛樂場所了。還可將書店、餐館等售點(point of sales)做成節點，當用戶靠近時，便可以通知他們，提供基于位置的服務。

3）推薦引擎

在系統中創建節點與關系時，可以利用它們為客戶推薦信息。例如”您的朋友也買了這件產品”或”給這些貨品開發票時，通常也要為哪些貨品一并開票”。還可以用它們向旅行者提議“來巴塞羅那旅游的人一般都會去看看安東尼.高迪所設計的建筑”。

用圖數據庫推薦信息時，要注意他的一個副作用——隨著數據量變多，推薦信息所用的節點及關系數也會激增。同一份數據可以挖掘出不同信息。例如，既可以從中看出客戶總是將其與那些產品一并購買，也可以查出與此產品一并開發票的其余產品。若兩者不匹配，則可發出警示。圖數據庫與其他”推薦引擎”一樣，也可以根據關系間的模式偵測交易欺詐。如果我們將數據以圖的形式表現，將會非常有益于推薦的制定。

2、圖數據庫Neo4j不適用場合

1）圖數據庫Neo4j對于更新全部或某子集內的實體就不適用。比如，在某個”數據分析解決方案”中，只要一個屬性變了，全部實體都得更新。此時圖數據庫的效果就不理想了，因為沒有哪個簡單的操作能一次性改變所有節點中的某個屬性。即便數據模型適合問題領域，某些圖數據庫可能也無法處理那么大的數據量，尤其在執行”全局圖操作”時更是如此。

2）不適合的數據模型。圖數據庫的適用范圍很小，因為很少有操作涉及到整個圖。

1、存儲在mysql中的業務：

• 名片、群組信息

• 好友關系

• 路由表

• IM離線消息、Topic

• passport鑒權信息

• 交易明細

• 點贊、關注、朋友圈、評論、聊伴話題

• 信用積分

• 相冊、輕博客、日記記錄

2、存儲在PostgreSQL中的業務：

交易明細-通寶

支付相關的應用應當轉到PostgreSQL

3、HBase 目前已有的業務 ：

• 各用戶的插件、應用同步消息

• 各用戶的等級、積分

4、Cassandra 涉及到的公司業務：

輕博客等

5、MongoDB 涉及到公司業務：

相冊、輕博客、日記記錄

(一般這樣的業務數據量都 增長得 很快)

6、 Neo4j涉及到公司業務 ：

關注關系、名片好友關系等

作者介紹：胡國青

• 【DBA+社群】群副。

• Oracle OCM10G。

• 曾任職于外企，為聯通、移動，水利和國電等提供服務。負責Oracle，MySQL，MongoDB等數據庫運維工作。

• 曾任職于某國有企業，負責公司電商網站數據庫架構和業務應用的架構。