NoSQL 比較及應用場景選擇?

NoSQL是一個通用術語,數據是非關係型的,它是用於解決可伸縮性和可用性問題而不是原子性或一致性問題的數據庫。

NoSQL可以用描述任何一種數據文件,不具備傳統關係型數據庫的範式,NoSQL是非關係型設計的Database,主要針對當前互聯網時代的複雜數據

1.性能

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

2.操作的便利性

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

3.內存空間的大小和數據量的大小

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

4.可用性(單點問題)

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

(1) Redis

依賴客戶端來實現分佈式讀寫;主從複製時,每次從節點重新連接主節點都要依賴整個快照,無增量複製;不支持自動sharding,需要依賴程序設定一致hash機制。

(2) Monogodb

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

(3) Memcache

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

(4) Cassandra

一個沒有單點故障的Dynamo風格的複製模型

(5) HBase

配置hbase的高可用的目的是為了解決主從架構的單點故障問題????

(6) Neo4j

5.可靠性(持久化)

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

6.數據一致性(事務特性)

數據一致性,就是當多個用戶試圖同時訪問一個數據庫,它們的事務同時使用相同的數據時,可能會發生以下四種情況:丟失更新、未確定的相關性、不一致的分析和幻想讀。

(1) Redis

redis事務支持比較弱,只能保證事務中的每個操作連續執行。

(2) Monogodb

mongoDB不支持事務。

(3) Memcache

Memcache 在併發場景下,用cas保證一致性。

(4) Cassandra

提供輕量級事務支持,用於cas更新

(5) HBase

有行級鎖memstore鎖,region鎖

(6) Neo4j

讀鎖和寫鎖來控制每一個圖形數據庫資源,如節點和之間關係

7.數據分析

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

8.應用場景

Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j、HBase

(1) Redis

  • 緩存
  • 排行榜

很多網站都有排行榜應用的,如京東的月度銷量榜單、商品按時間的上新排行榜等。Redis提供的有序集合數據類構能實現各種複雜的排行榜應用。

  • 計數器

什麼是計數器,如電商網站商品的瀏覽量、視頻網站視頻的播放數等。為了保證數據實時效,每次瀏覽都得給+1,併發量高時如果每次都請求數據庫操作無疑是種挑戰和壓力。

  • 分佈式會話

集群模式下,在應用不多的情況下一般使用容器自帶的session複製功能就能滿足,當應用增多相對複雜的系統中,一般都會搭建以Redis等內存數據庫為中心的session服務,session不再由容器管理,而是由session服務及內存數據庫管理。

分佈式鎖

在很多互聯網公司中都使用了分佈式技術,分佈式技術帶來的技術挑戰是對同一個資源的併發訪問,如全局ID、減庫存、秒殺等場景,併發量不大的場景可以使用數據庫的悲觀鎖、樂觀鎖來實現,但在併發量高的場合中,利用數據庫鎖來控制資源的併發訪問是不太理想的,大大影響了數據庫的性能。可以利用Redis的setnx功能來編寫分佈式的鎖,如果設置返回1說明獲取鎖成功。

  • 社交網絡

點贊、踩、關注/被關注、共同好友等是社交網站的基本功能。

  • 最新列表

Redis列表結構

  • 消息系統

消息隊列是大型網站必用中間件。

(2) Monogodb

MongoDB 的主要目標是在鍵/值存儲和傳統的RDBMS 系統之間架起一座橋樑,它集兩者的優勢於一身。

  • 網站數據:Mongo 非常適合實時的插入,更新與查詢,並具備網站實時數據存儲所需的複製及高度伸縮性。
  • 緩存:由於性能很高,Mongo 也適合作為信息基礎設施的緩存層。
  • 大尺寸、低價值的數據
  • 高伸縮性的場景:Mongo 非常適合由數十或數百臺服務器組成的數據庫。
  • 用於對象及JSON 數據的存儲


(3) Memcache

  • 分佈式

由於memcached本身基於分佈式的系統,所以尤其適合大型的分佈式系統。

  • 前段緩存

數據庫常常是網站系統的瓶頸。數據庫的大併發量訪問,常常造成網站內存溢出。當然我們也可以使用Hibernate的緩存機制。但memcached是基於分佈式的,並可獨立於網站應用本身,所以更適合大型網站進行應用的拆分。

  • 服務器間數據共享。

(4) Cassandra

  • 寫入大幅度超出讀。
  • 數據很少更新,並且在進行更新時它們是冪等的。
  • 通過主鍵查詢,非二級索引。
  • 可以通過partitionKey均勻分區。
  • 不需要Join或聚合。


  • 交易日誌:購買,測試分數,觀看的電影等。
  • 存儲時序數據
  • 跟蹤幾乎任何事情,包括訂單狀態,包裹等。
  • 存儲健康追蹤數據。
  • 氣象服務歷史。
  • 物聯網狀態和事件歷史。
  • 汽車的物聯網數據。
  • 電子郵件

(5) HBase

  • 對象存儲:頭條類、新聞類的的新聞、網頁、圖片存儲在HBase之中,一些病毒公司的病毒庫也是存儲在HBase之中
  • 時序數據:HBase之上有OpenTSDB模塊,可以滿足時序類場景的需求
  • 推薦畫像:特別是用戶的畫像,是一個比較大的稀疏矩陣,螞蟻的風控就是構建在HBase之上
  • 時空數據:主要是軌跡、氣象網格之類,滴滴打車的軌跡數據主要存在HBase之中,另外在技術所有大一點的數據量的車聯網企業,數據都是存在HBase之中
  • CubeDB OLAP:Kylin一個cube分析工具,底層的數據就是存儲在HBase之中,不少客戶自己基於離線計算構建cube存儲在hbase之中,滿足在線報表查詢的需求
  • 消息/訂單:在電信領域、銀行領域,不少的訂單查詢底層的存儲,另外不少通信、消息同步的應用構建在HBase之上
  • Feeds流:典型的應用就是xx朋友圈類似的應用
  • NewSQL:之上有Phoenix的插件,可以滿足二級索引、SQL的需求,對接傳統數據需要SQL非事務的需求


(6) Neo4j


NoSQL 比較及應用場景選擇?



分享到:


相關文章: