各種 NoSQL 的比較

即使關係型資料庫依然是非常有用的工具，但它們持續幾十年的壟斷地位就要走到頭了。現在已經存在無數能撼動關係型資料庫地位的 NoSQL，當然，這些 NoSQL 還無法完全取代它們。（也就是說，關係型資料庫還是處理關係型事務的最佳方式。）

NoSQL 與 NoSQL 之間的區別，要遠大於不同的 SQL 資料庫之間的區別，所以軟體架構師必須要在項目一開始就選好一款合適的 NoSQL。

考慮到這種情況，本文為大家介紹以下幾種 NoSQL 之間的區別：Cassandra, Mongodb, CouchDB, Redis, Riak, Couchbase (ex-Membase), Hypertable, ElasticSearch, Accumulo, VoltDB, Kyoto Tycoon, Scalaris, Neo4j和HBase：

最流行的 NoSQL

MongoDB 2.2版

開發語言： C++

主要特性： 保留 SQL 中一些用戶友好的特性（查詢、索引等）

許可證： AGPL （驅動: 採用Apache許可協議）

數據傳輸格式： 自定義，二進位（ BSON 文檔格式）

• 主/從備份（支持自動故障切換功能）
• 自帶數據分片功能
• 通過 javascript 表達式提供數據查詢
• 伺服器端完全支持 javascript 腳本
• 比 CouchDB 更好的升級功能
• 數據存儲使用內存映射文件技術
• 功能豐富，性能不俗
• 最好開啟日誌功能（使用 --journal 參數）
• 在 32 位系統中，內存限制在 2.5GB
• 空資料庫佔用 192MB 空間
• 使用 GridFS（不是真正的文件系統）來保存大數據和元數據
• 支持對地理數據建立索引
• 可用於數據中心

應用場景：

• 動態查詢
• 喜歡定義索引，而不是使用 map/reduce 功能
• 高性能的大數據訪問
• 想使用 CouchDB 但數據變化頻度太大

使用案例：

想布署 MySQL 或 PostgreSQL，但預先定義數據字典讓你望而卻步。這個時候，MongoDB 是你可以考慮的選項

Riak 1.2版

開發語言： Erlang、C、以及一些 JavaScript

主要特性： 容錯機制（當一份數據失效，服務會自動切換到備份數據，保證服務一直在線 —— 譯者注）

許可證： Apache

數據傳輸格式： HTTP/REST 架構，或自定義二進位格式

• 可存儲 BLOB（binary large object，二進位大對象，比如一張圖片、一個聲音文件 —— 譯者注）
• 可在分散式存儲和複製存儲之間作協調
• 為了保證可驗證性和安全性，Riak 在 JS 和 Erlaing 中提供提交前（pre-commit）和提交後（post-commit）鉤子（hook）函數（你可以在提交數據前執行一個 hook，或者在提交數據後執行一個 hook —— 譯者注）
• JS 和 Erlang 提供映射和簡化（map/reduce）編程模型
• 使用 links 和 link walking ，用於圖形化資料庫（link 用於描述對象之間的關係，link walking 是一個用於查詢對象關係的進程 —— 譯者注）
• 次要標記（secondaty indeces，開發者在寫數據時可用多個名稱來標記一個對象 —— 譯者注），一次只能用一個
• 支持大數據對象（Luwak）（Luwak 是 Riak 中的一個服務層，為大數據量對象提供簡單的、面向文檔的抽象，彌補了 Riak 的 Key/Value 存儲格式在處理大數據對象方面的不足 —— 譯者注）
• 提供「開源」和「企業」兩個版本
• 基於Riak搜索的全文檢索、建立索引和查詢
• 正在將存儲後端從「Bitcask」遷移到 Google 的「LevelDB」上
• 企業版本提供無主模式的多點複製（各點地位平等，非主從架構）和SNMP監控功能

應用場景：

• 假如你想要類似 Dynamo 的資料庫，但不想要它的龐大和複雜
• 假如你需要良好的單點可擴展性、可用性和容錯能力，但不想為多點備份買單。

