MySQL、HBase、ES的特色和區別

時間 2019-11-17

標籤 mysql hbase 特色區別欄目 MySQL 简体版

原文原文鏈接

MySQL：關係型數據庫，主要面向OLTP，支持事務，支持二級索引，支持sql，支持主從、Group Replication架構模型（本文所有以Innodb爲例，不涉及別的存儲引擎）。javascript

HBase：基於HDFS，支持海量數據讀寫（尤爲是寫），支持上億行、上百萬列的，面向列的分佈式NoSql數據庫。自然分佈式，主從架構，不支持事務，不支持二級索引，不支持sql。html

ElasticSearch：ES是一款分佈式的全文檢索框架，底層基於Lucene實現，雖然ES也提供存儲，檢索功能，但我一直不認爲ES是一款數據庫，可是隨着ES功能愈來愈強大，與數據庫的界限也愈來愈模糊。自然分佈式，p2p架構，不支持事務，採用倒排索引提供全文檢索。java

數據存儲方式

假設有這樣一張人員信息表：node

MySQL中要提早定義表結構，也就是說表共有多少列（屬性）須要提早定義好，而且同時須要定義好每一個列所佔用的存儲空間。數據以行爲單位組織在一塊兒的，假如某一行的某一列沒有數據，也須要佔用存儲空間。git

HBase則是以列爲單位存儲數據，每一列就是一個key-value，HBase的表列（屬性）不用提早定義，並且列能夠動態擴展，好比人員信息表中須要添加一個新的「address」字段，MySQL須要提早alter表，HBase的話直接插入便可。web

ES比較靈活，索引中的field類型能夠提早定義（定義mapping），也能夠不定義，若是不定義，會有一個默認類型，不過出於可控性考慮，關鍵字段最好提早定義好。（Solr中必須提早定義好schema.xml文件）redis

上圖簡單的展現了數據在MySQL和HBase中存儲差別（和真實的狀況還有差距），能夠看到即便第二條記錄的sex字段爲空，MySQL依然會爲該字段保留空間，由於後續有可能會有update語句來更新該記錄，補上sex內容。而HBase則是把每一列都看作是一條記錄，row+列名做爲key，data做爲value，依次存放。假如某一行的某一個列沒有數據，則直接跳過該列。對於稀疏矩陣的大表，HBase能節省空間。sql

看到這裏，你們是否會有一個疑問：使用HBase存儲時，假如此時須要添加第二行的sex內容，如何實現呢，數據是否連續？後面介紹讀寫流程會解釋。shell

不同的ES

說完MySQL、HBase，這裏要重點說一下ES，ES的存儲方式和上面兩個都不同，MySQL和HBase是將數據按不一樣的方式進行存儲，好歹它們存的仍是數據，而ES則存的是倒排索引。咱們先來了解一下什麼是倒排索引，以及爲何須要倒排索引（Inverted Index）：數據庫

咱們確定都會這樣的經歷：偶然看到一段很好的文字，可是殊不知道出處，這時候去圖書館，一個一個翻找，無疑是大海撈針，這個時候腫麼辦呢，因而便有了全文檢索這項技術，而它最核心的就是倒排索引。假若有以下文檔：

咱們想要知道有哪些文檔含有you這個關鍵字，首先能夠建立一個倒排索引，格式以下：

咱們把前面的部分叫作dictionary（字典），裏面的每一個單詞叫作term，後面的文檔列表叫作psoting-list，list中記錄了全部含有該term的文檔id，兩個組合起來就是一個完成的倒排索引（Inverted Index）。可以看出，假如須要查找含有「you」的文檔時，根據dictionary而後找到對應的posting-list便可。

而全文檢索中，建立Inverted Index是最關鍵也是最耗時的過程，並且真正的Inverted Index結構也遠比圖中展現的複雜，不只須要對文檔進行分詞（ES裏中文能夠自定義分詞器），還要計算TF-IDF，方便評分排序（當查找you時，評分決定哪一個doc顯示在前面，也就是所謂的搜索排名），壓縮等操做。每接收一個document，ES就會將其信息更新在倒排索引中。

從這裏咱們就能夠看出ES和MySQL、HBase的存儲仍是有很大的區別。並且ES不只包含倒排索引，默認同時還會把文檔doc存儲起來，因此當咱們使用ES時，也能拿到完整的文檔信息，因此某種程度上，感受就像在使用數據庫同樣，可是也能夠配置不存儲文檔信息，這時只能根據查詢條件獲得文檔id，並不能拿到完整的文檔內容。

總結：MySQL行存儲的方式比較適合OLTP業務。列存儲的方式比較適合OLAP業務，而HBase採用了列族的方式平衡了OLTP和OLAP，支持水平擴展，若是數據量比較大、對性能要求沒有那麼高、而且對事務沒有要求的話，HBase也是個不錯的考慮。ES默認對全部字段都建了索引，因此比較適合複雜的檢索或全文檢索。

容災

數據庫系統，數據的完整性和一致性是很是重要的問題，數據庫進程掛了，能夠恢復，可是數據丟了，就再也找不回來了。下面說說各個系統的容災方式。

MySQL

單節點：

如今的數據庫廣泛採用write ahead log策略來避免數據丟失，wal機制簡單的解釋就是：在提交CUD操做，數據寫入內存的同時，也要寫一份到log文件中，並且要保證log數據落盤成功後才能向client返回操做成功，假如此時數據庫宕機，已經提交到內存的數據還沒來得及刷回磁盤，重啓數據庫後能夠經過回放log文件來恢復內存中的數據。

問題又來了：寫log的話，對性能影響會不會很大？其實多少仍是有點影響的，不過log文件是順序寫入，相對來講爲了保證數據完整性，這點性能損失仍是能夠接受的。

單機狀況下，MySQL的innodb經過redo log和checkpoint機制來保證數據的完整性。由於怕log越寫越大，佔用過多磁盤，並且當log特別大的時候，恢復起來也比較耗時。而checkpoint的出現就是爲了解決這些問題。

checkpoint機制保證了以前的log數據必定已經刷回磁盤，當數據庫宕機時，只須要將checkpoint以後的log回放便可，數據庫會定時作checkpoint，這樣就保證了數據庫恢復的效率。

可是考慮到若是硬件故障時機器沒法啓動，或者磁盤故障時數據沒法恢復，checkpoint+redo log方案也就不起做用了，爲了防止這種故障，MySQL還提供了master-slave和group replication 集羣級別的容災方案。

Master-Slave架構主要思路是：master負責業務的讀寫請求，而後經過binlog複製到slave節點，這樣若是主庫由於不可抗拒因素沒法恢復時，從庫能夠提供服務，這裏咱們用了「複製「這個詞，而不是」同步「，由於基於binlog複製的方案並不能作到主從數據強一致，這種主從同步方式會致使主庫掛掉以後從庫有可能丟失少許的數據。

正是由於主從架構存在數據不一致的問題，因此MySQL5.7出現了Mysql Group Replication方案，mgr採用paxos協議實現了數據節點的強同步，保證了全部節點均可以寫數據，而且全部節點讀到的也是最新的數據。（原諒本人水平有限，說不清楚主從架構爲何會丟數據，也講不清楚mgr是怎麼實現的，可是這裏強烈推薦一本前司同事的書：《MySQL運維內參》，裏面詳細解釋了Master-Slave和Group Replication 的架構，是深刻理解Mysql的不二之選，聽說本書的出現拉低了DBA的門檻，沒有任何打廣告的嫌疑^ ^）

HBase：

