NoSQL數據庫的35個應用場景

本文另外一地址請見 NoSQL數據庫的35個應用場景

本文翻譯自 35+ Use Cases For Choosing Your Next NoSQL Database

以前有三篇文章

What The Heck Are You Actually Using NoSQL For?. 

101 Questions To Ask When Considering A NoSQL Database. 

What Should I Do? Choosing SQL, NoSQL or Both for Scalable Web Applications.

如今咱們站在各個用例的角度上來考慮那種系統適合於這些用例。

你的意見是?

首先，咱們要縱覽各類數據模型。這些模型的分類方法來自於Emil Eifrem 和 NoSQL databases。

文檔數據庫

• 源起：受Lotus Notes啓發。
• 數據模型：包含了key-value的文檔集合
• 例子：CouchDB, MongoDB 
• 優勢：數據模型天然，編程友好，快速開發，web友好，CRUD。

圖數據庫

• 源起： 歐拉和圖理論。
• 數據模型：節點和關係，也可處理鍵值對。
• 例子：AllegroGraph, InfoGrid, Neo4j
• 優勢：解決複雜的圖問題。

關係數據庫

• 源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
• 數據模型：各類關係
• 例子：VoltDB,  Clustrix, MySQL
• 優勢：高性能、可擴展的OLTP，支持SQL，物化視圖，支持事務，編程友好。

對象數據庫

• 源起：圖數據庫研究
• 數據模型：對象
• 例子：Objectivity, Gemstone
• 優勢：複雜對象模型，快速鍵值訪問，鍵功能訪問，以及圖數據庫的優勢。

Key-Value數據庫

• 源起：Amazon的論文 Dynamo 和 Distributed HashTables。
• 數據模型：鍵值對
• 例子：Membase, Riak
• 優勢：處理大量數據，快速處理大量讀寫請求。編程友好。

BigTable類型數據庫

• 源起：Google的論文 BigTable。
• 數據模型：列簇，每一行在理論上都是不一樣的
• 例子：HBase, Hypertable, Cassandra
• 優勢：處理大量數據，應對極高寫負載，高可用，支持跨數據中心， MapReduce。

數據結構服務

• 源起： ?
• 數據模型：字典操做，lists, sets和字符串值
  
• 例子：Redis
• 優勢：不一樣於之前的任何數據庫

網格數據庫

• 源起：數據網格和元組空間研究。
• 數據模型：基於空間的架構
• 例子：GigaSpaces, Coherence
• 優勢：適於事務處理的高性能和高擴展性

你的應用應該用什麼?

• 關鍵是要意識到不一樣的應用須要不一樣的數據模型和產品。選擇合適的數據模型和產品。
• 要了解你的應用須要什麼樣的數據模型能夠看 What The Heck Are You Actually Using NoSQL For? 在這篇文章裏我總結了一些特點各異的很是規的使用場景。
• 適應你的需求和應用場景。依次而爲你就能找到最適合你的架構的產品。不管NoSQL仍是SQL都不重要。
• 綜合考慮數據模型、產品特性和應用情景。不一樣產品功能各異，只憑數據模型來決定選擇誰是不可能的。
• 哪一個產品具備你最須要的特色哪一個就是最好的。

假如你的應用有如下需求：

• 復瑣事物，若是你不能承受數據丟失的風險或者你想要一個簡單的事務編程模型能夠選擇關係數據庫和網格數據庫。
  • 例子：一個庫存系統須要完整的ACID特性。若是我在買了一個東西后才被告知它已經售罄我會很是不快。不不想要補償，我只要我買的東西。
• 擴展性，NoSQL或SQL皆可，目標產品要支持水平擴展、分區、在線增減硬件、負載均衡、自動分片、數據平衡和容錯等特性。
• 追求高可用性，可用Bigtable類型的等支持最終一致性的數據庫。
• 須要處理長期的快速讀寫，能夠看看文檔數據庫，Key-value數據庫或者內存數據庫，還能夠考慮SSD。
• 要實現社會化網絡，第一選擇應該是圖數據庫。其次像Riak這樣支持關係的數據庫也能夠。一個支持簡單SQL join操做的內存關係數據庫可以處理數據量不大的狀況。Redis' set 和list 操做就是這樣。

假如你的應用有如下需求：

