現在我們站在各個用例的角度上來考慮那種系統適合于這些用例。你的意見是?

首先，我們要縱覽各種數據模型。這些模型的分類方法來自于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的數據庫，可以在存儲過程或者應用代碼中實現。

深度連接用圖數據庫，它支持實體鍵間的快速定位。

更多信息請查看IT技術專欄