NoSQL資料庫的35個應用場景

英文原文：35+ Use Cases For Choosing Your Next NoSQL Database，編譯：Juliashine

之前有三篇文章

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。

物件資料庫

• 源起：圖資料庫研究
• 資料模型：物件
• 例子：Objectivity, Gemstone
• 優點：複雜物件模型，快速鍵值訪問，鍵功能訪問，以及圖資料庫的優點。

Key-Value資料庫

• 源起：Amazon的論文 Dynamo 和 Distributed HashTables。
• 資料模型：鍵值對
• 例子：Membase, Riak
• 優點：處理大量資料，快速處理大量讀寫請求。程式設計友好。

• 源起： ?
• 資料模型：字典操作，lists, sets和字串值
• 例子：Redis
• 優點：不同於以前的任何資料庫

你的應用應該用什麼?

• 關鍵是要意識到不同的應用需要不同的資料模型和產品。選擇合適的資料模型和產品。
• 要了解你的應用需要什麼樣的資料模型可以看 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也是一樣。每個產品都會有問題，你能解決你選擇的產品的問題嗎？