【架構選型】-- HBase 、MongoDB、Redis和ES的應用場景選擇

目錄

​​1 HBase-2008年初始版本​​

​​1.1 特點​​

​​1.2 缺點（與關系性資料庫對比）​​

​​1.3 應用場景​​

​​1.4 FAQ​​

​​2 MongoDB-2009年初始版本​​

​​2.1 特點​​

​​2.2 缺點（與關系性資料庫對比）​​

​​2.2.1 acid事務​​

​​2.2.2 運維​​

​​2.2.3 mongodb占用空間過大​​

​​2.3 應用場景​​

​​2.3.1.适用場景​​

​​2.3.2.不适合場景​​

​​2.4 FAQ​​

​​3 Redis-2009年初始版本​​

​​3.1 特點​​

​​3.2 缺點（與關系性資料庫對比）​​

​​3.3 應用場景​​

​​3.4 FAQ​​

​​4 ES-2010年初始版本​​

​​4.1 優點​​

​​4.2 缺點​​

​​4.3 應用場景​​

​​日志分析​​

​​全文檢索​​

​​商業智能 BI​​

​​4.4 FAQ​​

​​5 總結​​

HBase、MongoDB、ElasitcSearch和Redis 都是 NoSql 資料庫，各有千秋，應用場景也不同。

1 HBase-2008年初始版本

1.1 特點

1.1.1 容量大


    傳統關系型資料庫，單表不會超過五百萬，超過要做分表分庫，不會超過30列。

    Hbase單表可以有百億行、百萬列，資料矩陣橫向和縱向兩個次元所支援的資料量級都非常具有彈性。

1.1.2 面向列

      
面向列的存儲和權限控制，并支援獨立檢索，可以動态增加列，即，可單獨對列進行各方面的操作
列式存儲，其資料在表中是按照某列存儲的，這樣在查詢隻需要少數幾個字段的時候，能大大減少讀取的數量。

1.1.3 多版本


     Hbase的每一個列的資料存儲有多個Version，比如住址列，可能有多個變更，是以該列可以有多個version

1.1.4 稀疏性


      為空的列并不占用存儲空間，表可以設計的非常稀疏。不必像關系型資料庫那樣需要預先知道所有列名然後再進行null填充

1.1.5 拓展性


     底層依賴HDFS，當磁盤空間不足的時候，隻需要動态增加datanode節點服務(機器)就可以了

1.1.6 高可靠性


      WAL機制，保證資料寫入的時候不會因為叢集異常而導緻寫入資料丢失。

Replication機制，保證了在叢集出現嚴重的問題時候，資料不會發生丢失或者損壞。

Hbase底層使用HDFS，本身也有備份。

1.1.7 高性能

         
底層的LSM資料結構和RowKey有序排列等架構上的獨特設計，使得Hbase寫入性能非常高。
Region切分、主鍵索引、緩存機制使得Hbase在海量資料下具備一定的随機讀取性能，該性能針對Rowkey的查詢能夠到達毫秒級别。

         LSM樹，樹形結構，最末端的子節點是以記憶體的方式進行存儲的，記憶體中的小樹會flush到磁盤中（當子節點達到一定門檻值以後，會放到磁盤中，且存入的過程會進行實時merge成一個主節點，然後磁盤中的樹定期會做merge操作，合并成一棵大樹，以優化讀性能。）

1.2 缺點（與關系性資料庫對比）

• 不支援複雜查詢，如條件查詢，隻支援按照row key來查詢
• 容易産生單點故障（在隻使用一個HMaster的時候），HA 的master 可以避免
• 不支援事務
• JOIN不是資料庫層支援的，而需要用MapRecue
• 隻能在主鍵上索引和排序
• 沒有内置的身份和權限認證，需要外部支援

1.3 應用場景

1. 寫密集型應用，每天寫入量巨大(上千萬或者上億行，每日 TB 以上資料量)，而相對讀數量較小的應用，比如遊戲的日志，DNS資訊等