HBase的容災和MySQL的單機容災有些相似，但具體實現上仍是頗有本身的特色。在介紹HBase容災前，咱們先來了解一下HBase和HDFS的關係：HBase中的數據都是存放在HDFS上，能夠簡單理解HBase分爲兩層：一層爲NoSql service（即提供分佈式檢索服務），一層是分佈式文件系統（數據真正存放的位置，目前採用HDFS）。HBase中region分佈在不一樣的regionserver上，client端經過meta表來定位數據在在哪一個regionserver的region上，而後獲取數據，可是數據有可能並不必定在該regionserver本地保存，每一個region都知道本身對應的數據在HDFS的哪些數據塊上，最後經過訪問HDFS來獲取數據，尤爲當HBase和HDFS部署在不一樣的集羣上時，數據的讀寫徹底是經過RPC來實現，爲了減小RPC的開銷，保證服務穩定，每每會將HBase和HDFS部署在同一個集羣。同理，當一個regionserver掛了，region能夠快速切換到別的regionserver上，由於只涉及到回放Log，並不會移動已經落盤的數據，並且HBase也會控制log的大小，來減小恢復時間。

HBase也是採用寫log的方式防止數據丟失，數據寫內存的同時，同時也會寫入HLog，HLog也是存儲在HDFS上，寫入HLog後纔會認爲數據寫成功，某個regionserver掛掉以後，master將故障機器上的regions調度到別的regionserver上，regionserver經過回放HLog來恢復region的數據，恢復成功後，region從新上線，因爲log是直接寫在HDFS上，因此不用擔憂單個節點掛掉log數據丟失的問題。

這裏引出一個問題：回放HLog的時候，正在被恢復的region會短期不可用，直到HLog回放成功。HBase1.0版本中加入了region replicas功能，也就是提供一個slave region，當主region掛掉的時候，依然能夠經過slave replicas來讀數據，可是slave不提供write，並且slave replicas和primary region並非強同步的，並不必定總能讀到最新的數據，因此開啓該功能時，也要考慮本身業務是否必需要求強一致。

HBase也提供了cluster replication，目的是爲了作機房級的容災，boss說如今cluster replication功能還有些bug，目前也在積極優化改進，相信之後會cluster replication會愈來愈完善。

ES：

ES的容災也是採用寫log的方式，與HBase不一樣的是，ES的節點保存各自的log，這點跟MySQL相似，log是存放在本地的，這也就存在和MySQL同樣的問題，假如機器宕機或硬盤故障，log數據也會丟失，因此index每一個shard也有主備，默認配置是一個primary shard，一個replica shard，固然也能夠配置多個replica。

默認狀況下：primary shard首先接收client端發送過來的數據，而後將數據同步到replica shard中，當replica shard也寫入成功後，纔會告知client數據已正確寫入，這樣就防止數據還沒寫入replica shard時，primary掛掉致使的數據丟失。

又到了提問環節，若是有一個replica節點出了問題，好比網絡故障沒法寫入，那豈不是數據一直寫入不成功了？因此ES的master維護了一個in-sync set，裏面保存了目前存活、且與primary同步的replica集合，只要set中的replica同步完成即認爲數據寫入成功。考慮到一種狀況：全部的replica由於網絡故障都下線了，in-sync set此時爲空，數據只在primary中保留一份，頗有可能因primary故障而致使丟數據，因此ES新增了wait_for_active_shards參數，只有當存活的replica數大於該參數時，才能正常寫入，若不知足，則中止寫服務。

（這是5.X版本的實現，因爲ES版本更新過快，這和2.X以前的版本有些差別，5.X中in-sync set的方式和Kafka的容災模式很是相似，但和Kafka有一點區別：ES的primary負責寫服務，可是primary和replica均可以提供讀服務，而Kafka只有primary partition提供讀寫服務，replica只是同步primary上的數據，並不提供讀。具體爲何Kafka不用replica提供讀服務，你們能夠思考一下哈。而ES 2.X以前版本的容災更像ZK，採用quorum的方式，若是不對請指正）

讀寫方式

存儲方式和讀寫方式很大程度上決定了系統的吞吐，本節主要介紹MySQL、HBase、ES各自是如何讀寫數據的。

Mysql

先說說MySQL，MySQL的Innodb中的數據是按主鍵的順序依次存放，主鍵即爲聚簇索引（對聚簇索引和非聚簇索引不瞭解同窗能夠看看這篇文章），索引採用B+樹結構進行組織。

從圖中能夠看出，數據是按聚簇索引順序依次存放，假設下面一些場景：

1.查詢

