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。

        圖數據庫

• 源起： 歐拉和圖理論。
• 數據模型：節點和關系，也可處理鍵值對。
• 例子：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 也是一樣。每個產品都會有問題，你能解決你選擇的產品的問題嗎？
  來自: blog.jobbole.com