資料庫各個派系的起源和應用情境

資料庫各個派系的起源和應用情境

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

首先，我們要縱覽各種資料模型。這些模型的分類方法來自於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類型資料庫，因為它工作在Distributed File System上，可以處理大規模的寫入請求。

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

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

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

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

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

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

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

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

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