數(shù)據(jù)庫各個派系的起源和應(yīng)用場景
現(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é)點和關(guān)系，也可處理鍵值對。
例子：AllegroGraph, InfoGrid, Neo4j
優(yōu)點：解決復(fù)雜的圖問題。
關(guān)系數(shù)據(jù)庫
源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
數(shù)據(jù)模型：各種關(guān)系
例子：VoltDB, Clustrix, MySQL
優(yōu)點：高性能、可擴展的OLTP，支持SQL，物化視圖，支持事務(wù)，編程友好。
對象數(shù)據(jù)庫
源起：圖數(shù)據(jù)庫研究
數(shù)據(jù)模型：對象
例子：Objectivity, Gemstone
優(yōu)點：復(fù)雜對象模型，快速鍵值訪問，鍵功能訪問，以及圖數(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ù)，應(yīng)對極高寫負載，高可用，支持跨數(shù)據(jù)中心， MapReduce。
數(shù)據(jù)結(jié)構(gòu)服務(wù)
源起： ?
數(shù)據(jù)模型：字典操作，lists, sets和字符串值
例子：Redis
優(yōu)點：不同于以前的任何數(shù)據(jù)庫
網(wǎng)格數(shù)據(jù)庫
源起：數(shù)據(jù)網(wǎng)格和元組空間研究。
數(shù)據(jù)模型：基于空間的架構(gòu)
例子：GigaSpaces, Coherence
優(yōu)點：適于事務(wù)處理的高性能和高擴展性
你的應(yīng)用應(yīng)該用什么?
關(guān)鍵是要意識到不同的應(yīng)用需要不同的數(shù)據(jù)模型和產(chǎn)品。選擇合適的數(shù)據(jù)模型和產(chǎn)品。
要了解你的應(yīng)用需要什么樣的數(shù)據(jù)模型可以看 What The Heck Are You Actually Using NoSQL For? 在這篇文章里我總結(jié)了一些特色各異的非常規(guī)的使用場景。
適應(yīng)你的需求和應(yīng)用場景。依次而為你就能找到最適合你的架構(gòu)的產(chǎn)品。無論NoSQL還是SQL都不重要。
綜合考慮數(shù)據(jù)模型、產(chǎn)品特性和應(yīng)用情景。不同產(chǎn)品功能各異，只憑數(shù)據(jù)模型來決定選擇誰是不可能的。
哪個產(chǎn)品具有你最需要的特點哪個就是***的。
假如你的應(yīng)用有以下需求：
復(fù)雜事物，如果你不能承受數(shù)據(jù)丟失的風險或者你想要一個簡單的事務(wù)編程模型可以選擇關(guān)系數(shù)據(jù)庫和網(wǎng)格數(shù)據(jù)庫。
例子：一個庫存系統(tǒng)需要完整的ACID特性。如果我在買了一個東西后才被告知它已經(jīng)售罄我會非常不快。不不想要補償，我只要我買的東西。
擴展性，NoSQL或SQL皆可，目標產(chǎn)品要支持水平擴展、分區(qū)、在線增減硬件、負載均衡、自動分片、數(shù)據(jù)平衡和容錯等特性。
追求高可用性，可用Bigtable類型的等支持最終一致性的數(shù)據(jù)庫。
需要處理長期的快速讀寫，可以看看文檔數(shù)據(jù)庫，Key-value數(shù)據(jù)庫或者內(nèi)存數(shù)據(jù)庫，還可以考慮SSD。
要實現(xiàn)社會化網(wǎng)絡(luò)，***選擇應(yīng)該是圖數(shù)據(jù)庫。其次像Riak這樣支持關(guān)系的數(shù)據(jù)庫也可以。一個支持簡單SQL join操作的內(nèi)存關(guān)系數(shù)據(jù)庫能夠處理數(shù)據(jù)量不大的情況。Redis’ set 和list 操作就是這樣。
假如你的應(yīng)用有以下需求：
需要不同的訪問方式和數(shù)據(jù)類型的話可以看看文檔數(shù)據(jù)庫，它們在這方面很靈活。
大數(shù)據(jù)量的離線分析首先應(yīng)該考慮Hadoop，其次是其他支持MapReduce的產(chǎn)品。當然，支持MapReduce與擅長MapReduce處理不是一回事。
如需跨越多個數(shù)據(jù)中心，可選用基于Bigtable模型的產(chǎn)品，或其分布式的，能解決延遲問題，分區(qū)容錯性問題的產(chǎn)品。
CRUD類型的應(yīng)用可以考慮文檔數(shù)據(jù)庫，這樣不需要join就可訪問復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。
搜索可以考慮Riak。
需要lists, sets, queues, publish-subscribe等數(shù)據(jù)結(jié)構(gòu)的話，可以考慮Redis，它的分布式鎖等特性也非常有用。
編程友好，如果要使用JSON, HTTP, REST, Javascript等程序員喜聞樂見的數(shù)據(jù)類型，***選擇就是文檔數(shù)據(jù)庫和Key-value數(shù)據(jù)庫。
假如你的應(yīng)用有以下需求：
用于實時事務(wù)處理的物化視圖，可以考慮VoltDB，非常適合于快速處理大量事務(wù)。
企業(yè)級支持及服務(wù)級協(xié)議 ，可以尋找市場上以此為賣點的產(chǎn)品，如Membase。
要記錄連續(xù)的大量數(shù)據(jù)，又對一致性無太高要求，可以看看Bigtable類型數(shù)據(jù)庫，因為它工作在分布式文件系統(tǒng)上，可以處理大規(guī)模的寫入請求。
需要盡可能使用簡單，請考慮PAAS方案，用這種方案你自己幾乎不需要做什么。
如果你的產(chǎn)品要賣給企業(yè)客戶請考慮關(guān)系數(shù)據(jù)庫，因為他們習慣于關(guān)系數(shù)據(jù)庫。
要動態(tài)構(gòu)建對象間的關(guān)系，對象的屬性能夠動態(tài)加減，可以考慮圖數(shù)據(jù)庫，因為它不需要schema，可以在代碼中隨需建模。
要支持大影音文件，可以看看像S3這樣的存儲服務(wù)。NoSQL不適于存儲BLOBS，盡管MongoDB也提供了文件服務(wù)。
假如你的應(yīng)用有以下需求：
要快速批量上傳大量數(shù)據(jù)，得尋找支持這種場景的產(chǎn)品。但是大多數(shù)產(chǎn)品都不支持批量操作。
易于變化，要選擇支持動態(tài)schema的文檔數(shù)據(jù)庫和 Key-value數(shù)據(jù)庫。它支持可選域，不需要修改schema即可增加、減少域。
為了支持完整性約束，選擇支持SQL DDL的數(shù)據(jù)庫，可以在存儲過程或者應(yīng)用代碼中實現(xiàn)。
深度連接用圖數(shù)據(jù)庫，它支持實體鍵間的快速定位。
