1樓：
5G很小了，直接分片存raid5磁碟，手擼乙個簡單的查詢引擎，搞定。
運維一套ELK或者hbase，成本可不小。
如果傾向於開源方案的話，看下loki吧，雲原生，低成本。
2樓：dz lee
elasticsearch和Hbase結合使用是不錯的選擇.
Hbase:
儲存是很不錯的選擇,NOSQL格式,方便擴充套件列,寫入效能不錯.rowkey的查詢效率高.
但是其他字段檢索,全表掃瞄就很慢了.
elasticsearch:
優勢是查詢檢索引擎,支援複雜的查詢條件,此方面完爆Hbase(注意是複雜的查詢條件情況),如果只是需要通過Hbase主鍵rowkey查詢的需求,那Hbase查詢也很強.
但是寫入效能相對Hbase來說是不如的.
所以把你業務需要的查詢字段內容放在elasticsearch上儲存查詢,同時儲存Hbase的rowKey資訊.
業務使用時,通過elasticsearch查詢出Hbase的rowkey,再從Hbase讀取出全部資訊是不錯的組合.
思路就是:找出結合各元件優劣勢,搭配出適合自己的用途.
3樓：BadSmile
我們最近也有類似的需求，也在做技術選型，在考慮使用哪一種方案來存我們的感測器資料，我們的業務場景是寫多讀少，讀寫比大概是2：8吧，所以我們考慮使用hbase，因為但凡索引類的產品，寫就面臨索引的更新，這多少是有開銷的，所以個人見解，寫多讀少用hbase，讀多寫少用es，資料量不大或者讀寫頻率不高，那開心就好
4樓：Jerry
我覺得elasticsearch可能更有優勢點，首先日誌多種多樣，結構不統一，es這種非結構化儲存更方便靈活。再者，es的查詢速度非常快，如果你的日誌是實時打入的，那麼利用es的視覺化工具kibana，利用luence語法，可以篩選出相應的日誌資訊，特別是對於多台機器，統一日誌都在es中，不用到指定機器查詢。
5樓：李卓然
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好，畢竟資料量並不是很大。
6樓：
單純從技術的角度來說其實沒有好壞之分，技術選型需要結合實際的業務場景來定。從問題描述上看大致可以從幾個方面來考慮：
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來實現欄位的擴充套件
7樓：冰封
elasticsearch 和 hbase 儲存機制是不一樣，hbase是Key vlaue的形式，大批量拉取資料，儲存海量的資料效能必須大於elasticsearch，但是搜尋列沒有優勢。
elasticsearch是基於lucene，優點是搜尋速度快，方便建立索引，支援全文檢索，但是資料上百億的情況下，幹不過hbase。
兩者都有好處，而且使用場景不一樣，如果題主喜歡elasticsearch，說實話你一天2G的資料，我覺得沒有問題，關鍵看你的業務邏輯如何處理，資料要儲存多久時間，全文搜尋多久的資料，劃分好，過期的資料定時清除，保持索引庫的高可用即可.
8樓：楊東東
從基本功能來說這兩個確實有相似性，但是根據業務需求不同，我覺得有幾點可以考慮：
1. 查詢複雜度：HBase支援簡單的行或者range查詢，比如給乙個PK查該行的資料，或者給乙個begin/end查這個範圍的資料，如果想完成更複雜的功能就不太容易。
而ES支援的查詢比較豐富，或者說這些查詢都帶有一點複雜計算的味道了。比如你有個論壇，你想查帖子裡面是否包含敏感詞，如果採用HBase就比較麻煩，使用HBase你可以將帖子存進來、讀出去，但是要查內容裡面的東西，只能一點點過濾；而ES是可以比較方便的幫助你完成這個功能的；
2. 資料量：按道理說兩者都是支援海量資料的，但是據我個人感覺，HBase可能更容易支援更多的資料，因為其一開始設計就是解決海量問題的；而ES是後來慢慢增強其儲存擴充套件性的；那麼也就是說，HBase上手起來擴充套件性不太會阻礙你使用；ES可能要多費點勁。
當然，聽說也有人寫了ES基於Azure或者S3的儲存外掛程式，但是穩定性不知道如何；
3. 剩下的就是比較遠的考慮，比如維護性，HBase基於Hadoop那一套，元件多，維護起來代價也不低，而ES自成體系，維護起來稍微好點；當然這個是相對的，絕對來說都不會容易。比如新功能開發，比如成本控制等等。。。
9樓：
才5gb的日誌，對es技術棧來說太小意思了，你可以查詢一下攜程網的技術slide 《TB級日誌的秒級檢索》 Elasticsearch logstsh kiabana是開源日誌檢索系統的主流技術，存大資料一點問題沒有，有的問題就是貴公司舍不捨得撥款那麼多機器來存資料
10樓：木洛
1. HBase是schema free的，加欄位完全沒問題2. 用ES存日誌資料，成本會很高
3. 偏分析還是偏儲存？還是兩者結合？應用場景是什麼?
4. 推薦的架構：ES給日誌建索引（看業務是否需要），日誌原始內容存HBase。
11樓：face hog
hbase存多讀少，不適合高併發查詢，適合存資料；
es是全文檢索，適合日誌分析日誌統計之類。
ps：hbase是面向列儲存的nosql資料庫，怎麼就成了結構化的了？
12樓：Golion
ElasticSearch + Logstash + Kibana本質上是個搜尋引擎，視覺化不錯，適合簡單、實時的場景。不應作為乙個儲存方案，因為資料很難取，只能用ES來搜。
Hbase + Hadoop
海量資料、大計算量，適合持久存資料，適合做深度的資料分析。
如果題主要做實時、動態的計數，則推薦ES。
如果題主要跑些月報表什麼的，則推薦Hbase。
13樓：金色木葉楓
選擇elasticsearch 還是hbase主要是取決於你的業務場景和需求，如何通過日誌進行一些搜尋和分析統計工作可以考慮使用elasticsearch,logstash,kibana視覺化組合棒棒的，每日5GB這個不是什麼大的資料量
14樓：YING zz
hbase面向列非常好加字段的！
es適合搜尋和分析小規模資料，速度快過hbase。
hbase穩定可靠，而且可以通過mr spark等大批量拉取資料。
不過你這種5g的資料扔哪沒啥區別，開心就好。
銀行海量交易資料是怎麼儲存的？海量流水資料如何開放給客戶查甚至匯出？
zhen liang 如果人人能購買DB2，自然沒有其他大資料軟體市場了，谷歌設計這個打敗IBM的，當然銀行還是在使用db2，其他行業使用其他軟體 地主 負責任地告訴LZ，幾大行基於hadoop技術開展的第乙個應用基本都是歷史資料查詢！目前已經有多個行投產上線 最早的13年底就已經投產了 相比於原來...
請問Ceph能扛得住海量小檔案儲存嗎？
陳濤在走神 目前ceph已經能使用Bluestore直接對接裸盤了，min alloc size 預設是64KB，應付海量小檔案應該ok 鐵馬冰河 扛不住。曾經嘗試將某客戶的海量小檔案環境 3億 1MB以下 遷移到某國內ceph公司產品上，檔案數目一多，效能是大問題。 海量是多大量？我就說說物件儲存...
Hadoop 是否適合海量遙感影像資料處理？
向磊 完全可以，但需要自定義inputformat來識別和讀取資料切片，結合GPU CUDA做大規模浮點運算，但是這個比較前沿，不夠穩定。 造輪子 韓冰 呂超 回答到其中一面，在這裡通過hadoop的應用特點，分析為什麼hadoop不適合海量遙感影像資料處理的原因。從儲存來說 提到的海量影像遙感資料...