主流的Nosql數據庫的對比

主流的Nosql數據庫的對比

 

 MongoDB，Cassandra，CouchDB，Hypertable， Redis，Riak，Neo4j，Hadoop HBase，

Couchbase，MemcacheDB

 

1. Hadoop HBase

 

Hbase的優勢及應用場景：

 

1. 半結構化或非結構化數據: 

對於數據結構字段不夠肯定或雜亂無章很是難按一個概念去進行抽取的數據適合用HBase，由於HBase支持動態添加列。

1. 記錄很稀疏： 

RDBMS的行有多少列是固定的。爲null的列浪費了存儲空間。HBase爲null的Column不會被存儲，這樣既節省了空間又提升了讀性能。

3. 多版本號數據： 

依據Row key和Column key定位到的Value可以有隨意數量的版本號值，所以對於需要存儲變更歷史記錄的數據，用HBase是很方便的。比方某個用戶的Address變動，用戶的Address變動記錄也許也是具備研究意義的。

4. 僅要求最終一致性： 

對於數據存儲事務的要求不像金融行業和財務系統這麼高，只要保證最終一致性就行。（好比HBase+elasticsearch時，可能出現數據不一致）

5. 高可用和海量數據以及很大的瞬間寫入量： 

WAL解決高可用，支持PB級數據，put性能高

適用於插入比查詢操做更頻繁的狀況。好比，對於歷史記錄表和日誌文件。（HBase的寫操做更加高效）

業務場景簡單： 

不須要太多的關係型數據庫特性，列入交叉列，交叉表，事務，鏈接等。

 

Hbase的缺點：

1. 單一RowKey固有的侷限性決定了它不可能有效地支持多條件查詢
2. 不適合於大範圍掃描查詢
3. 不直接支持 SQL 的語句查詢
4. java語言實現及Hadoop架構意味着其API更適用於Java項目
5. 佔用內存很大，且鑑於創建在爲批量分析而優化的HDFS上，致使讀取性能不高；API相比其它 NoSql 的相對笨拙。

 

可是Hadoop/HBase集羣的維護經常須要不少專業人員而且須要構建一個比較大的集羣才能最大化體現出威力，所以用戶主要是Facebook, yahoo, 百度和阿里巴巴等大公司。因此咱們用它來開發系統是一件

 

 

最佳應用場景：適用於偏好BigTable:)而且須要對大數據進行隨機、實時訪問的場合。

例如： Facebook消息數據庫（更多通用的用例即將出現）

 

1. MongoDB 數據庫

 

MongoDB是一個新的和廣泛使用的數據庫。 它是一個基於文檔的非關係數據庫提供程序。

MongoDB是個面向文檔的數據庫，使用JSON風格的數據格式。它很是適合於網站的數據存儲、內容管理與緩存應用，而且經過配置能夠實現複製與高可用性功能。

MongoDB具備很強的可伸縮性，性能表現優異。它使用C++編寫，基於文檔存儲。此外，

MongoDB還支持全文檢索、跨WAN與LAN的高可用性、易於實現的複製、水平擴展、基於文檔的豐富查詢、在數據處理與聚合等方面具備很強的靈活性。

MongoDB社區很是活躍，不少開發框架都迅速提供了對MongDB的支持。

 

優勢：

1. MongoDB 的架構較少。它是一個文檔數據庫，它的一個集合持有不一樣的文檔。
2. 從一個到另外一個的文檔的數量，內容和大小可能有差別。支持多種文檔！
3. MongoDB 中單個對象的結構很清淅。
4. MongoDB 中沒有複雜的鏈接。
5. MongoDB 提供深度查詢的功能，由於它支持對文檔的強大的動態查詢。
6. MongoDB 很容易擴展。
7. 它使用內部存儲器來存儲工做集，這是其快速訪問的緣由。
8. MongoDB更加靈活，由於能夠在文檔中直接插入數組之類的複雜數據類型，而且文檔的key和value不是固定的數據類型和大小，因此開發者在使用MongoDB時無須預約義關係型數據庫中的」表」等數據庫對象，設計數據庫將變得很是方便，能夠大大地提高開發進度。
9. 適用於須要動態查詢支持；須要使用索引而不是 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版本，已經有部分重同步的功能，可是仍是有可能有完整重同步的。好比，新上線的備機。

1. 修改配置文件，進行重啓，將硬盤中的數據加載進內存，時間比較久。在這個過程當中，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對一些數據結構採用了壓縮算法存儲，但佔用內存量仍是太高。

 

適用場景：適用於數據變化快且數據庫大小可碰見（適合內存容量）的應用程序。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. 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的內部測試中曾經暴露出很多嚴重的問題。

缺點的討論：

一、它未採用hdfs文件系統，因此存在與Hadoop難以協同的問題。數據源在cassandra存儲體系中，不利於mapreduce分析。

二、該開源體系尚不成熟，代碼穩定性存在不肯定性，前後被一些大型互聯網公司採用又棄用。

三、其快速查詢的功能有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還對某些應用提供了很多性能改進。

優勢：

1. 數據的插入，查詢操做很直觀，不用再像以前要考慮各個表之間的關係。
2. 提供的圖搜索和圖遍歷方法很方便，速度也是比較快的。

缺點：

1. 最不能讓人忍受的就是極慢的插入速度。多是由於建立節點和邊的時候須要保存一些額外信息（爲了查詢服務）。不知道是否是我代碼的問題，插入10000個節點，10000條邊花了將近10分鐘...
2. 超大節點。當有一個節點的邊很是多時（常見於大V），有關這個節點的操做的速度將大大降低。這個問題很早就有了，官方也說過會處理，然而如今仍然不能讓人滿意。
3. 提升數據庫速度的經常使用方法就是多分配內存，然而看了官方操做手冊，貌似沒法直接設置數據庫內存佔用量，而是須要計算後爲其」預留「內存...

 

最佳應用場景：適用於圖形一類數據。這是 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(算法)：未使用內存》過時內存》最近最少使用內存   這是惰性刪除