from:http://tech.it168.com/a2015/0303/1708/000001708320.shtml

一、縱覽各種資料模型

　　這些模型的分類方法來自於Emil Eifrem 和 NoSQL databases。

　　1. 文件資料庫

　　源起：受Lotus Notes啟發。

　　資料模型：包含了key-value的文件集合

　　例子：CouchDB, MongoDB

　　優點：資料模型自然，程式設計友好，快速開發，web友好，CRUD。

　　2.圖資料庫

　　源起： 尤拉和圖理論。

　　資料模型：節點和關係，也可處理鍵值對。

　　例子：AllegroGraph, InfoGrid, Neo4j

　　優點：解決複雜的圖問題。

　　3.關係資料庫

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

　　資料模型：各種關係

　　例子：VoltDB, Clustrix, MySQL

　　優點：高效能、可擴充套件的OLTP，支援SQL，物化檢視，支援事務，程式設計友好。

　　4.物件資料庫

　　源起：圖資料庫研究

　　資料模型：物件

　　例子：Objectivity, Gemstone

　　優點：複雜物件模型，快速鍵值訪問，鍵功能訪問，以及圖資料庫的優點。

　　5.Key-Value資料庫

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

　　資料模型：鍵值對

　　例子：Membase, Riak

　　優點：處理大量資料，快速處理大量讀寫請求。程式設計友好。

　　6.BigTable型別資料庫

　　源起：Google的論文 BigTable。

　　資料模型：列簇，每一行在理論上都是不同的

　　例子：HBase, Hypertable, Cassandra

　　優點：處理大量資料，應對極高寫負載，高可用，支援跨資料中心， MapReduce。

　　6.資料結構服務

　　源起： ?

　　資料模型：字典操作，lists, sets和字串值

　　例子：Redis

　　優點：不同於以前的任何資料庫

　　7.網格資料庫

　　源起：資料網格和元組空間研究。

　　資料模型：基於空間的架構

　　例子：GigaSpaces, Coherence

　　優點：適於事務處理的高效能和高擴充套件性

　　二、你的應用應該用什麼?

　　關鍵是要意識到不同的應用需要不同的資料模型和產品。選擇合適的資料模型和產品。

　　要了解你的應用需要什麼樣的資料模型可以看 What The Heck Are You Actually Using NoSQL For? 在這篇文章裡我總結了一些特色各異的非常規的使用場景。

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

　　綜合考慮資料模型、產品特性和應用情景。不同產品功能各異，只憑資料模型來決定選擇誰是不可能的。

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

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

　　複雜事物，如果你不能承受資料丟失的風險或者你想要一個簡單的事務程式設計模型可以選擇關係資料庫和網格資料庫。

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

　　擴充套件性，NoSQL或SQL皆可，目標產品要支援水平擴充套件、分割槽、線上增減硬體、負載均衡、自動分片、資料平衡和容錯等特性。

　　追求高可用性，可用Bigtable型別的等支援最終一致性的資料庫。

　　需要處理長期的快速讀寫，可以看看文件資料庫，Key-value資料庫或者記憶體資料庫，還可以考慮SSD。

　　要實現社會化網路，第一選擇應該是圖資料庫。其次像Riak這樣支援關係的資料庫也可以。一個支援簡單SQL join操作的記憶體關係資料庫能夠處理資料量不大的情況。Redis’ set 和list 操作就是這樣。

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

　　需要不同的訪問方式和資料型別的話可以看看文件資料庫，它們在這方面很靈活。

　　大資料量的離線分析首先應該考慮Hadoop，其次是其他支援MapReduce的產品。當然，支援MapReduce與擅長MapReduce處理不是一回事。

　　如需跨越多個資料中心，可選用基於Bigtable模型的產品，或其分散式的，能解決延遲問題，分割槽容錯性問題的產品。

　　CRUD型別的應用可以考慮文件資料庫，這樣不需要join就可訪問複雜的資料結構。

　　搜尋可以考慮Riak。

　　需要lists, sets, queues, publish-subscribe等資料結構的話，可以考慮Redis，它的分散式鎖等特性也非常有用。

　　程式設計友好，如果要使用JSON, HTTP, REST, Javascript等程式設計師喜聞樂見的資料型別，第一選擇就是文件資料庫和Key-value資料庫。

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

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

　　企業級支援及服務級協議 ，可以尋找市場上以此為賣點的產品，如Membase。

　　要記錄連續的大量資料，又對一致性無太高要求，可以看看Bigtable型別資料庫，因為它工作在分散式檔案系統上，可以處理大規模的寫入請求。

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

　　如果你的產品要賣給企業客戶請考慮關係資料庫，因為他們習慣於關係資料庫。

　　要動態構建物件間的關係，物件的屬效能夠動態加減，可以考慮圖資料庫，因為它不需要schema，可以在程式碼中隨需建模。

　　要支援大影音檔案，可以看看像S3這樣的儲存服務。NoSQL不適於儲存BLOBS，儘管MongoDB也提供了檔案服務。

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

　　要快速批量上傳大量資料，得尋找支援這種場景的產品。但是大多數產品都不支援批量操作。

　　易於變化，要選擇支援動態schema的文件資料庫和 Key-value資料庫。它支援可選域，不需要修改schema即可增加、減少域。

　　為了支援完整性約束，選擇支援SQL DDL的資料庫，可以在儲存過程或者應用程式碼中實現。

　　深度連線用圖資料庫，它支援實體鍵間的快速定位。