2. 不需要複雜查詢條件來查詢資料的應用，HBase隻支援基于rowkey的查詢，對于HBase來說，單條記錄或者小範圍的查詢是可以接受的，大範圍的查詢由于分布式的原因，可能在性能上有點影響，而對于像SQL的join等查詢，HBase無法支援。

3. 對性能和可靠性要求非常高的應用，由于HBase本身沒有單點故障，可用性非常高。

1.4 FAQ

​​https://hbase.apache.org/book.html#faq​​

注意

• 面向列，容量大，寫入比mysql快但是讀取沒有mysql快，超過五百萬條資料，則建議讀寫用HBase
• 業務可不依賴 RDBMS 的額外特性。例如，列資料類型、第二索引、事務、進階查詢語言等
• 確定有足夠的硬體。因為HDFS在小于5個資料節點時，基本上展現不出來它的優勢

2 MongoDB-2009年初始版本

2.1 特點

• 弱一緻性（最終一緻），更能保證使用者的通路速度
• 文檔結構的存儲方式，能夠更便捷的擷取資料
• 内置GridFS，支援大容量的存儲
• 内置Sharding
• 第三方支援豐富

2.2 缺點（與關系性資料庫對比）

2.2.1 acid事務

mongodb 4.0以前不支援 acid 事務操作

2.2.2 運維

• MongoDB沒有如MySQL那樣成熟的維護工具，這對于開發和IT營運都是個值得注意的地方。
• 在叢集分片中的資料分布不均勻
• 單機可靠性比較差
• 大資料量持續插入，寫入性能有較大波動

2.2.3 mongodb占用空間過大

關于其原因，在官方的FAQ中，提到有如下幾個方面：

• 空間的預配置設定：為避免形成過多的硬碟碎片，mongodb每次空間不足時都會申請生成一大塊的硬碟空間，而且申請的量從64M、128M、256M那樣的指數遞增，直到2G為單個檔案的最大體積。随着資料量的增加，你可以在其資料目錄裡看到這些整塊生成容量不斷遞增的檔案。
• 字段名所占用的空間：為了保持每個記錄内的結構資訊用于查詢，mongodb需要把每個字段的key-value都以BSON的形式存儲，如果 value域相對于key域并不大，比如存放數值型的資料，則資料的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些，這樣占用空間就小了，但這就要求在易讀性與空間占用上作為權衡了。我曾建議作者把字段名作個index，每個字段名用一個位元組表示，這樣就不用擔心字段名取多長了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到用戶端，這個替換也是挺耗費時間的。現在的實作算是拿空間來換取時間吧。
• 删除記錄不釋放空間：這很容易了解，為避免記錄删除後的資料的大規模挪動，原記錄空間不删除，隻标記“已删除”即可，以後還可以重複利用。
• 可以定期運作db.repairDatabase()來整理記錄，但這個過程會比較緩慢

2.3 應用場景

2.3.1.适用場景

• 網站實時資料：實時的插入，更新與查詢，并具備網站實時資料存儲所需的複制及高度伸縮性。
• 資料緩存:資訊基礎設施的緩存層。在系統重新開機之後，由 MongoDB 搭建的持久化緩存層可以避免下層的資料源過載。
• 大尺寸、低價值資料存儲:使用傳統的關系型資料庫存儲一些資料時可能會比較昂貴，在此之前，很多時候程式員往往會選擇傳統的檔案進行存儲。
• 高伸縮性場景:由數十或數百台伺服器組成的資料庫。MongoDB 的路線圖中已經包含對 MapReduce 引擎的内置支援。
• 對象或 JSON 資料存儲:  BSON 資料格式非常适合文檔化格式的存儲及查詢。

2.3.2.不适合場景