Innodb中主鍵即爲聚簇索引，假如根據主鍵查詢，聚簇索引的葉子節點存放就是真正的數據，能夠直接查到相應的記錄。

假如是二級索引查詢，那麼須要先經過二級索引找到該記錄的主鍵，而後根據主鍵經過聚簇索引找到對應的記錄，這裏多了一個索引查找的過程。

2.插入

順序插入：由於Innodb的數據是按聚簇索引的順序依次存放的，若是是根據主鍵索引的順序插入，即插入的數據的主鍵是連續的，由於是順序io，因此插入效率會較高。

隨機插入：假如每次插入的數據主鍵是不連續的，MySQL須要取出每條記錄對應的物理block，會引發大量的隨機io，隨機io操做和順序io的性能差距很大，尤爲是機械盤。

（Kafka官網提到一個機械盤的順序寫能達到600M/s，而隨機寫可能只有100k/s。As a result the performance of linear writes on aJBODconfiguration with six 7200rpm SATA RAID-5 array is about 600MB/sec but the performance of random writes is only about 100k/sec—a difference of over 6000X.這也是爲何HBase、ES將全部的insert、update、delete操做都統一當作順序寫操做，避免隨機io）

note：這也是爲何MySQL的主鍵一般定義爲自增id，不涉及業務邏輯，這樣新數據插入時能保證是順序io。另外MySQL爲了提升隨機io的性能，提供了insert buffer的功能。

3.更新 & 刪除

update和delete若是不是順序的話，也會包含大量的隨機io，固然MySQL都針對隨機io都進行了一些優化，儘可能減小隨機io帶來的性能損失。

HBase

HBase不支持二級索引，它只有一個主鍵索引，採用LSM樹（LSM能夠參考這篇博客）。

HBase是一個分佈式系統，這點跟MySQL不一樣，它的數據是分散不一樣的server上，每一個table由一個或多個region組成，region分散在集羣中的server上，一個server能夠負責多個region。

這裏有一點須要特別注意：table中各個region的存放數據的rowkey（主鍵）範圍是不會重疊的，能夠認爲region上數據基於rowkey全局有序，每一個region負責它本身的那一部分的數據。

1.查詢

假如咱們要查詢rowkey=150的這條記錄，首先從zk中獲取hbase:meta表（存放region和key的對應關係的元數據表）的位置，經過查詢meta表得知rowkey=150的數據在哪一個server的哪一個region上。

2.插入

上圖粗略的展現了HBase的region的結構，region不僅僅是一個文件，它是由一個memstore和多個storeFile組成（storeFile上的上限能夠配置）。插入數據時首先將數據寫入memstore，當memstore大小達到必定閾值，將memstore flush到硬盤，變成一個新的storeFile。flush的時候會對memstore中的數據進行排序，壓縮等操做。能夠看到單個storeFile中的數據是有序的，可是region中的storeFile間的數據不是全局有序的。

這樣有的好處就是：無論主鍵是否連續，全部的插入一概變成順序寫，大大提升了寫入性能。

看到這裏你們可能會有一個疑問：這種寫入方式致使了一條記錄若是不是一次性插入，極可能分散在不一樣的storeFile中，那在該region上面查詢一條記錄時，怎麼知道去找哪一個storeFile呢？答案就是：所有查詢。HBase會採用多路歸併的方式，對該region上的全部storeFile進行查詢，直到找到符合條件的記錄。因此HBase的擁有很好的寫入性能，可是讀性能較差。

固然HBase也作了不少優化，好比每一個storeFile都有本身的index、用於過濾的bloom filter、compaction：按可配置的方式將多個storeFile合併成一個，減小檢索時打開的文件數。

3.更新 & 刪除

HBase將更新和刪除也所有看作插入操做，用timestamp和delete marker來區分該記錄是不是最新記錄、是否須要刪除。也正是由於這樣，除了查詢，其餘的操做統一轉換成了順序寫，保證了HBase高效的寫性能。

ES

ES的也是一個分佈式系統，與ES相似的還有一個叫Solr的項目，都是基於Lucene的全文檢索分佈式框架，有興趣的能夠去Lucene官網瞭解，這裏就不作對比了。

