今天我将對常見關系型資料庫以及nosql的使用場景做一個詳細的分析和比較。希望對大家以後的資料庫選型有所幫助。
目錄
資料庫場景比較
mysql還是postgresql?
mongodb
鍵值（key-value）資料庫
cassandra
圖資料庫(neo4j)
公司業務适合使用的資料庫
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使用場景
由于列族資料庫可存放任意資料結構，是以它很适合用來儲存應用程式狀态或運作中遇到的錯誤等事件資訊。在企業級環境下，所有應用程式都可以把事件寫入cassandra資料庫。它們可以用appname:timestamp(應用程式名：時間戳)作為行鍵，并使用自己需要的列。由于cassandra的寫入能力可擴充，是以在事件記錄系統中使用它效果會很好。
2）内容管理系統與部落格平台
使用列族，可以把博文的”标簽”(tag)、”類别”(category)、”連結”(link)和”trackback”（俗稱引用告知，是一種網志工具，它可以讓文章作者知道該文讀者中有哪些人撰寫了哪些與之有關的文章）等屬性放在不同的列中。評論資訊即可以與上述内容放在同一行，也可以移到另一個”鍵空間”。同理，部落格使用者與實際博文亦可存于不同列族中。部落格平台：我們儲存每個資訊到不同的列族中。舉個例子，标簽、類别、文章分别儲存在不同列族。
3）計數器
在網絡應用程式中，通常要統計某頁面的通路人數并對其分類，以算出分析資料。此時可使用contercolumntype來建立列族。
建立好列族後，可以使用任意列記錄網絡應用程式中每個使用者通路每一頁面的次數。
也可以使用cql增加計數器的值：
4）限期使用
我們可能需要向使用者提供試用版，或是在網站上讓某個廣告條顯示一定時間。這些功能可以通過”帶過期時限的列”(expiring column)來完成。這種列過了給定時限後，就會又cassandra自動删除。這個時限叫做ttl(time to live，生存時間)，以秒為機關。經過ttl指定的時長後，這種列就被删掉了。程式若檢測到此列不存在，則可收回使用者通路權限或移除廣告條。
因為我們可以将資料儲存在不同的列中，每個應用程式可以将資訊寫入自己的列族中。
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等資料庫運維工作。
曾任職于某國有企業，負責公司電商網站資料庫架構和業務應用的架構。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-02-29</b>