主流的Nosql數據庫的對比
MongoDB，Cassandra，CouchDB，Hypertable， Redis，Riak，Neo4j，Hadoop HBase，
Couchbase，MemcacheDB
- Hadoop HBase
Hbase的優點及應用場景：
1. 半結構化或非結構化數據:
對於數據結構字段不夠確定或雜亂無章非常難按一個概念去進行抽取的數據適合用HBase，因為HBase支持動態添加列。
- 記錄很稀疏：
RDBMS的行有多少列是固定的。為null的列浪費了存儲空間。HBase為null的Column不會被存儲，這樣既節省了空間又提高了讀性能。
3. 多版本號數據：
依據Row key和Column key定位到的Value能夠有隨意數量的版本號值，因此對於須要存儲變動歷史記錄的數據，用HBase是很方便的。比方某個用戶的Address變更，用戶的Address變更記錄也許也是具有研究意義的。
4. 僅要求最終一致性：
對於數據存儲事務的要求不像金融行業和財務系統這么高，只要保證最終一致性就行。（比如HBase+elasticsearch時，可能出現數據不一致）
5. 高可用和海量數據以及很大的瞬間寫入量：
WAL解決高可用，支持PB級數據，put性能高
適用於插入比查詢操作更頻繁的情況。比如，對於歷史記錄表和日志文件。（HBase的寫操作更加高效）
業務場景簡單：
不需要太多的關系型數據庫特性，列入交叉列，交叉表，事務，連接等。
Hbase的缺點：
- 單一RowKey固有的局限性決定了它不可能有效地支持多條件查詢
- 不適合於大范圍掃描查詢
- 不直接支持 SQL 的語句查詢
- java語言實現及Hadoop架構意味着其API更適用於Java項目
- 占用內存很大，且鑒於建立在為批量分析而優化的HDFS上，導致讀取性能不高；API相比其它 NoSql 的相對笨拙。
但是Hadoop/HBase集群的維護常常需要很多專業人員並且需要構建一個比較大的集群才能最大化體現出威力，因此用戶主要是Facebook, yahoo, 百度和阿里巴巴等大公司。所以我們用它來開發系統是一件
最佳應用場景：適用於偏好BigTable:)並且需要對大數據進行隨機、實時訪問的場合。
例如： Facebook消息數據庫（更多通用的用例即將出現）
- MongoDB 數據庫
MongoDB是一個新的和普遍使用的數據庫。 它是一個基於文檔的非關系數據庫提供程序。
MongoDB是個面向文檔的數據庫，使用JSON風格的數據格式。它非常適合於網站的數據存儲、內容管理與緩存應用，並且通過配置可以實現復制與高可用性功能。
MongoDB具有很強的可伸縮性，性能表現優異。它使用C++編寫，基於文檔存儲。此外，
MongoDB還支持全文檢索、跨WAN與LAN的高可用性、易於實現的復制、水平擴展、基於文檔的豐富查詢、在數據處理與聚合等方面具有很強的靈活性。
MongoDB社區非常活躍，很多開發框架都迅速提供了對MongDB的支持。
優點：
- MongoDB 的架構較少。它是一個文檔數據庫，它的一個集合持有不同的文檔。
- 從一個到另一個的文檔的數量，內容和大小可能有差異。支持多種文檔！
- MongoDB 中單個對象的結構很清淅。
- MongoDB 中沒有復雜的連接。
- MongoDB 提供深度查詢的功能，因為它支持對文檔的強大的動態查詢。
- MongoDB 很容易擴展。
- 它使用內部存儲器來存儲工作集，這是其快速訪問的原因。
- MongoDB更加靈活，因為可以在文檔中直接插入數組之類的復雜數據類型，並且文檔的key和value不是固定的數據類型和大小，所以開發者在使用MongoDB時無須預定義關系型數據庫中的”表”等數據庫對象，設計數據庫將變得非常方便，可以大大地提升開發進度。
- 適用於需要動態查詢支持；需要使用索引而不是 map/reduce功能；需要對大數據庫有性能要求；需要使用 CouchDB但因為數據改變太頻繁而占滿內存的應用程序。
缺點：
mongodb不支持事務操作。
1. 所以事務要求嚴格的系統（如果銀行系統）肯定不能用它
2.③MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方。
3. mongo 命令行 shell 使用 linenoise 而不是 readline，中文支持問題嚴重
3. Redis
這是個開源、高級的鍵值存儲。由於在鍵中使用了hash、set、string、sorted set及list，因此Redis也稱作數據結構服務器。這個系統可以幫助你執行原子操作，比如說增加hash中的值、集合的交集運算、字符串拼接、差集與並集等。Redis通過內存中的數據集實現了高性能。此外，該數據庫還兼容於大多數編程語言。
redis是一個key-value存儲系統，數據存儲在內存中，它的優點主要如下：
1. 支持多種數據類型
包括set,zset,list,hash,string這五種數據類型，操作非常方便。比如，如果你在做好友系統，查看自己的好友關系，如果采用其他的key-value系統，則必須把對應的好友拼接成字符串，然后在提取好友時，再把value進行解析，而redis則相對簡單，直接支持list的存儲(采用雙向鏈表或者壓縮鏈表的存儲方式)。
2. 持久化存儲
作為一個內存數據庫，最擔心的，就是萬一機器死機，數據會消失掉。redi使用rdb和aof做數據的持久化存儲。主從數據同時，生成rdb文件，並利用緩沖區添加新的數據更新操作做對應的同步。
3. 豐富的特性
pub/sub，key過期策略，事務，支持多個DB等
4. 性能很好
由於是全內存操作，所以讀寫性能很好，可以達到10w/s的頻率。公司有項目使用redis，目前的訪問頻率是80w/s，通過適當的部署，線上運行一切ok。
redis的缺點主要如下：
1. 由於是內存數據庫，所以，單台機器，存儲的數據量，跟機器本身的內存大小有關。雖然redis本身有key過期策略，但是還是需要提前預估和節約內存。如果內存增長過快，需要定期刪除數據。
2. 如果進行完整重同步，由於需要生成rdb文件，並進行傳輸，會占用主機的CPU，並會消耗現網的帶寬。不過redis2.8版本，已經有部分重同步的功能，但是還是有可能有完整重同步的。比如，新上線的備機。
- 修改配置文件，進行重啟，將硬盤中的數據加載進內存，時間比較久。在這個過程中，redis不能提供服務。
總結來說，主要優點有
（1）非常豐富的數據結構，且這些數據結構的常見操作均是原子性的；
（2） 高速讀寫。Memcached提供了CAS命令，可以保證多個並發訪問操作同一份數據的一致性問題。 Redis沒有提供CAS命令，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。MYSQL使用了鎖，而memcache未使用鎖，進而效率極高。總之，Redis用自己實現的事件分離器，代碼量很短，沒有CAS，沒有lock，因而效率非常高。
缺點：
1 Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復。
2 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP后還會引入數據不一致的問題，降低了系統的可用性。
3 Redis的主從復制采用全量復制，復制過程中主機會fork出一個子進程對內存做一份快照，並將子進程的內存快照保存為文件發送給從機，這一過程需要確保主機有足夠多的空余內存。若快照文件較大，對集群的服務能力會產生較大的影響，而且復制過程是在從機新加入集群或者從機和主機網絡斷開重連時都會進行，也就是網絡波動都會造成主機和從機間的一次全量的數據復制，這對實際的系統運營造成了不小的麻煩。
4 Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。
總結來說：主要缺點有
（1）持久化。 Redis直接將數據存儲到內存中，可通過兩種方式持久化：定時快照（snapshot）和基於語句的追加（AppendOnlyFile，aof）。Snapshot的方法是指每隔一段時間將整個數據庫的數據寫到磁盤上，很明顯，每次均是寫全部數據，代價非常高；而aof方法只追蹤變化的數據，這類似於mysql的binlog方法，但追加log可能過大，同時所有操作均要重新執行一遍，恢復速度慢。
（2）耗內存。盡管Redis對一些數據結構采用了壓縮算法存儲，但占用內存量還是過高。
適用場景：適用於數據變化快且數據庫大小可遇見（適合內存容量）的應用程序。
- 4. Cassandra
這是個Apache軟件基金會的項目，Cassandra是個分布式數據庫，支持分散的數據存儲，可以實現容錯以及無單點故障等。換句話說，“Cassandra非常適合於那些無法忍受數據丟失的應用”。
優點：
Cassandra的主要特點就是它不是一個數據庫，而是由一堆數據庫節點共同構成的一個分布式網絡服務，對Cassandra 的一個寫操作，會被復制到其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。
模式靈活
使用Cassandra，像文檔存儲，你不必提前解決記錄中的字段。你可以在系統運行時隨意的添加或移除字段。這是一個驚人的效率提升，特別是在大型部署上。
真正的可擴展性
Cassandra是純粹意義上的水平擴展。為給集群添加更多容量，可以指向另一台電腦。你不必重啟任何進程，改變應用查詢，或手動遷移任何數據。
多數據中心識別
你可以調整你的節點布局來避免某一個數據中心起火，一個備用的數據中心將至少有每條記錄的完全復制。
缺點：
Cassandra的設計初衷就不是存儲大文件
Twitter為什么要停用Cassandra
1. Cassandra仍然缺少大並發海量數據訪問的案例及經驗，Cassandra來源自Facebook，但是在Facebook內部Cassandra目前只用在inbox search產品上，容量大約有100-200T。且Inbox Search在Facebook的基礎架構中也並非核心應用。並且還傳出不少rumors說facebook已經放棄Cassandra。
2. 新產品需要一定穩定期，Cassandra代碼或許還存在不少問題，但是Twitter如果投入大量的精力來改進Cassandra和比較優化MySQL的投入來看有點得不償失。在QCon Beijing上@nk也提到Cassandra在Twitter的內部測試中曾經暴露出不少嚴重的問題。
缺點的討論：
1、它未采用hdfs文件系統，所以存在與Hadoop難以協同的問題。數據源在cassandra存儲體系中，不利於mapreduce分析。
2、該開源體系尚不成熟，代碼穩定性存在不確定性，先后被一些大型互聯網公司采用又棄用。
3、其快速查詢的功能有hbase這樣的列存式數據庫這樣的替代品。
最佳應用場景：當使用寫操作多過讀操作（記錄日志）如果每個系統組建都必須用 Java編寫（沒有人因為選用 Apache的軟件被解雇）
例如：銀行業，金融業（雖然對於金融交易不是必須的，但這些產業對數據庫的要求會比它們更大）寫比讀更快，所以一個自然的特性就是實時數據分析
5. Hypertable
Hypertable模仿的是Google的BigTable數據庫系統。Hypertable的創建者將“成為高可用、PB規模的數據庫開源標准”作為Hypertable的目標。換言之，Hypertable的設計目標是跨越多個廉價的服務器可靠地存儲大量數據。
Hypertable是一個開源、高性能、可伸縮的數據庫，它采用與Google的Bigtable相似的模型。在過去數年中，Google為在 PC集群 上運行的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統，提供了一個全局的命名空間。它通過跨機器（和跨機架）的文件數據復制來達到高可用性，並因此免受傳統 文件存儲系統無法避免的許多失敗的影響，比如電源、內存和網絡端口等失敗。第二個基礎設施是名為Map-Reduce的計算框架，它與GFS緊密協作，幫 助處理收集到的海量數據。第三個基礎設施是Bigtable，它是傳統數據庫的替代。Bigtable讓你可以通過一些主鍵來組織海量數據，並實現高效的 查詢。Hypertable是Bigtable的一個開源實現，並且根據我們的想法進行了一些改進。
主要功能特點：
負載均衡的處理，版本控制和一致性，可靠性，分布為多個節點。
6. Riak
Riak是最為強大的分布式數據庫之一，它提供了輕松且可預測的伸縮能力，向用戶提供了快速測試、原型與應用部署能力，從而簡化應用的開發過程。
最佳應用場景：適用於想使用類似 Cassandra（類似Dynamo）數據庫但無法處理 bloat及復雜性的情況。適用於你打算做多站點復制，但又需要對單個站點的擴展性，可用性及出錯處理有要求的情況。
例如：銷售數據搜集，工廠控制系統；對宕機時間有嚴格要求；可以作為易於更新的 web服務器使用。
7. Neo4j
Neo4j是一款NoSQL圖型數據庫，具有非常高的性能。它擁有一個健壯且成熟的系統的所有特性，向程序員提供了靈活且面向對象的網絡結構，可以讓開發者充分享受到擁有完整事務特性的數據庫的所有好處。相較於RDBMS，Neo4j還對某些應用提供了不少性能改進。
優點：
- 數據的插入，查詢操作很直觀，不用再像之前要考慮各個表之間的關系。
- 提供的圖搜索和圖遍歷方法很方便，速度也是比較快的。
缺點：
- 最不能讓人忍受的就是極慢的插入速度。可能是因為創建節點和邊的時候需要保存一些額外信息（為了查詢服務）。不知道是不是我代碼的問題，插入10000個節點，10000條邊花了將近10分鍾...
- 超大節點。當有一個節點的邊非常多時（常見於大V），有關這個節點的操作的速度將大大下降。這個問題很早就有了，官方也說過會處理，然而現在仍然不能讓人滿意。
- 提高數據庫速度的常用方法就是多分配內存，然而看了官方操作手冊，貌似無法直接設置數據庫內存占用量，而是需要計算后為其”預留“內存...
最佳應用場景：適用於圖形一類數據。這是 Neo4j與其他nosql數據庫的最顯著區別
例如：社會關系，公共交通網絡，地圖及網絡拓譜
鑒於其明顯的優缺點，Neo4j適合存儲”修改較少，查詢較多，沒有超大節點“的圖數據。
另外，針對Neo4j的缺點，有一款使用混合索引的數據庫Arangodb也許是一個不錯的考慮對象。根據其官網的說明，Arangodb不僅具有一般圖形數據庫的優點，而且在各種操作的速度上領先於Neo4j
8. Couchbase
雖然Couchbase是CouchDB的派生，不過它已經成為了一款功能完善的數據庫產品。它向文檔數據庫轉移的趨勢會讓MongoDB感到壓力。每個節點上它都是多線程的，這是個非常主要的可伸縮性優勢，特別是當托管在自定義或是Bare-Metal硬件上時更是如此。借助於一些非常棒的集成特性，諸如與Hadoop的集成，Couchbase對於數據存儲來說是個非常不錯的選擇。
Redis相比Couchbase來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Couchbase里，你需要將數據拿到客戶端來進行類似的修改再set回去（你需要先先通過get方法從服務器讀取數據文檔，並將文檔反序列化為json對象，之后修改json對象對應屬性，再通過set方法將數據寫入服務器，序列化后進行存儲）。這大大增加了網絡IO的次數和傳輸中的數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。
適用場景：最佳應用場景：適用於數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用於需要提供數據版本支持的應用程序。
9.. MemcacheDB
這是個分布式的鍵值存儲系統，我們不應該將其與緩存解決方案搞混；相反，它是個持久化存儲引擎，用於數據存儲並以非常快速且可靠的方式檢索數據。它遵循memcache協議。其存儲后端用於Berkeley DB中，支持諸如復制與事務等特性。
優點
一.部分容災
假設只用一台memcache，如果這台memcache服務器掛掉了，那么請求將不斷的沖擊數據庫，這樣有可能搞死數據庫，從而引發”雪崩“。如果使用多台memcache服務器，由於memcache使用一致性哈希算法，萬一其中一台掛掉了，部分請求還是可以在memcache中命中，為修復系統贏得一些時間。
二.容量問題
一台memcache服務器的容量畢竟有限，可以使用多台memcache服務器，增加緩存容量。
三.均衡請求
使用多台memcache服務器，可以均衡請求，避免所有請求都沖進一台memcache服務器，導致服務器掛掉。
四.利用memcache分布式特性
使用一台memcache服務器，並沒有利用memcache的數據分布式特性。
缺點
1.不能持久化存儲
2.存儲數據有限制：1M 【大於1M，認為就行分割】（內存碎片）
3.mm存儲數據只能key-value
4.集群數據沒有復制和同步機制 【崩潰不會影響程序，會從數據庫中取數據】
5.內存回收不能及時 LRU(算法)：未使用內存》過期內存》最近最少使用內存 這是惰性刪除