上如展現了ES和傳統數據庫的概念對比。下面的介紹中，統一使用index對應DB中table，doc對應table中的記錄，field對應row中的一列。

ES集羣由一個或多個node組成，一個node即爲一個ES服務進程。一個index由多個分片shard組成，shard分散在各個node上面，每一個shard都採用Lucene來建立倒排索引，維護各自的索引數據。

圖中的一個小方框即爲一個shard，出於容災考慮，每一個shard都會有多副本，副本個數能夠配置，默認爲2，綠色的即爲primary shard，灰色的即爲replica shard。

1.插入

先來講說寫入吧，因爲有多個shard，請求過來時，如何判斷寫入到哪一個shard呢，ES中每一個doc都會有一個惟一id，默認會對id取hash值，根據shard的個數mode到對應的shard上，默認狀況下shard中的數據id不是全局有序的，這點和Mysql、HBase有很大區別。

ES的寫入和HBase有些相似，也是將全部的寫操做變成順序寫，也是先將數據寫入內存，而後一段時間後會將內存數據flush到磁盤，磁盤的索引文件會定時進行merge，保證索引文件不會過多而影響檢索性能。

另外提一點,數據存入ES後並非立馬就能檢索到，這點跟MySQL和HBase，或者說跟數據庫系統是徹底不同的。主要是由於因爲Inverted Index結構的複雜，須要一個專門的indexReader來查詢數據，可是indexReader是以snapshot的方式打開的索引，也就是說indexReader看不到以後的新數據。因此ES提供了一個refresh功能，refresh會從新打開indexReader，使其可以讀到最新的數據。默認refresh的間隔是1s，因此ES自稱是近實時檢索功能。

說到順序寫,這時候你們可能會想：那ES的寫入速度和HBase差很少嘍？那，其實不是的，不止不如並且差的還不是一點點，由於ES多了兩個最關鍵的步驟：build index和refresh index！這兩個過程是很耗時的: build index時須要分詞、計算權重等複雜的操做（對inverted index建立，檢索感興趣的，能夠參考《信息檢索導論》）。而refresh會從新打開index,這兩個過程加起來致使ES接收文檔的速率並不高（能夠經過bulk方式來加快數據導入）。但也正是由於這些過程才使ES有強大的檢索功能。（雖然我insert慢，可是我花樣多呀^ ^）

2.讀取

每一個node均可以接收讀request，而後該node會把request分發到含有該index的shard的節點上，對應的節點會查詢、並計算出符合條件的文檔，排序後結果匯聚到分發request的node（因此查詢請求默認會輪循的將發送到各個節點上，防止請求所有打到一個節點），由該node將數據返回給client。（ES也支持指定shard查詢，默認是根據文檔id進行路由，至關於主鍵查詢，可是假如不能肯定數據在哪一個shard上時，仍是須要查詢全部shard）

這裏要強調一下，因爲ES支持全文檢索，根據Inverted Index的特性，大部分狀況下，一個關鍵字對應了不少的doc，若是所有返回，數據量較大，會對集羣形成較大壓力，因此ES默認只返回權重最高的前20條記錄（可配置），也能夠經過scroll功能獲取所有數據。相似的場景跟咱們平時使用baidu、google是同樣的，咱們使用搜索引擎時，每每是但願獲得關聯性最強的top N文檔，並不關心所有文檔有多少個，這也是爲何要計算權重的緣由。

如今的ES的功能愈來愈豐富，不只僅包含全文檢索的功能，並且還有統計分析等功能，說它是全文檢索框架吧，它比全文檢索功能要豐富，說它是數據庫吧，可是它不支持事務，只能說如今各個框架之間的界限愈來愈模糊了。

3.更新 &刪除

ES的更新和刪除和HBase相似，也是所有看作是插入操做，經過timestamp和delete marker來區分。

又到了問題環節 :D ：既然這種將更新刪除統一變成順序寫的方式可以提升寫性能，那它難道沒有什麼壞處嗎？

