海量日誌數據存儲用 elasticsearch 和 hbase 哪個好？

01-04

每天 5G 的流水日誌（也許標題不應該寫海量。。。），不知道怎麼存儲比較好，目前能想到的方案就是 elasticsearch 和 hbase ，不知道哪個更好呢？個人比較傾向 es 這個非結構化的資料庫，hbase 是結構化的，以後想加欄位會比較麻煩。大家覺得呢？

單純從技術的角度來說其實沒有好壞之分，技術選型需要結合實際的業務場景來定。從問題描述上看大致可以從幾個方面來考慮：

1）數據量

每天5G數據量，按存儲1年的數據來考慮，大概是1.8T，es和hbase都能支持，並且兩者都可以通過擴展集群來加大可存儲的數據量。隨著數據量的增加，es的讀寫性能會有所下降，從存儲原始數據的角度來看，hbase要優於es

2）數據更新

es數據更新是對文檔進行更新，需要先將es中的數據取出，設置更新欄位後再寫入es。hbase是列存儲的，可以方便地更新任意欄位的值。

3）查詢複雜度

hbase支持簡單的行、列或範圍查詢，若沒有對查詢欄位做二級索引的話會引發掃全表操作，性能較差。而ES提供了豐富的查詢語法，支持對多種類型的精確匹配、模糊匹配、範圍查詢、聚合等操作，ES對欄位做了反向索引，即使在億級數據量下還可以達到秒級的查詢響應速度。

4）欄位擴展性

hbase和es都對非結構化數據存儲提供了良好的支持。es可以通過動態欄位方便地對欄位進行擴展，而hbase本身就是基於列存儲的，可以很方便地添加qualifier來實現欄位的擴展

從基本功能來說這兩個確實有相似性，但是根據業務需求不同，我覺得有幾點可以考慮：

1. 查詢複雜度：HBase支持簡單的行或者range查詢，比如給一個PK查該行的數據，或者給一個begin/end查這個範圍的數據，如果想完成更複雜的功能就不太容易。而ES支持的查詢比較豐富，或者說這些查詢都帶有一點複雜計算的味道了。比如你有個論壇，你想查帖子裡面是否包含敏感詞，如果採用HBase就比較麻煩，使用HBase你可以將帖子存進來、讀出去，但是要查內容裡面的東西，只能一點點過濾；而ES是可以比較方便的幫助你完成這個功能的；

2. 數據量：按道理說兩者都是支持海量數據的，但是據我個人感覺，HBase可能更容易支持更多的數據，因為其一開始設計就是解決海量問題的；而ES是後來慢慢增強其存儲擴展性的；那麼也就是說，HBase上手起來擴展性不太會阻礙你使用；ES可能要多費點勁。當然，聽說也有人寫了ES基於Azure或者S3的存儲插件，但是穩定性不知道如何；

3. 剩下的就是比較遠的考慮，比如維護性，HBase基於Hadoop那一套，組件多，維護起來代價也不低，而ES自成體系，維護起來稍微好點；當然這個是相對的，絕對來說都不會容易。比如新功能開發，比如成本控制等等。。。

elasticsearch 和 hbase 存儲機制是不一樣，

hbase是Key vlaue的形式，大批量拉取數據，存儲海量的數據性能必須大於elasticsearch，但是搜索列沒有優勢。

elasticsearch是基於lucene，優點是搜索速度快，方便建立索引，支持全文檢索，但是數據上百億的情況下，干不過hbase。

兩者都有好處，而且使用場景不一樣，如果題主喜歡elasticsearch，說實話你一天2G的數據，我覺得沒有問題，關鍵看你的業務邏輯如何處理，數據要存儲多久時間，全文搜索多久的數據，劃分好，過期的數據定時清除，保持索引庫的高可用即可.

這兩個不應該拿來做對比。看一下各自的介紹：

Elasticsearch is a search server based on Lucene. （wiki：Elasticsearch）
HBase is an open source, non-relational, distributed database modeled after Google"sBigTable and written in Java.（wiki：Apache HBase）

一個是搜索引擎，一個是資料庫。

在分散式環境中，兩者得到廣泛使用，但發揮的作用是不一樣的。具體要怎麼使用怎麼配合，要看實際業務了。

1. HBase是schema free的，加欄位完全沒問題