• 高度事務性系統:例如銀行或會計系統。傳統的關系型資料庫目前還是更适用于需要大量原子性複雜事務的應用程式
• 傳統的商業智能應用:針對特定問題的BI 資料庫會對産生高度優化的查詢方式。對于此類應用，資料倉庫可能是更合适的選擇
• 需要複雜SQL 查詢的問題

2.4 FAQ

​​https://www.mongodb.com/faq​​

注意事項：​​https://www.huaweicloud.com/articles/bc546fc97713dc4d6cfe8f0898ff170a.html​​

3 Redis-2009年初始版本

3.1 特點

• 記憶體資料庫，速度快，也支援資料的持久化，可以将記憶體中的資料儲存在磁盤中，重新開機的時候可以再次加載進行使用
• Redis不僅僅支援簡單的key-value類型的資料，同時還提供list，set，zset，hash等資料結構的存儲
• Redis支援資料的備份，即master-slave模式的資料備份
• 支援事務

優勢

• 性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 
• 豐富的資料類型 – Redis支援二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 資料類型操作
• 原子 – Redis的所有操作都是原子性的，同時Redis還支援對幾個操作合并後的原子性執行。（事務）
• 豐富的特性 – Redis還支援 publish/subscribe, 通知, key 過期等等特性

3.2 缺點（與關系性資料庫對比）

• 由于 Redis 是記憶體資料庫，是以，單台機器，存儲的資料量，跟機器本身的記憶體大小。雖有 Key 過期政策，但是還是需要提前預估和節約記憶體。如果記憶體增長過快，需要定期删除資料。
• redis 是單線程的，單台伺服器無法充分利用多核伺服器的CPU
• 修改配置檔案，進行重新開機，将硬碟中的資料加載進記憶體，時間比較久。在這個過程中，redis不能提供服務

3.3 應用場景

3.3.1 緩存

   緩存現在幾乎是所有中大型網站都在用的必殺技，合理的利用緩存不僅能夠提升網站通路速度，還能大大降低資料庫的壓力。Redis提供了鍵過期功能，也提供了靈活的鍵淘汰政策，是以，現在Redis用在緩存的場合非常多。

3.3.2 排行榜

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

3.3.3 計數器

什麼是計數器，如電商網站商品的浏覽量、視訊網站視訊的播放數等。為了保證資料實時效，每次浏覽都得給+1，并發量高時如果每次都請求資料庫操作無疑是種挑戰和壓力。Redis提供的incr指令來實作計數器功能，記憶體操作，性能非常好，非常适用于這些計數場景。

3.3.4 分布式會話

叢集模式下，在應用不多的情況下一般使用容器自帶的session複制功能就能滿足，當應用增多相對複雜的系統中，一般都會搭建以Redis等記憶體資料庫為中心的session服務，session不再由容器管理，而是由session服務及記憶體資料庫管理。

3.3.5 分布式鎖

在很多網際網路公司中都使用了分布式技術，分布式技術帶來的技術挑戰是對同一個資源的并發通路，如全局ID、減庫存、秒殺等場景，并發量不大的場景可以使用資料庫的悲觀鎖、樂觀鎖來實作，但在并發量高的場合中，利用資料庫鎖來控制資源的并發通路是不太理想的，大大影響了資料庫的性能。可以利用Redis的setnx功能來編寫分布式的鎖，如果設定傳回1說明擷取鎖成功，否則擷取鎖失敗，實際應用中要考慮的細節要更多。

3.3.6 社交網絡

點贊、踩、關注/被關注、共同好友等是社交網站的基本功能，社交網站的通路量通常來說比較大，而且傳統的關系資料庫類型不适合存儲這種類型的資料，Redis提供的哈希、集合等資料結構能很友善的的實作這些功能。

3.3.7 最新清單

Redis清單結構，LPUSH可以在清單頭部插入一個内容ID作為關鍵字，LTRIM可用來限制清單的數量，這樣清單永遠為N個ID，無需查詢最新的清單，直接根據ID去到對應的内容頁即可。