答案是確定有的呀，這種方式可以有效的提高寫性能，可是存在一個很大的問題就是後臺常常會須要merge，而merge是一個很是耗資源的過程，對於某些穩定性要求較高的業務來講，這是不能接受的，可是不merge的話，又會下降查詢性能（過多的小文件影響查詢性能）。目前通用的作法是儘可能選擇業務低峯期進行merge操做。

使用場景

說了這麼多，其實仍是但願對MySQL，HBase，ES各自的實現作下對比，方便咱們根據業務特色選擇最合適的存儲、檢索方案。下面說一下筆者在工做中使用的經驗：

MySQL在三款中最爲成熟，並且支持事務，支持二級索引，容災備份方案也最爲成熟，因此線上核心業務Mysql是不二之選（固然若是不差錢，Oracle也挺不錯，並且出問題本身解決不了的話，打電話就能夠了，手動斜眼）。

HBase由於其強大的寫入能力和水平擴展能力，比較適合存儲日誌，用戶行爲等數據量比較大的數據，這種數據通常不涉及事務級別的讀寫，對二級索引的需求也不是很高。並且HBase的主鍵不像Mysql，每每是涉及到業務邏輯的，若是查詢條件單一的話，能夠把直接把須要查詢的字段做爲主鍵的一部分，相似MySQL的聯合索引，來提供檢索功能。

ES如今不只提供全文檢索，還提供統計功能，而且提供的Restful接口很是好用，配上Kibana還能夠進行圖形化展現，第三方插件也很豐富。雖然ES能夠水平擴展，可是考慮到ES的大部分檢索都會檢索該index的全部shard，若是單個index數據過大，性能多少也會受到影響，因此單個index的大小最好控制在必定的範圍，好比存儲用戶行爲日誌的index，能夠每隔一段時間歸一次檔，建立新的index，作到冷熱分離。並且ES也能夠做爲MySQL或HBase的索引來使用，雖然Mysql也有索引功能，可是過多的索引每每會拖累MySQL的性能，而且線上MySQL數據庫通常也不容許執行統計類的sql，這時能夠用ES輔助實現統計，HBase由於只有主鍵檢索，因此更須要二級索引的功能。

舉一個筆者前司組合使用的場景：trace系統的log數據以HBase做爲主要存儲，同時最近三個月的數據也在ES裏面保留一份，ES主要用來完成各類複雜檢索、統計。但數據同步須要業務本身實現，固然trace業務對一致性要求不那麼高，也能夠忽略這個問題。

tip：將數據庫的數據向ES中同步的時候，由於網絡延遲等問題，到達的順序可能會亂序，這時老數據有可能會覆蓋新的數據，ES提供了一個version功能，能夠將數據的timestamp做爲version值，防止舊version的數據覆蓋新version的數據。

展望

傳統的關係型數據庫有着強大的事物處理能力，知足了大部分線上業務需求，可是水平擴展性一直是一個頭疼的問題，NoSql數據庫雖然解決了水平擴展問題，可是功能太單一，如今愈來愈多的公司開始着手研究新一代NewSQL數據庫，結合了關係型數據庫的優勢外還擁有水平擴展能力，好比淘寶的Oceanbase，PingCAP的TiDB，國外的CockroachDB，讓咱們作好擁抱NewSQL的準備吧。

轉載自：https://www.jianshu.com/p/4e412f48e820

-------

The most popular ones

Redis (V3.2)

Written in: C
Main point: Blazing fast
License: BSD
Protocol: Telnet-like, binary safe
Disk-backed in-memory database,
Master-slave replication, automatic failover
Simple values or data structures by keys
but complex operations like ZREVRANGEBYSCORE.
INCR & co (good for rate limiting or statistics)
Bit and bitfield operations (for example to implement bloom filters)
Has sets (also union/diff/inter)
Has lists (also a queue; blocking pop)
Has hashes (objects of multiple fields)
Sorted sets (high score table, good for range queries)
Lua scripting capabilities
Has transactions
Values can be set to expire (as in a cache)
Pub/Sub lets you implement messaging
GEO API to query by radius (!)

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