2. 用ES存日誌數據，成本會很高

3. 偏分析還是偏存儲？還是兩者結合？應用場景是什麼?

4. 推薦的架構：ES給日誌建索引（看業務是否需要），日誌原始內容存HBase。

HBase結構化………

呵

不能加欄位不會用而已ho

選個你會用的架構

ElasticSearch + Logstash + Kibana

本質上是個搜索引擎，可視化不錯，適合簡單、實時的場景。不應作為一個存儲方案，因為數據很難取，只能用ES來搜。

Hbase + Hadoop

海量數據、大計算量，適合持久存數據，適合做深度的數據分析。

如果題主要做實時、動態的計數，則推薦ES。

如果題主要跑些月報表什麼的，則推薦Hbase。

才5gb的日誌，對es技術棧來說太小意思了，你可以查找一下攜程網的技術slide 《TB級日誌的秒級檢索》 Elasticsearch logstsh kiabana是開源日誌檢索系統的主流技術，存大數據一點問題沒有，有的問題就是貴公司舍不捨得撥款那麼多機器來存數據

Elasticsearch 並不是資料庫，是搜索引擎，沒有用過hbase，組裡正在用Elasticsearch，就說說ES吧。一天5G，一年也就1.8T，我們組的ES，配置如下：

5個virtual machine，每個vm有8個VCPU，32G的內存，2T的SSD。這個cluster專門是ES。一年下來，一共存了9T的數據。我們一共有大概100+個index，每個index是5個shard，RF2。最大的一個index有1.5T。一年過後每個vm加了另外1T的ssd，應該還能用上一陣。

所以從提問的人的需求來看，如果你按周或按月來創建index，3-5個node，配置也可以比我們低一些。半年或者一年rotate，完全可以符合要求。配上kibana和logstash，還可以做可視化分析。我相信效果會比hbase好，畢竟數據量並不是很大。

也歡迎有用了hbase的朋友貼一貼配置和數據量，互相交流

這兩個功能有重疊。

本質不一樣

如果知識簡單的存儲讀取。就用es好了

如果將來業務會偏向複雜那麼

推薦使用

推薦用ES給日誌建索引，日誌原始內容存HBase。這樣數據搜索效率達到最高。

hbase面向列非常好加欄位的！

es適合搜索和分析小規模數據，速度快過hbase。

hbase穩定可靠，而且可以通過mr spark等大批量拉取數據。

不過你這種5g的數據扔哪沒啥區別，開心就好。

hbase存多讀少，不適合高並發查詢，適合存數據；

es是全文檢索，適合日誌分析日誌統計之類。

ps：hbase是面向列存儲的nosql資料庫，怎麼就成了結構化的了？

ELK相關的幾個問題是否關註：

1、運維管理方不方便。ELK是三個獨立的系統，沒有統一的部署、管理工具，需要分別部署及管理這三套系統。

2、多部門協調辦公嗎，ELK沒有用戶認證及許可權管理。

3、Elasticsearch存在嚴重的安全漏洞，沒經驗的用戶很可能中招，被黑客入侵。

4、······

全球500億條數據被 Elasticsearch 勒索者刪除，中國受災排第二

每天 5G 的數據量可以輕鬆的現在日誌易

我覺得elasticsearch可能更有優勢點，首先日誌多種多樣，結構不統一，es這種非結構化存儲更方便靈活。再者，es的查詢速度非常快，如果你的日誌是實時打入的，那麼利用es的可視化工具kibana，利用luence語法，可以篩選出相應的日誌信息，特別是對於多台機器，統一日誌都在es中，不用到指定機器查詢。

看存儲的目的，僅僅為了保存，hbase，如果批量任務 hbase 如果實時查詢elasticsearch

如果僅僅是存儲，稍有分析需求，或分析需求實時性要求不高，可以用hbase。

反之用es，太方便了

5g es完全沒問題，同時配套的web之類的也有了。會節省很多時間。

選擇elasticsearch 還是hbase主要是取決於你的業務場景和需求，如何通過日誌進行一些搜索和分析統計工作可以考慮使用elasticsearch,logstash,kibana可視化組合棒棒的，每日5GB這個不是什麼大的數據量

我個人覺得，es注重的還是檢索，hbase擅長的是讀寫操作，所以還需要看見你的應用場景