現(xiàn)在我們站在各個用例的角度上來考慮那種系統(tǒng)適合于這些用例。你的意見是?

首先，我們要縱覽各種數(shù)據(jù)模型。這些模型的分類方法來自于Emil Eifrem 和 NoSQL databases。

文檔數(shù)據(jù)庫

源起：受Lotus Notes啟發(fā)。

數(shù)據(jù)模型：包含了key-value的文檔集合

例子：CouchDB, MongoDB

優(yōu)點：數(shù)據(jù)模型自然，編程友好，快速開發(fā)，web友好，CRUD。

圖數(shù)據(jù)庫

源起： 歐拉和圖理論。

數(shù)據(jù)模型：節(jié)點和關系，也可處理鍵值對。

例子：AllegroGraph, InfoGrid, Neo4j

優(yōu)點：解決復雜的圖問題。

關系數(shù)據(jù)庫

源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的

數(shù)據(jù)模型：各種關系

例子：VoltDB, Clustrix, MySQL

優(yōu)點：高性能、可擴展的OLTP，支持SQL，物化視圖，支持事務，編程友好。

對象數(shù)據(jù)庫

源起：圖數(shù)據(jù)庫研究

數(shù)據(jù)模型：對象

例子：Objectivity, Gemstone

優(yōu)點：復雜對象模型，快速鍵值訪問，鍵功能訪問，以及圖數(shù)據(jù)庫的優(yōu)點。

Key-Value數(shù)據(jù)庫

源起：Amazon的論文 Dynamo 和 Distributed HashTables。

數(shù)據(jù)模型：鍵值對

例子：Membase, Riak

優(yōu)點：處理大量數(shù)據(jù)，快速處理大量讀寫請求。編程友好。

BigTable類型數(shù)據(jù)庫

源起：Google的論文 BigTable。

數(shù)據(jù)模型：列簇，每一行在理論上都是不同的

例子：HBase, Hypertable, Cassandra

優(yōu)點：處理大量數(shù)據(jù)，應對極高寫負載，高可用，支持跨數(shù)據(jù)中心， MapReduce。

數(shù)據(jù)結構服務

源起： ?

數(shù)據(jù)模型：字典操作，lists, sets和字符串值

例子：Redis

優(yōu)點：不同于以前的任何數(shù)據(jù)庫

網格數(shù)據(jù)庫

源起：數(shù)據(jù)網格和元組空間研究。

數(shù)據(jù)模型：基于空間的架構

例子：GigaSpaces, Coherence

優(yōu)點：適于事務處理的高性能和高擴展性

你的應用應該用什么?

關鍵是要意識到不同的應用需要不同的數(shù)據(jù)模型和產品。選擇合適的數(shù)據(jù)模型和產品。

要了解你的應用需要什么樣的數(shù)據(jù)模型可以看 What The Heck Are You Actually Using NoSQL For? 在這篇文章里我總結了一些特色各異的非常規(guī)的使用場景。

適應你的需求和應用場景。依次而為你就能找到最適合你的架構的產品。無論NoSQL還是SQL都不重要。

綜合考慮數(shù)據(jù)模型、產品特性和應用情景。不同產品功能各異，只憑數(shù)據(jù)模型來決定選擇誰是不可能的。

哪個產品具有你最需要的特點哪個就是最好的。

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

復雜事物，如果你不能承受數(shù)據(jù)丟失的風險或者你想要一個簡單的事務編程模型可以選擇關系數(shù)據(jù)庫和網格數(shù)據(jù)庫。

例子：一個庫存系統(tǒng)需要完整的ACID特性。如果我在買了一個東西后才被告知它已經售罄我會非常不快。不不想要補償，我只要我買的東西。

擴展性，NoSQL或SQL皆可，目標產品要支持水平擴展、分區(qū)、在線增減硬件、負載均衡、自動分片、數(shù)據(jù)平衡和容錯等特性。

追求高可用性，可用Bigtable類型的等支持最終一致性的數(shù)據(jù)庫。

需要處理長期的快速讀寫，可以看看文檔數(shù)據(jù)庫，Key-value數(shù)據(jù)庫或者內存數(shù)據(jù)庫，還可以考慮SSD。

要實現(xiàn)社會化網絡，第一選擇應該是圖數(shù)據(jù)庫。其次像Riak這樣支持關系的數(shù)據(jù)庫也可以。一個支持簡單SQL join操作的內存關系數(shù)據(jù)庫能夠處理數(shù)據(jù)量不大的情況。Redis’ set 和list 操作就是這樣。

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

需要不同的訪問方式和數(shù)據(jù)類型的話可以看看文檔數(shù)據(jù)庫，它們在這方面很靈活。

大數(shù)據(jù)量的離線分析首先應該考慮Hadoop，其次是其他支持MapReduce的產品。當然，支持MapReduce與擅長MapReduce處理不是一回事。

如需跨越多個數(shù)據(jù)中心，可選用基于Bigtable模型的產品，或其分布式的，能解決延遲問題，分區(qū)容錯性問題的產品。

CRUD類型的應用可以考慮文檔數(shù)據(jù)庫，這樣不需要join就可訪問復雜的數(shù)據(jù)結構。

搜索可以考慮Riak。

需要lists, sets, queues, publish-subscribe等數(shù)據(jù)結構的話，可以考慮Redis，它的分布式鎖等特性也非常有用。

編程友好，如果要使用JSON, HTTP, REST, Javascript等程序員喜聞樂見的數(shù)據(jù)類型，第一選擇就是文檔數(shù)據(jù)庫和Key-value數(shù)據(jù)庫。

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

用于實時事務處理的物化視圖，可以考慮VoltDB，非常適合于快速處理大量事務。

企業(yè)級支持及服務級協(xié)議 ，可以尋找市場上以此為賣點的產品，如Membase。

要記錄連續(xù)的大量數(shù)據(jù)，又對一致性無太高要求，可以看看Bigtable類型數(shù)據(jù)庫，因為它工作在分布式文件系統(tǒng)上，可以處理大規(guī)模的寫入請求。

需要盡可能使用簡單，請考慮PAAS方案，用這種方案你自己幾乎不需要做什么。

如果你的產品要賣給企業(yè)客戶請考慮關系數(shù)據(jù)庫，因為他們習慣于關系數(shù)據(jù)庫。

要動態(tài)構建對象間的關系，對象的屬性能夠動態(tài)加減，可以考慮圖數(shù)據(jù)庫，因為它不需要schema，可以在代碼中隨需建模。

要支持大影音文件，可以看看像S3這樣的存儲服務。NoSQL不適于存儲BLOBS，盡管MongoDB也提供了文件服務。

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

要快速批量上傳大量數(shù)據(jù)，得尋找支持這種場景的產品。但是大多數(shù)產品都不支持批量操作。

易于變化，要選擇支持動態(tài)schema的文檔數(shù)據(jù)庫和 Key-value數(shù)據(jù)庫。它支持可選域，不需要修改schema即可增加、減少域。

為了支持完整性約束，選擇支持SQL DDL的數(shù)據(jù)庫，可以在存儲過程或者應用代碼中實現(xiàn)。

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

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