For example: To store real-time stock prices. Real-time analytics. Leaderboards. Real-time communication. And wherever you used memcached before.

Cassandra (2.0)

Written in: Java
Main point: Store huge datasets in "almost" SQL
License: Apache
Protocol: CQL3 & Thrift
CQL3 is very similar SQL, but with some limitations that come from the scalability (most notably: no JOINs, no aggregate functions.)
CQL3 is now the official interface. Don't look at Thrift, unless you're working on a legacy app. This way, you can live without understanding ColumnFamilies, SuperColumns, etc.
Querying by key, or key range (secondary indices are also available)
Tunable trade-offs for distribution and replication (N, R, W)
Data can have expiration (set on INSERT).
Writes can be much faster than reads (when reads are disk-bound)
Map/reduce possible with Apache Hadoop
All nodes are similar, as opposed to Hadoop/HBase
Very good and reliable cross-datacenter replication
Distributed counter datatype.
You can write triggers in Java.

Best used: When you need to store data so huge that it doesn't fit on server, but still want a friendly familiar interface to it.

For example: Web analytics, to count hits by hour, by browser, by IP, etc. Transaction logging. Data collection from huge sensor arrays.

MongoDB (3.2)

Written in: C++
Main point: JSON document store
License: AGPL (Drivers: Apache)
Protocol: Custom, binary (BSON)
Master/slave replication (auto failover with replica sets)
Sharding built-in
Queries are javascript expressions
Run arbitrary javascript functions server-side
Geospatial queries
Multiple storage engines with different performance characteristics
Performance over features
Document validation
Journaling
Powerful aggregation framework
On 32bit systems, limited to ~2.5Gb
Text search integrated
GridFS to store big data + metadata (not actually an FS)
Has geospatial indexing
Data center aware

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 most things that you would do with MySQL or PostgreSQL, but having predefined columns really holds you back.

ElasticSearch (0.20.1)

Written in: Java
Main point: Advanced Search
License: Apache
Protocol: JSON over HTTP (Plugins: Thrift, memcached)
Stores JSON documents
Has versioning
Parent and children documents
Documents can time out
Very versatile and sophisticated querying, scriptable
Write consistency: one, quorum or all
Sorting by score (!)
Geo distance sorting
Fuzzy searches (approximate date, etc) (!)
Asynchronous replication
Atomic, scripted updates (good for counters, etc)
Can maintain automatic "stats groups" (good for debugging)

Best used: When you have objects with (flexible) fields, and you need "advanced search" functionality.

For example: A dating service that handles age difference, geographic location, tastes and dislikes, etc. Or a leaderboard system that depends on many variables.

Classic document and BigTable stores

CouchDB (V1.2)

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)

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.

Accumulo (1.4)

Written in: Java and C++
Main point: A BigTable with Cell-level security
License: Apache
Protocol: Thrift
Another BigTable clone, also runs of top of Hadoop
Originally from the NSA
Cell-level security
Bigger rows than memory are allowed
Keeps a memory map outside Java, in C++ STL
Map/reduce using Hadoop's facitlities (ZooKeeper & co)
Some server-side programming

Best used: If you need to restict access on the cell level.

For example: Same as HBase, since it's basically a replacement: Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.

HBase (V0.92.0)

Written in: Java
Main point: Billions of rows X millions of columns
License: Apache
Protocol: HTTP/REST (also Thrift)
Modeled after Google's BigTable
Uses Hadoop's HDFS as storage
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
Jruby-based (JIRB) shell
Rolling restart for configuration changes and minor upgrades
Random access performance is like MySQL
A cluster consists of several different types of nodes

Best used: Hadoop is probably still the best way to run Map/Reduce jobs on huge datasets. Best if you use the Hadoop/HDFS stack already.

For example: Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.

Hypertable (0.9.6.5)

Written in: C++
Main point: A faster, smaller HBase
License: GPL 2.0
Protocol: Thrift, C++ library, or HQL shell
Implements Google's BigTable design
Run on Hadoop's HDFS
Uses its own, "SQL-like" language, HQL
Can search by key, by cell, or for values in column families.
Search can be limited to key/column ranges.
Sponsored by Baidu
Retains the last N historical values
Tables are in namespaces
Map/reduce with Hadoop

