NoSQL數據庫發展迅猛，據說現在已經有上百種NoSQL數據庫了，下面來了解下常見的一些NoSQL數據庫

先來看張表，了解下典型的NoSQL數據庫的分類

NoSQL一般特征：

臨時性鍵值存儲

一般作為關系型數據庫的緩存來使用

由于存在數據丟失的可能，所以一般用來處理不需要持久保存的數據

具有非常快的處理速度

用于需要使用expires時(需要定期清除數據)

使用一致性散列(Consistent Hashing)算法來分散數據

1、CouchDB

• 所用語言： Erlang
• 特點：DB一致性，易于使用
• 使用許可： Apache
• 協議： HTTP/REST
• 雙向數據復制，
• 持續進行或臨時處理，
• 處理時帶沖突檢查，
• 采用的是master-master復制（見編注2）
• MVCC – 寫操作不阻塞讀操作
• 可保存文件之前的版本
• Crash-only（可靠的）設計
• 需要不時地進行數據壓縮
• 視圖：嵌入式 映射/減少
• 格式化視圖：列表顯示
• 支持進行服務器端文檔驗證
• 支持認證
• 根據變化實時更新
• 支持附件處理
• CouchApps（獨立的 js應用程序）
• 需要 jQuery程序庫

最佳應用場景：適用于數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用于需要提供數據版本支持的應用程序。

例如： CRM、CMS系統。 master-master復制對于多站點部署是非常有用的。

2、Neo4j

所用語言： Java
特點：基于關系的圖形數據庫
使用許可： GPL，其中一些特性使用 AGPL/商業許可
協議： HTTP/REST（或嵌入在 Java中）
可獨立使用或嵌入到 Java應用程序
圖形的節點和邊都可以帶有元數據
很好的自帶web管理功能
使用多種算法支持路徑搜索
使用鍵值和關系進行索引
為讀操作進行優化
支持事務（用 Java api）
使用 Gremlin圖形遍歷語言
支持 Groovy腳本
支持在線備份，高級監控及高可靠性支持使用 AGPL/商業許可

最佳應用場景：適用于圖形一類數據。這是 Neo4j與其他nosql數據庫的最顯著區別
例如：社會關系，公共交通網絡，地圖及網絡拓譜

最佳應用場景：適用于數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用于需要提供數據版本支持的應用程序。

例如： CRM、CMS系統。 master-master復制對于多站點部署是非常有用的。

（編注2：master-master復制：是一種數據庫同步方法，允許數據在一組計算機之間共享數據，并且可以通過小組中任意成員在組內進行數據更新。）

3、 Cassandra

所用語言： Java
特點：對大型表格和 Dynamo支持得最好
使用許可： Apache
協議： Custom, binary (節約型)
可調節的分發及復制(N, R, W)
支持以某個范圍的鍵值通過列查詢
類似大表格的功能：列，某個特性的列集合
寫操作比讀操作更快
基于 Apache分布式平臺盡可能地 Map/reduce
我承認對 Cassandra有偏見，一部分是因為它本身的臃腫和復雜性，也因為 Java的問題（配置，出現異常，等等）

最佳應用場景：當使用寫操作多過讀操作（記錄日志）如果每個系統組建都必須用 Java編寫（沒有人因為選用 Apache的軟件被解雇）
例如：銀行業，金融業（雖然對于金融交易不是必須的，但這些產業對數據庫的要求會比它們更大）寫比讀更快，所以一個自然的特性就是實時數據分析

4、HBase

（配合 ghshephard使用）

所用語言： Java
特點：支持數十億行X上百萬列
使用許可： Apache
協議：HTTP/REST （支持 Thrift，見編注4）
在 BigTable之后建模
采用分布式架構 Map/reduce
對實時查詢進行優化
高性能 Thrift網關
通過在server端掃描及過濾實現對查詢操作預判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby（ JIRB）的shell
對配置改變和較小的升級都會重新回滾
不會出現單點故障
堪比MySQL的隨機訪問性能

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

例如： Facebook消息數據庫（更多通用的用例即將出現）
編注4：Thrift 是一種接口定義語言，為多種其他語言提供定義和創建服務，由Facebook開發并開源。

5、Tokyo Tyrant

• 持久性的鍵值存儲
• 用來處理需要持久保存，高速處理的數據
• 具有非常快的處理速度
• 用于不需要定期清除的數據
• 使用一致性散列(Consistent Hashing)算法來分散數據

6、redis

優點：