• 須要不一樣的訪問方式和數據類型的話能夠看看文檔數據庫，它們在這方面很靈活。
• 大數據量的離線分析首先應該考慮Hadoop，其次是其餘支持MapReduce的產品。固然，支持MapReduce與擅長MapReduce處理不是一回事。
• 如需跨越多個數據中心，可選用基於Bigtable模型的產品，或其分佈式的，能解決延遲問題，分區容錯性問題的產品
• CRUD類型的應用能夠考慮文檔數據庫，這樣不須要join就可訪問複雜的數據結構。
• 搜索能夠考慮Riak。
• 須要lists, sets, queues, publish-subscribe等數據結構的話，能夠考慮Redis，它的分佈式鎖等特性也很是有用。
• 編程友好，若是要使用JSON, HTTP, REST, Javascript等程序員喜聞樂見的數據類型，第一選擇就是文檔數據庫和Key-value數據庫。

假如你的應用有如下需求：

• 用於實時事務處理的物化視圖，能夠考慮VoltDB，很是適合於快速處理大量事務。
• 企業級支持及服務級協議 ，能夠尋找市場上以此爲賣點的產品，如Membase。
• 要記錄連續的大量數據，又對一致性無過高要求，能夠看看Bigtable類型數據庫，由於它工做在分佈式文件系統上，能夠處理大規模的寫入請求。
• 須要儘量使用簡單，請考慮PAAS方案，用這種方案你本身幾乎不須要作什麼。
• 若是你的產品要賣給企業客戶請考慮關係數據庫，由於他們習慣於關係數據庫。
• 要動態構建對象間的關係，對象的屬性可以動態加減，能夠考慮圖數據庫，由於它不須要schema，能夠在代碼中隨需建模。
• 要支持大影音文件，能夠看看像S3這樣的存儲服務。NoSQL不適於存儲BLOBS，儘管MongoDB也提供了文件服務。

假如你的應用有如下需求：

• 要快速批量上傳大量數據，得尋找支持這種場景的產品。可是大多數產品都不支持批量操做。
• 易於變化，要選擇支持動態schema的文檔數據庫和 Key-value數據庫。它支持可選域，不須要修改schema便可增長、減小域。
• 爲了支持完整性約束，選擇支持SQL DDL的數據庫，能夠在存儲過程或者應用代碼中實現。
• 深度鏈接用圖數據庫，它支持實體鍵間的快速定位。
• 爲了讓計算靠近數據，減小數據在網絡中傳送的開銷，能夠考慮存儲過程。關係數據庫，網個數據庫，文檔數據庫和Key-value數據庫都支持存儲過程。

假如你的應用有如下需求：

• 要存儲BLOB數據，可選擇Key-value數據庫。它能夠存儲網頁或者複雜對象，後者在關係數據庫中要用join才能獲取，代價高昂。還能夠下降延遲。
• 選擇一個通過驗證的成熟產品，在處理擴展性問題的時候的時候選擇通用的方案（縱向擴展、調優、緩存、數據分片、反範式等等）
• 多變的數據類型，數據不規整，列數不固定，複雜的數據結構等，考慮文檔數據庫，Key-value數據庫，和Bigtable型數據庫。它們的數據類型都比較靈活。
• 須要快速的關係查詢，可是又不想本身實現，那麼就選擇支持SQL的數據庫。
• 可以在雲中操做，自動利用雲的一切特性和好處，目前尚未這樣的東西。

假如你的應用有如下需求：

• 支持二級索引，經過不一樣的鍵來檢索，能夠考慮關係數據庫和 Cassandra，後者新增了對二級索引的支持。
• 規模不斷增加（真正的大數據場景），可是訪問不頻繁的數據可使用Bigtable類型的數據庫，由於它的數據存儲在一個分佈式文件系統上，很容易擴展 。
• 要和其餘服務集成，檢查數據庫是否提供某種寫後同步功能，以便可以捕捉到數據庫變化，通知其它系統，保證一致性。
• 容錯性，檢查在停電、分區故障以及其餘故障場景下寫操做是否可以成功。
• 若是隻是爲了推進某個方向上的技術創新，彷佛沒有現成的東西可以達到這個目的，你得本身去創造一個新的。這可不是件容易事。
• 移動平臺上能夠用CouchDB/Mobile couchbase.

那個更好?

• 爲了25%的性能提高而遷移到NoSQL是不值得的。
• 性能測試數據都有其特定的場景，不見得能適合你的狀況。 
• 若是你的公司剛剛成立，尚未一個成型的產品，而且你很願意嘗試一些新東西，那麼選擇SQL仍是NoSQL對你而言須要費上些心思（言下之意，一張白紙好做畫，沒有既有系統的負擔就能夠隨便折騰？）。
• 數據量不大的時候性能差距並不明顯，可是當數據量變大的時候呢？
• 沒有完美的東西，若是你去Amazon的論壇上去看，上面充滿了對各類產品的性能和服務的抱怨，GAE也是同樣。每一個產品都會有問題，你能解決你選擇的產品的問題嗎？