Best used: If you need a better HBase.

For example: Same as HBase, since it's basically a replacement: Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.

Graph databases

OrientDB (2.0)

Written in: Java
Main point: Document-based graph database
License: Apache 2.0
Protocol: binary, HTTP REST/JSON, or Java API for embedding
Has transactions, full ACID conformity
Can be used both as a document and as a graph database (vertices with properties)
Both nodes and relationships can have metadata
Multi-master architecture
Supports relationships between documents via persistent pointers (LINK, LINKSET, LINKMAP, LINKLIST field types)
SQL-like query language (Note: no JOIN, but there are pointers)
Web-based GUI (quite good-looking, self-contained)
Inheritance between classes. Indexing of nodes and relationships
User functions in SQL or JavaScript
Sharding
Advanced path-finding with multiple algorithms and Gremlin traversal language
Advanced monitoring, online backups are commercially licensed

Best used: For graph-style, rich or complex, interconnected data.

For example: For searching routes in social relations, public transport links, road maps, or network topologies.

Neo4j (V1.5M02)

Written in: Java
Main point: Graph database - connected data
License: GPL, some features AGPL/commercial
Protocol: HTTP/REST (or embedding in Java)
Standalone, or embeddable into Java applications
Full ACID conformity (including durable data)
Both nodes and relationships can have metadata
Integrated pattern-matching-based query language ("Cypher")
Also the "Gremlin" graph traversal language can be used
Indexing of nodes and relationships
Nice self-contained web admin
Advanced path-finding with multiple algorithms
Indexing of keys and relationships
Optimized for reads
Has transactions (in the Java API)
Scriptable in Groovy
Clustering, replication, caching, online backup, advanced monitoring and High Availability are commercially licensed

Best used: For graph-style, rich or complex, interconnected data.

For example: For searching routes in social relations, public transport links, road maps, or network topologies.

The "long tail"

Couchbase (ex-Membase) (2.0)

Written in: Erlang & C
Main point: Memcache compatible, but with persistence and clustering
License: Apache
Protocol: memcached + extensions
Very fast (200k+/sec) access of data by key
Persistence to disk
All nodes are identical (master-master replication)
Provides memcached-style in-memory caching buckets, too
Write de-duplication to reduce IO
Friendly cluster-management web GUI
Connection proxy for connection pooling and multiplexing (Moxi)
Incremental map/reduce
Cross-datacenter replication

Best used: Any application where low-latency data access, high concurrency support and high availability is a requirement.

For example: Low-latency use-cases like ad targeting or highly-concurrent web apps like online gaming (e.g. Zynga).

Scalaris (0.5)

Written in: Erlang
Main point: Distributed P2P key-value store
License: Apache
Protocol: Proprietary & JSON-RPC
In-memory (disk when using Tokyo Cabinet as a backend)
Uses YAWS as a web server
Has transactions (an adapted Paxos commit)
Consistent, distributed write operations
From CAP, values Consistency over Availability (in case of network partitioning, only the bigger partition works)

Best used: If you like Erlang and wanted to use Mnesia or DETS or ETS, but you need something that is accessible from more languages (and scales much better than ETS or DETS).

For example: In an Erlang-based system when you want to give access to the DB to Python, Ruby or Java programmers.

Aerospike (3.4.1)

Written in: C
Main point: Speed, SSD-optimized storage
License: License: AGPL (Client: Apache)
Protocol: Proprietary
Cross-datacenter replication is commercially licensed
Very fast access of data by key
Uses SSD devices as a block device to store data (RAM + persistence also available)
Automatic failover and automatic rebalancing of data when nodes or added or removed from cluster
User Defined Functions in LUA
Cluster management with Web GUI
Has complex data types (lists and maps) as well as simple (integer, string, blob)
Secondary indices
Aggregation query model
Data can be set to expire with a time-to-live (TTL)
Large Data Types