雖然SQL資料庫是非常有用的工具,但經歷了15年的一支獨秀之後壟斷即將被打破。 這只是時間問題:被迫使用關係資料庫,但最終發現不能適應需求的情況不勝枚舉。
但是NoSQL資料庫之間的不同,遠超過兩 SQL資料庫之間的差別。 這意味著軟體架構師更應該在專案開始時就選擇好一個適合的 NoSQL資料庫。 針對這種情況,這裡對 Cassandra、 Mongodb、CouchDB、Redis、Riak、Membase、Neo4j和HBase進行了比較:
(編注1:NoSQL:是一項全新的資料庫革命性運動,NoSQL的擁護者們提倡運用非關聯式的資料存儲。 現今的電腦體系結構在資料存儲方面要求具 備龐大的水準擴 展性,而NoSQL致力於改變這一現狀。 目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型資料庫。 參見NoSQL詞條。 )
1. CouchDB
所用語言: Erlang
特點:DB一致性,便於使用
使用許可: Apache
協定: HTTP/REST
雙向資料複製,
持續進行或臨時處理,
處理時帶衝突檢查,
因此,採用的是master-master複製(見編注2)
MVCC - 寫操作不阻塞讀操作
可保存檔之前的版本
Crash-only(可靠的)設計
需要不時地進行資料壓縮
視圖:嵌入式 映射/減少
格式化視圖:清單顯示
支援進行伺服器端文檔驗證
支援認證
根據變化即時更新
支援附件處理
因此, CouchApps(獨立的 js應用程式)
需要 jQuery程式庫
最佳應用場景:適用于資料變化較少,執行預定義查詢,進行資料統計的應用程式。 適用于需要提供資料版本支援的應用程式。
例如: CRM、CMS系統。 master-master複製對於多網站部署是非常有用的。
(編注2:master-master複製:是一種資料庫同步方法,允許資料在一組電腦之間共用資料,並且可以通過小組中任意成員在組內進行資料更新。 )
2. Redis
所用語言:C/C++
特點:運行異常快
使用許可: BSD
協定:類 Telnet
有硬碟存儲支援的記憶體資料庫,
但自2.0版本以後可以將資料交換到硬碟(注意, 2.4以後版本不支援該特性! )
Master-slave複製(見編注3)
雖然採用簡單資料或以鍵值索引的雜湊表,但也支援複雜操作,例如 ZREVRANGEBYSCORE。
INCR & co (適合計算極限值或統計資料)
支援 sets(同時也支援 union/diff/inter)
支援清單(同時也支援佇列;阻塞式 pop操作)
支援雜湊表(帶有多個域的物件)
支援排序 sets(高得分表,適用于範圍查詢)
Redis支援事務
支援將資料設置成過期資料(類似快速緩衝區設計)
Pub/Sub允許使用者實現消息機制
最佳應用場景:適用于資料變化快且資料庫大小可遇見(適合記憶體容量)的應用程式。
例如:股票價格、資料分析、即時資料搜集、即時通訊。
(編注3:Master-slave複製:如果同一時刻只有一台伺服器處理所有的複製請求,這被稱為 Master-slave複製,通常應用在需要提供高可用性的伺服器集群。 )
3. MongoDB
所用語言:C++
特點:保留了SQL一些友好的特性(查詢,索引)。
使用許可: AGPL(發起者: Apache)
協定: Custom, binary( BSON)
Master/slave複製(支援自動錯誤恢復,使用 sets 複製)
內建分片機制
支援 javascript運算式查詢
可在伺服器端執行任意的 javascript函數
update-in-place支援比CouchDB更好
在資料存儲時採用記憶體到檔案對應
對性能的關注超過對功能的要求
建議最好打開日誌功能(參數 --journal)
在32位作業系統上,資料庫大小限制在約2.5Gb
空資料庫大約占 192Mb
採用 GridFS存儲大資料或中繼資料(不是真正的檔案系統)
最佳應用場景:適用于需要動態查詢支援;需要使用索引而不是 map/reduce功能;需要對大資料庫有性能要求;需要使用 CouchDB但因為資料改變太頻繁而占滿記憶體的應用程式。
例如:你本打算採用 MySQL或 PostgreSQL,但因為它們本身自帶的預定義欄讓你望而卻步。
4. Riak
所用語言:Erlang和C,以及一些JAVAscript
特點:具備容錯能力
使用許可: Apache
協定: HTTP/REST或者 custom binary
可調節的分發及複製(N, R, W)
用 JavaScript or Erlang在操作前或操作後進行驗證和安全支援。
使用JavaScript或Erlang進行 Map/reduce
連接及連接遍歷:可作為圖形資料庫使用
索引:輸入中繼資料進行搜索(1.0版本即將支援)
大資料物件支援( Luwak)
提供「開源」和「企業」兩個版本
全文本搜索,索引,通過 Riak搜尋伺服器查詢( Beta版)
支援Masterless多網站複製及商業許可的 SNMP監控
最佳應用場景:適用于想使用類似 Cassandra(類似Dynamo)資料庫但無法處理 bloat及複雜性的情況。 適用于你打算做多網站複製,但又需要對單個網站的擴充性,可用性及出錯處理有要求的情況。
例如:銷售資料搜集,工廠控制系統;對宕機時間有嚴格要求;可以作為易於更新的 web伺服器使用。
5. Membase
所用語言: Erlang和C
特點:相容 Memcache,但同時兼具持久化和支援集群
使用許可: Apache 2.0
協定:分散式緩存及擴展
非常快速(200k+/秒),通過鍵值索引資料
可持久化存儲到硬碟
所有節點都是唯一的( master-master複製)
在記憶體中同樣支援類似分散式緩存的暫存單元
寫資料時通過去除重復資料來減少 IO
提供非常好的集群管理 web介面
更新軟體時軟無需停止資料庫服務
支援連接池和多工的連接代理
最佳應用場景:適用于需要低延遲資料訪問,高併發支援以及高可用性的應用程式
例如:低延遲資料訪問比如以廣告為目標的應用,高併發的 web 應用比如網路遊戲(例如 Zynga)
6. Neo4j
所用語言: JAVA
特點:基於關係的圖形資料庫
使用許可: GPL,其中一些特性使用 AGPL/商業許可
協定: HTTP/REST(或嵌入在 JAVA中)
可獨立使用或嵌入到 JAVA應用程式
圖形的節點和邊都可以帶有中繼資料
很好的自帶web管理功能
使用多種演算法支援路徑搜索
使用鍵值和關係進行索引
為讀操作進行優化
支援事務(用 JAVA api)
使用 Gremlin圖形遍歷語言
支援 Groovy腳本
支援線上備份,高級監控及高可靠性支援使用 AGPL/商業許可
最佳應用場景:適用于圖形一類資料。 這是 Neo4j與其他nosql資料庫的最顯著區別
例如:社會關係,公共交通網絡,地圖及網路拓譜
7. Cassandra
所用語言: JAVA
特點:對大型表格和 Dynamo支援得最好
使用許可: Apache
協定: Custom, binary (節約型)
可調節的分發及複製(N, R, W)
支援以某個範圍的鍵值通過列查詢
類似大表格的功能:列,某個特性的列集合
寫操作比讀操作更快
基於 Apache分散式平臺盡可能地 Map/reduce
我承認對 Cassandra有偏見,一部分是因為它本身的臃腫和複雜性,也因為 JAVA的問題(配置,出現異常,等等)
最佳應用場景:當使用寫操作多過讀操作(記錄日誌)如果每個系統組建都必須用 JAVA編寫(沒有人因為選用 Apache的軟體被解雇)
例如:銀行業,金融業(雖然對於金融交易不是必須的,但這些產業對資料庫的要求會比它們更大)寫比讀更快,所以一個自然的特性就是即時資料分析
8. HBase
(配合 ghshephard使用)
所用語言: JAVA
特點:支援數十億行X上百萬列
使用許可: Apache
協定:HTTP/REST (支援 php/73" rel="nofollow" style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; color: rgb(68, 102, 187); outline-width: 0px; outline-style: initial; outline-color: initial; ">Thrift,見編注4)
在 BigTable之後建模
採用分散式架構 Map/reduce
對即時查詢進行優化
高性能 Thrift閘道
通過在server端掃描及過濾實現對查詢操作預判
支援 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基於 Jruby( JIRB)的shell
對配置改變和較小的升級都會重新回滾
不會出現單點故障
堪比MySQL的隨機訪問性能
最佳應用場景:適用于偏好BigTable:)並且需要對大資料進行隨機、即時訪問的場合。
例如: Facebook消息資料庫(更多通用的用例即將出現)
編注4:Thrift 是一種介面定義語言,為多種其他語言提供定義和創建服務,由Facebook開發並開源。
當然,所有的系統都不只具有上面列出的這些特性。 這裡我僅僅根據自己的觀點列出一些我認為的重要特性。 與此同時,技術進步是飛速的,所以上述的內容肯定需要不斷更新。 我會盡我所能地更新這個清單。