使用案例：

銷售點數據收集；工廠控制系統；必須實時在線的系統；需要易於升級的網站伺服器

CouchDB 1.2版

開發語言： Erlang

主要特性： 數據一致性；易於使用

許可證： Apache

數據傳輸格式： HTTP/REST

• 雙向複製！（一種同步技術，每個備份點都有一份它們自己的拷貝，允許用戶在存儲點斷線的情況下修改數據，當存儲節點重新上線時，CouchDB 會對所有節點同步這些修改 —— 譯者注）
• 支持持續同步或者點對點同步
• 支持衝突檢測
• 支持主主互備！（多個資料庫實時同步數據，起到備份和分攤用戶並行訪問量的作用 —— 譯者注）
• 多版本並發控制（MVCC），寫操作時不需要阻塞讀操作（或者說不需要鎖住資料庫的讀取操作）
• 向下兼容以前版本的數據
• 可靠的 crash-only 設計（所謂 crash-only，就是程序出錯時，只需重啟下程序，丟棄內存的所有數據，不需要執行複雜的數據恢復操作 —— 譯者注）
• 需要實時壓縮數據
• 視圖（文檔是 CouchDB 的核心概念，CouchDB 中的視圖聲明了如何從文檔中提取數據，以及如何對提取出來的數據進行處理 —— 譯者注）：內嵌映射和簡化（map/reduce）編程模型
• 格式化的views欄位：lists（包含把視圖運行結果轉換成非 JSON 格式的方法）和 shows（包含把文檔轉換成非 JSON 格式的方法）（在 CouchDB 中，一個 Web 應用是與一個設計文檔相對應的。在設計文檔中可以包含一些特殊的欄位，views 欄位包含永久的視圖定義 —— 譯者注）
• 能夠進行伺服器端文檔驗證
• 能夠提供身份認證功能
• 通過 _changes 函數實時更新數據！
• 鏈接處理（attachment：couchDB 的每份文檔都可以有一個 attachment，就像一份 email 有它的網址 —— 譯者注）
• 有個 CouchApps（第三方JS的應用）

應用場景：

• 用於隨機數據量多、需要預定義查詢的地方
• 用於版本控制比較重要的地方

使用案例：

可用於客戶關係管理（CRM），內容管理系統（CMS）；可用於主主互備甚至多機互備

Redis 2.4版

開發語言： C/C++

主要特性： 快到掉渣

許可證： BSD

數據傳輸格式： 類似 Telnet 式的交換

• Redis 是一個內存資料庫（in-memory database，簡稱 IMDB，將數據放在內存進行讀寫，這才是「快到掉渣」的真正原因 —— 譯者注），磁碟只是提供數據持久化（即將內存的數據寫到磁碟）的功能（這類資料庫被稱為「disk backed」資料庫）
• 當前不支持將磁碟作為 swap 分區，虛擬內存（VM）和 Diskstore 方式都沒加到此版本（Redis 的數據持久化共有4種方式：定時快照、基於語句追加、虛擬內存、diskstore。其中 VM 方式由於性能不好以及不穩定的問題，已經被作者放棄，而 diskstore 方式還在實驗階段 —— 譯者注）
• 主從備份
• 存儲結構為簡單的 key/value 或 hash 表
• 但是操作比較複雜，比如：ZREVRANGEBYSCORE
• 支持 INCR（INCR key 就是將key中存儲的數值加一 —— 譯者注）命令（對限速和統計有幫助）
• 支持sets數據類型（以及 union/diff/inter）
• 支持 lists （以及 queue/blocking pop）
• 支持 hash sets （多級對象）
• 支持 sorted sets（高效率的表，在範圍查找方面有優勢）
• 支持事務處理！
• 緩存中的數據可被標記為過期
• Pub/Sub 實現了消息訂閱和推送！

應用場景：

• 適合布署快速多變的小規模數據（可以完全運行在存在中）

使用案例：

