NoSQL資料庫 Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison

轉載：http://hi.baidu.com/yandavid/blog/item/04f0d1952850ab52d1135e94.html

NoSQL世界的幾個重要理論

1.CAP理論

CAP理論無疑是導致技術趨勢由關聯式資料庫系統向NoSQL系統轉變的最重要原因。

CAP（Consistency,Availability,Patition tolerance）理論論述的是在任何分布式系統中，只可能滿足一致性，可用性及分區容忍性三者中的兩者，不可能全部都滿足。所以不用花時間精力在如何滿足所有三者上面。

原理的證明簡單的說就是，在保證分區容忍性的情形下，一致性和可用性是不可能同時達到的，高一致性就得犧牲可用性，高可用性就得犧牲可用性。（為什麼要保證分區容忍性？因為在網路應用越來越大的今天，資料分區是一個基本要求）

證明過程：Brewer’s CAP Theorem

2.一致性hash

這個不用多說了，用過MC的人應該都清楚，直接：

3.MapReduce

MapReduce思想分為Map和Reduce兩個部分，簡單來說Map就是將大的計算量分區，以便並行的進行計算，Reduce就是將並行計算的結果進行組合，以便得到一個最終的輸出。

更詳細的描述見wikipedia：MapReduce

Google關於MapReduce的文檔PDF版：MapReduce: Simplified Data Processing on Large Clusters

4.Gossip

Gossip是一個應用於p2p中的理論（不是當下流行的Gossip Girl［緋聞女孩］），他的主要過程是通過一個N節點叢集中的每一個節點與所有其它N-1個節點進行通訊，實現資料的同步，Gossip基於不要求叢集中有一個Master存在，並能以病毒傳播的方式將一個節點的變更傳達到所有其它節點，而系統增加或減少一個結點的成本幾乎為0。

更詳盡描述見wikipedia：Gossip

 

雖然SQL資料庫佔據統治地位15年，但現在該是結束的時候了，這隻是時間問題。在NoSQL如日中天的今天，各種NoSQL產品可謂百花齊放，但每一個產品都有自己的特點，有長處也有不適合的情境。本文對Cassandra、Mongodb、CouchDB、Redis、Riak以及HBase進行了多方面的特點分析。

CouchDB使用的開發語言為Erlang，遵循Apache許可，使用HTTP/REST協議。主要優點是可保持資料一致性和易用性，同時允許多站部署。CouchDB主要適用於積累性的、並且較少改變資料的應用。例如CRM、CMS systems等。

Redis使用的開發語言為C/C++，遵循BSD許可，使用Telnet-like協議。主要優點是速度極快。Redis主要適用資料集資料時常變化的應用。但記憶體佔用較大。主要應用於金融機構、即時分析、即時資料收集、即時通訊等。

MongoDB使用的開發語言為C++，遵循AGPL(Drivers:Apache)，使用Custom，binary(BSON)協議。MongoDB適用於動態查詢、且定義索引比Map/Reduce效能更佳的地方。不過與CouchDB一樣其資料變動較多，需要大容量磁碟。MongoDB可在任何Mysql/PostgreSQL的環境下使用。

Cassandra使用的開發語言是Java，遵循Apache，使用Custom，binary(Thrift)協議。Cassandra適用於寫入多於查詢的場合，例如銀行和金融行業等需要即時資料分析的行業。

Riak使用的開發語言是Erlang & C、Javascript。遵循Apache，使用HTTP/REST協議。Riak具有高容錯性的特點。Riak和Cassandra非常相似。當需要高擴充性和高容錯性時Riak是不錯的選擇。但多網站的部署需要付費。Riak適用於銷售資料錄入、工控系統等一些不允許宕機的場合。

HBase使用的開發語言為Java，遵循Apache，使用HTTP/REST協議。HBase可支援高達數十億的列。如果你喜愛BigTable並且需要一個能提供隨機即時讀寫訪問你海量資料的資料庫，HBase是不錯的選擇。HBase現被Facebook郵件資料庫所使用。

 