支持多種數據結構，如 string（字符串）、 list(雙向鏈表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基數估算）

支持持久化操作，可以進行aof及rdb數據持久化到磁盤，從而進行數據備份或數據恢復等操作，較好的防止數據丟失的手段。

支持通過Replication進行數據復制，通過master-slave機制，可以實時進行數據的同步復制，支持多級復制和增量復制，master-slave機制是Redis進行HA的重要手段。

單線程請求，所有命令串行執行，并發情況下不需要考慮數據一致性問題。

支持pub/sub消息訂閱機制，可以用來進行消息訂閱與通知。

支持簡單的事務需求，但業界使用場景很少，并不成熟。

缺點：

Redis只能使用單線程，性能受限于CPU性能，故單實例CPU最高才可能達到5-6wQPS每秒（取決于數據結構，數據大小以及服務器硬件性能，日常環境中QPS高峰大約在1-2w左右）。

支持簡單的事務需求，但業界使用場景很少，并不成熟，既是優點也是缺點。

Redis在string類型上會消耗較多內存，可以使用dict（hash表）壓縮存儲以降低內存
耗用。

7、Memcache

優點：

Memcached可以利用多核優勢，單實例吞吐量極高，可以達到幾十萬QPS（取決于key、value的字節大小以及服務器硬件性能，日常環境中QPS高峰大約在4-6w左右）。適用于最大程度扛量。

支持直接配置為session handle。

缺點：

只支持簡單的key/value數據結構，不像Redis可以支持豐富的數據類型。

無法進行持久化，數據不能備份，只能用于緩存使用，且重啟后數據全部丟失。

無法進行數據同步，不能將MC中的數據遷移到其他MC實例中。

Memcached內存分配采用Slab Allocation機制管理內存，value大小分布差異較大時會造成內存利用率降低，并引發低利用率時依然出現踢出等問題。需要用戶注重value設計。

8、MongoDB

優點：

更高的寫負載，MongoDB擁有更高的插入速度。

處理很大的規模的單表，當數據表太大的時候可以很容易的分割表。

高可用性，設置M-S不僅方便而且很快，MongoDB還可以快速、安全及自動化的實現節點（數據中心）故障轉移。

快速的查詢，MongoDB支持二維空間索引，比如管道，因此可以快速及精確的從指定位置獲取數據。MongoDB在啟動后會將數據庫中的數據以文件映射的方式加載到內存中。如果內存資源相當豐富的話，這將極大地提高數據庫的查詢速度。

非結構化數據的爆發增長，增加列在有些情況下可能鎖定整個數據庫，或者增加負載從而
導致性能下降，由于MongoDB的弱數據結構模式，添加1個新字段不會對舊表格有任何影響，
整個過程會非常快速。

缺點：

不支持事務。

MongoDB占用空間過大 。

MongoDB沒有成熟的維護工具。

9、Redis、Memcache和MongoDB的區別

9.1 性能

三者的性能都比較高，總的來講：Memcache和Redis差不多，要高于MongoDB。

9.2 便利性

memcache數據結構單一。
redis豐富一些，數據操作方面，redis更好一些，較少的網絡IO次數。
mongodb支持豐富的數據表達，索引，最類似關系型數據庫，支持的查詢語言非常豐富。

9.3 存儲空間

redis在2.0版本后增加了自己的VM特性，突破物理內存的限制；可以對key value設置過期時間（類似memcache）。
memcache可以修改最大可用內存,采用LRU算法。
mongoDB適合大數據量的存儲，依賴操作系統VM做內存管理，吃內存也比較厲害，服務不要和別的服務在一起。

9.4 可用性

redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整個快照,無增量復制，因性能和效率問題，所以單點問題比較復雜；不支持自動sharding,需要依賴程序設定一致hash 機制。一種替代方案是，不用redis本身的復制機制，采用自己做主動復制（多份存儲），或者改成增量復制的方式（需要自己實現），一致性問題和性能的權衡。

Memcache本身沒有數據冗余機制，也沒必要；對于故障預防，采用依賴成熟的hash或者環狀的算法，解決單點故障引起的抖動問題。

mongoDB支持master-slave,replicaset（內部采用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制。

9.5 可靠性

redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響。
memcache不支持，通常用在做緩存,提升性能。
MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性。

9.6 一致性

Memcache 在并發場景下，用cas保證一致性。
redis事務支持比較弱，只能保證事務中的每個操作連續執行。
mongoDB不支持事務。

9.7 數據分析

mongoDB內置了數據分析的功能(mapreduce),其他兩者不支持。

9.8 應用場景

redis：數據量較小的性能操作和運算上。
memcache：用于在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫
少，對于數據量比較大，可以采用sharding）。
MongoDB:主要解決海量數據的訪問效率問題。

總結

以上是生活随笔為你收集整理的常见的NoSQL数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。