股價系統、分析系統、實時數據收集系統、實時通信系統、以及取代 memcached

Google Bigtable 的衍生品

HBase 0.92.0 版

開發語言： Java

主要特性： 支持幾十億行*幾百萬列的大表

許可證： Apache

數據傳輸格式： HTTP/REST （也支持 Thrift 開發框架）

• 仿造 Google 的 BigTable
• 使用 Hadoop 的 HDFS 文件系統作為存儲
• 使用 Hadoop 的映射和簡化（map/reduce）編程模型
• 查詢條件被推送到伺服器端，由伺服器端執行掃描和過濾
• 對實時查詢進行優化
• 高性能的 Thrift gateway（訪問 HBase 的介面之一，特點是利用 Thrift 序列化支持多種語言，可用於異構系統在線訪問 HBase 表數據 —— 譯者注）
• 使用 HTTP 通信協議，支持 XML、Protobuf 以及二進位格式
• 支持基於 Jruby（JIRB）的shell
• 當配置信息有更改時，支持 rolling restart（輪流重啟數據節點）
• 隨機讀寫性能與 MySQL 一樣
• 一個集群可由不同類型的結點組成

應用場景：

• Hadoop 可能是在大數據上跑 Map/Reduce 業務的最佳選擇
• 如果你已經搭建了 Hadoop/HDFS 架構，HBase 也是你最佳的選擇。

使用案例：

搜索引擎；日誌分析系統；掃描大型二維非關係型數據表。

Cassandra 1.2版

開發語言： Java

主要特性： BigTable 和 Dynamo的完美結合（Cassandra 以 Amazon 專有的完全分散式的 Dynamo 為基礎，結合了Google BigTable基於 Column Family 的數據模型 —— 譯者注）

許可證： Apache

數據傳輸格式： Thrift 和自定義二進位 CQL3（即 Cassandra 查詢語言第3版 —— 譯者注）

• 可以靈活調整對數據的分散式或備份式存儲（通過設置N，R，W之間的關係）（NRW是資料庫布署模型中的概念，N是存儲網路中複製數據的節點數，R是網路中讀數據的節點數，W是網路中寫數據的節點數。一個環境中N值是固定的，設置不同的WR值組合能在數據可用性和數據一致性之間取得不同的平衡，可參考 CAP 定理 —— 譯者注）
• 按列查詢，按keys值排序後存儲（需要包含你想要搜索的任何信息）（Cassandra 的數據模型借鑒自 BigTable 的列式存儲，列式存儲可以理解成這樣，將行ID、列簇號，列號以及時間戳一起，組成一個Key，然後將Value按Key的順序進行存儲 —— 譯者注）
• 類似 BigTable 的特性：列、列簇
• 支持分散式 hash 表，使用「類 SQL」 語言 —— CQL（但沒有 SQL 中的 JOIN 語句）
• 可以為數據設置一個過期時間（使用 INSERT 指令）
• 寫性能遠高於讀性能（讀性能的瓶頸是磁碟 IO）
• 可使用 Hadoop 的映射和簡化（map/reduce）編程模型
• 所有節點都相似，這點與 Hadop/HBase 架構不同
• 可靠的跨數據中心備份解決方案

應用場景：

• 寫操作多於讀操作的環境（比如日誌系統）
• 如果系統全部由 JAVA 組成（「沒人會因為使用了 Apache 許可下的產品而被炒魷魚」（此句貌似是網上有人針對「Apache considered harmful」一文所作的回應 —— 譯者注））

使用案例：

銀行、金融機構；寫性能強於讀性能，所以 Cassandra 天生就是用來作數據分析的。

Hypertable 0.9.6.5版

開發語言： C++

主要特性： HBase 的精簡版，但比 HBase 更快

許可證： GPL 2.0

數據傳輸格式： Thrift，C++庫，或者 HQL shell