CouchDB Written in: Erlang Main point: DB consistency, ease of use
License: Apache Protocol: HTTP/REST Bi-directional (!) replication, continuous or ad-hoc, with conflict detection, thus, master-master replication. (!) MVCC - write operations do not block reads Previous versions of documents
are available Crash-only (reliable) design Needs compacting from time to time Views: embedded map/reduce Formatting views: lists & shows Server-side document validation possible Authentication possible Real-time updates via _changes (!) Attachment handling
thus, CouchApps (standalone js apps) jQuery library included

Best used: For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.

For example: CRM, CMS systems. Master-master replication is an especially interesting feature, allowing easy multi-site deployments.

Redis Written in: C/C++ Main point: Blazing fast
License: BSD Protocol: Telnet-like Disk-backed in-memory database, but since 2.0, it can swap to disk. Master-slave replication Simple keys and values, but
complex operations like ZREVRANGEBYSCORE INCR & co (good for rate limiting or statistics) Has sets (also union/diff/inter) Has lists (also a queue; blocking pop) Has hashes (objects of multiple fields) Of all these databases,
only Redis does transactions (!) Values can be set to expire (as in a cache) Sorted sets (high score table, good for range queries) Pub/Sub and WATCH on data changes (!)

Best used: For rapidly changing data with a foreseeable database size (should fit mostly in memory).

For example: Stock prices. Analytics. Real-time data collection. Real-time communication.

MongoDB Written in: C++ Main point: Retains some friendly properties of SQL. (Query, index)
License: AGPL (Drivers: Apache) Protocol: Custom, binary (BSON) Master/slave replication Queries are javascript expressions Run arbitrary javascript functions server-side Better update-in-place than CouchDB Sharding built-in
Uses memory mapped files for data storage Performance over features After crash, it needs to repair tables Better durablity coming in V1.8

Best used: If you need dynamic queries. If you prefer to define indexes, not map/reduce functions. If you need good performance on a big DB. If you wanted CouchDB, but your data changes too much, filling up disks.

For example: For all things that you would do with MySQL or PostgreSQL, but having predefined columns really holds you back.

Cassandra Written in: Java Main point: Best of BigTable and Dynamo
License: Apache Protocol: Custom, binary (Thrift) Tunable trade-offs for distribution and replication (N, R, W) Querying by column, range of keys BigTable-like features: columns, column families Writes are much faster than
reads (!) Map/reduce possible with Apache Hadoop I admit being a bit biased against it, because of the bloat and complexity it has partly because of Java (configuration, seeing exceptions, etc)

Best used: When you write more than you read (logging). If every component of the system must be in Java. ("No one gets fired for choosing Apache's stuff.")

For example: Banking, financial industry (though not necessarily for financial transactions, but these industries are much bigger than that.) Writes are faster than reads, so one natural niche is real time data analysis.

Riak Written in: Erlang & C, some Javascript Main point: Fault tolerance
License: Apache Protocol: HTTP/REST Tunable trade-offs for distribution and replication (N, R, W) Pre- and post-commit hooks, for validation and security. Built-in full-text search Map/reduce in javascript or Erlang Comes in
"open source" and "enterprise" editions

Best used: If you want something Cassandra-like (Dynamo-like), but no way you're gonna deal with the bloat and complexity. If you need very good single-site scalability, availability and fault-tolerance, but you're ready to pay for multi-site
replication.

For example: Point-of-sales data collection. Factory control systems. Places where even seconds of downtime hurt.

HBase

(With the help of ghshephard)

Written in: Java Main point: Billions of rows X millions of columns
License: Apache Protocol: HTTP/REST (also Thrift) Modeled after BigTable Map/reduce with Hadoop Query predicate push down via server side scan and get filters Optimizations for real time queries A high performance Thrift gateway
HTTP supports XML, Protobuf, and binary Cascading, hive, and pig source and sink modules Jruby-based (JIRB) shell No single point of failure Rolling restart for configuration changes and minor upgrades Random access performance is like MySQL

Best used: If you're in love with BigTable. And when you need random, realtime read/write access to your Big Data.

For example: Facebook Messaging Database (more general example coming soon)