3.3.8 消息系統

消息隊列是大型網站必用中間件，如ActiveMQ、RabbitMQ、Kafka等流行的消息隊列中間件，主要用于業務解耦、流量削峰及異步處理實時性低的業務。Redis提供了釋出/訂閱及阻塞隊列功能，能實作一個簡單的消息隊列系統。另外，這個不能和專業的消息中間件相比。

3.4 FAQ

​​https://redis.io/topics/faq​​

4 ES-2010年初始版本

4.1 優點

​

• 功能全面
• Restful API
• 擴充性強
• 支援複雜查詢

4.2 缺點

• 字段類型無法修改、寫入性能較低和高硬體資源消耗
• 各節點資料的一緻性問題：其預設的機制是通過多點傳播機制，同步中繼資料資訊，但是在比較繁忙的叢集中，可能會由于網絡的阻塞，或者節點處理能力達到飽和，導緻各資料節點資料不一緻——也就是所謂的腦裂問題，這樣會使得叢集處于不一緻狀态。目前并沒有一個徹底的方案來解決這個問題，但是可以通過參數配置和節點角色配置來緩解這種情況。
• 沒有細緻的權限管理，也就是說，沒有像mysql那樣的分各種使用者，每個使用者又有不同的權限。是以在操作上的限制需要自己開發一個系統化來完成。

4.3 應用場景

參考：​​https://cloud.tencent.com/document/product/845/16480​​

日志分析

• 網站伺服器、移動裝置、IOT 傳感器等裝置産生的日志都存在節點分散、種類多樣、規模龐大等問題，這對需要通過日志搜尋進行異常問題定位和業務分析等工作造成了很大的挑戰。ES 提供了彈性可擴充、實時的集中式存儲方案以及全文搜尋功能，友善日志的統一管理和查詢，幫助使用者快速定位和發現問題，提高解決問題的效率。

全文檢索

• 電商商品搜尋、移動應用搜尋、企業内部資訊搜尋等海量資料下的站内搜尋服務是高效擷取資訊的必要途徑，ES 擁有全文檢索功能，對結構化和非結構化資料都有良好的支援，同時還提供了簡單易用的 RESTful API 和各種語言的用戶端，友善使用者快速搭建穩定的搜尋服務，整合到已有的業務架構中。

商業智能 BI

• 在資料驅動營運的行業背景下，電子商務、移動應用、廣告媒體等業務都需要借助資料分析和資料挖掘來輔助商業決策，而規模龐大的業務資料對資料的統計分析造成了很大的挑戰。ES 擁有結構化查詢的能力，支援複雜的過濾和聚合統計功能，幫助客戶對海量資料進行高效地個性化統計分析、發現問題與機會、輔助商業決策，讓資料産生真正的價值。

4.4 FAQ

​​https://www.elastic.co/guide/en/cloud/current/ec-faq-getting-started.html​​

5 總結

如何在 Redis、Mongodb、ES和 HBase 中進行技術選型，如下：

• Redis：如果你對資料的讀寫要求極高，并且你的資料規模不大，也不需要長期存儲，選redis；
• MongoDB：如果你的資料規模較大，對資料的讀性能要求很高，資料表的結構需要經常變，有時還需要做一些聚合查詢，選MongoDB；
• ES：如果你需要構造一個搜尋引擎或者你想搞一個看着高大上的資料可視化平台，并且你的資料有一定的分析價值或者你的老闆是土豪，選ElasticSearch；
• HBase：如果你需要存儲海量資料，連你自己都不知道你的資料規模将來會增長多麼大，那麼選HBase。

支援情況	Bad	General	Good	Best
資料規模	Redis	ES	MongoDB	Hbase
查詢性能	Hbase	ES	MongoDB	Redis
寫入性能	ES	MongoDB	Hbase	Redis
複雜查詢&檢索	Redis