• 採用與 Google BigTable 相似的設計
• 運行在 Hadoop HDFS 之上
• 使用自己的「類 SQL」語言 —— HQL
• 可以根據 key 值、單元（cell）進行查找，可以在列簇上查找
• 查詢數據可以指定 key 或者列的範圍
• 由百度公司贊助（百度早在2009年就成為這個項目的贊助商了 —— 好吧譯者表示有點大驚小怪了:P）
• 能保留一個值的 N 個歷史版本
• 表在命名空間內定義
• 使用 Hadoop 的 Map/reduce 模型

應用場景：

• 假如你需要一個更好的HBase，就用Hypertable吧

使用案例：

與HBase一樣，就是搜索引擎被換了下；分析日誌數據的系統；適用於瀏覽大規模二維非關係型數據表。

Accumulo 1.4版

開發語言： Java 和 C++

主要特性： 一個有著單元級安全的 BigTable

許可證： Apache

數據傳輸格式： Thrift

• 另一個 BigTable 的複製品，也是跑在 Hadoop 的上層
• 單元級安全保證
• 允許使用比內存容量更大的數據列
• 通過 C++ 的 STL 可保持數據從 JAVA 環境的內存映射出來
• 使用 Hadoop 的 Map/reduce 模型
• 支持在伺服器端編程

應用場景：

• HBase的替代品

使用案例：

與HBase一樣，就是搜索引擎被換了下；分析日誌數據的系統；適用於瀏覽大規模二維非關係型數據表。

特殊用途

Neo4j V1.5M02 版

開發語言： Java

主要特性： 圖形化資料庫

許可證： GPL，AGPL（商業用途）

數據傳輸格式： HTTP/REST（或內嵌在 Java 中）

• 可獨立存在，或內嵌在 JAVA 的應用中
• 完全的 ACID 保證（包括正在處理的數據）
• 節點和節點的關係都可以擁有原數據
• 集成基於「模式匹配」的查詢語言（Cypher）
• 支持「Gremlin」圖形轉化語言
• 可對節點與節點關係進行索引
• 良好的自包含網頁管理技術
• 多個演算法實現高級文件查找功能
• 可對 key 與 key 的關係進行索引
• 優化讀性能
• 在 JAVA API 中實現事務處理
• 可運行腳本 Groovy 腳本
• 在商用版本中提供在線備份，高級監控和高可用性功能

應用場景：

• 適用於用圖形顯示複雜的交互型數據。

使用案例：

搜尋社交關係網、公共傳輸鏈、公路路線圖、或網路拓撲結構

ElasticSearch 0.20.1 版

開發語言： Java

主要特性： 高級搜索

許可證： Apache

數據傳輸格式： 通過 HTTP 使用 JSON 進行數據索引（插件：Thrift, memcached）

• 以 JSON 形式保存數據
• 提供版本升級功能
• 有父文檔和子文檔功能
• 文檔有過期時間
• 提供複雜多樣的查詢指令，可使用腳本
• 支持寫操作一致性的三個級別：ONE、QUORUM、ALL
• 支持通過分數排序
• 支持通過地理位置排序
• 支持模糊查詢（通過近似數據查詢等方式實現）
• 支持非同步複製
• 自動升級，也可通過設置腳本升級
• 可以維持自動的「統計組」（對調試很有幫助）
• 只有一個開發者（kimchy）

應用場景：

• 當你有可伸縮性很強的項目並且想擁有「高級搜索」功能。

使用案例：

可布署一個約會服務，提供不同年齡、不同地理位置、不同品味的客戶的交友需求。或者可以布署一個基於多項參數的排行榜。

其他

（不怎麼有名，但值得在這裡介紹一下）

Couchbase (ex-Membase) 2.0 版

開發語言： Erlang 和 C

主要特性： 兼容 Memcache，但數據是持久化的，並且支持集群

許可證： Apache

數據傳輸格式： 緩存和擴展（memcached + extensions）

• 通過 key 訪問數據非常快（20萬以上IOPS）
• 數據保存在磁碟（不像 Memcache 保存在內存中 —— 譯者注）
• 在主主互備中，所有節點數據是一致的
• 提供類似 Memcache 將數據保存在內存的功能
• 支持重複數據刪除功能
• 友好的集群管理 Web 界面
• 支持池和多叢結構的代理（利用 Moxi 項目）
• 支持 Map/reduce 模式
• 支持跨數據中心備份

應用場景：

• 適用於低延遲數據訪問系統，高並發和高可用系統。

使用案例：

低延遲可用於廣告定投；高並發可用於在線遊戲（如星佳公司）。

VoltDB 2.8.4.1版

開發語言： Java

主要特性： 快速的事務處理和數據變更

許可證： GPL 3

數據傳輸格式： 專有方式

• 運行在內存的關係型資料庫
• 可以將數據導入到 Hadoop
• 支持 ANSI SQL
• 在 JAVA 環境中保存操作過程
• 支持跨數據中心備份

應用場景：

• 適用於在大量傳入數據中保證快速反應能力的場合。

使用案例：

銷售點數據分析系統；工廠控制系統。

Scalaris 0.5版

開發語言： Erlang

主要特性： 分散式 P2P 鍵值存儲

許可證： Apache

數據傳輸和存儲的方式： 自有方式和 基於JSON的遠程過程調用協議

• 數據保存在內存中（使用 Tokyo Cabinet 作為後台時，數據可以持久化到磁碟中）
• 使用 YAWS 作為 Web 伺服器
• Has transactions (an adapted Paxos commit)
• 支持事務處理（基於 Paxos 提交）（Paxos 是一種基於消息傳遞模型的一致性演算法 —— 譯者注）
• 支持分散式數據的一致性寫操作
• 根據 CAP 定理，數據一致性要求高於數據可用性（前提是在一個比較大的網路分區環境下工作）（CAP 定理：數據一致性consistency、數據可用性availability、分隔容忍partition tolerance是分散式計算系統的三個屬性，一個分散式計算系統不可能同時滿足全部三項）

應用場景：

• 如果你喜歡 Erlang 並且想要使用 Mnesia 或 DETS 或 ETS，但你需要一個能使用多種語言（並且可擴展性強於 ETS 和 DETS）的技術，那就選它吧。

使用案例：

使用基於 Erlang 的系統，但是想通過 Python、Ruby 或 JAVA 訪問資料庫

Kyoto Tycoon 0.9.56版

開發語言： C++

主要特性： 輕量級網路資料庫管理系統

許可證： GPL

數據傳輸和存儲的方式： HTTP (TSV-RPC or REST)

• 基於 Kyoto Cabinet, 是 Tokyo Cabinet 的成功案例
• 支持多種存儲後端：Hash，樹、目錄等等（所有概念都是從 Kyoto Cabinet 那裡來的）
• Kyoto Cabinet 可以達到每秒100萬次插入/查詢操作（但是 Tycoon 由於瓶頸問題，性能比 Cabinet 要差點）
• 伺服器端支持 Lua 腳本語言
• 支持 C、JAVA、Python、Ruby、Perl、Lua 等語言
• 使用訪問者模式開發（visitor patten：讓開發者能在不修改類層次結構的前提下，定義該類層次結構的操作 —— 不明白就算了，譯者也不明白）
• 支持熱備、非同步備份
• 支持內存資料庫在後端執行快照
• 自動過期處理（可用來布署一個緩存伺服器）

應用場景：

• 當你想要一個很精準的後端存儲演算法引擎，並且速度是剛需的時候，玩玩 Kyoto Tycoon 吧。

使用案例：

緩存伺服器；股價查詢系統；數據分析系統；實時數據控制系統；實時交互系統；memcached的替代品。

當然，上述系統的特點肯定不止列出來這麼點。我只是列出了我認為很關鍵的信息。另外科技發展迅猛，技術改變得非常快。

附：現在下定論比較孰優孰劣還為時過早。上述資料庫的版本號以及特性我會一個一個慢慢更新。相信我，這些資料庫的特性不會變得很快。

via: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

譯者：bazz2 校對：wxy

本文由 LCTT 原創翻譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive