海量日志数据存储用 elasticsearch 和 hbase 哪个好？
每天 5G 的流水日志（也许标题不应该写海量。。。），不知道怎么存储比较好，目前能想到的方案就是 elasticsearch 和 hbase ，不知道…显示全部
关注者
196
被浏览
30,731
关注问题写回答
​4 条评论
​分享
​邀请回答
​
19 个回答
默认排序​
知乎用户
知乎用户
大数据爱好者、程序员
8 人赞同了该回答
单纯从技术的角度来说其实没有好坏之分，技术选型需要结合实际的业务场景来定。从问题描述上看大致可以从几个方面来考虑：

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来实现字段的扩展

发布于 2017-05-26
8
​1 条评论
​分享
​收藏​感谢
杨东东
杨东东
阿里云表格存储，更好的分布式NoSQL数据库！求分布式SQL引擎研发
11 人赞同了该回答
从基本功能来说这两个确实有相似性，但是根据业务需求不同，我觉得有几点可以考虑：
1. 查询复杂度：HBase支持简单的行或者range查询，比如给一个PK查该行的数据，或者给一个begin/end查这个范围的数据，如果想完成更复杂的功能就不太容易。而ES支持的查询比较丰富，或者说这些查询都带有一点复杂计算的味道了。比如你有个论坛，你想查帖子里面是否包含敏感词，如果采用HBase就比较麻烦，使用HBase你可以将帖子存进来、读出去，但是要查内容里面的东西，只能一点点过滤；而ES是可以比较方便的帮助你完成这个功能的；
2. 数据量：按道理说两者都是支持海量数据的，但是据我个人感觉，HBase可能更容易支持更多的数据，因为其一开始设计就是解决海量问题的；而ES是后来慢慢增强其存储扩展性的；那么也就是说，HBase上手起来扩展性不太会阻碍你使用；ES可能要多费点劲。当然，听说也有人写了ES基于Azure或者S3的存储插件，但是稳定性不知道如何；
3. 剩下的就是比较远的考虑，比如维护性，HBase基于Hadoop那一套，组件多，维护起来代价也不低，而ES自成体系，维护起来稍微好点；当然这个是相对的，绝对来说都不会容易。比如新功能开发，比如成本控制等等。。。
发布于 2016-06-18
11
​1 条评论
​分享
​收藏​感谢
冰封
冰封
Java吸星大法、大数据武学、算法内功、技术狂魔
1 人赞同了该回答
 elasticsearch 和 hbase 存储机制是不一样，

hbase是Key vlaue的形式，大批量拉取数据，存储海量的数据性能必须大于elasticsearch，但是搜索列没有优势。

elasticsearch是基于lucene，优点是搜索速度快，方便建立索引，支持全文检索，但是数据上百亿的情况下，干不过hbase。

两者都有好处，而且使用场景不一样，如果题主喜欢elasticsearch，说实话你一天2G的数据，我觉得没有问题，关键看你的业务逻辑如何处理，数据要存储多久时间，全文搜索多久的数据，划分好，过期的数据定时清除，保持索引库的高可用即可.

发布于 2017-02-12
1
​添加评论
​分享
​收藏​感谢
知乎用户
知乎用户
打代码
5 人赞同了该回答
这两个不应该拿来做对比。看一下各自的介绍：
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）
一个是搜索引擎，一个是数据库。
在分布式环境中，两者得到广泛使用，但发挥的作用是不一样的。具体要怎么使用怎么配合，要看实际业务了。
编辑于 2017-02-21
5
​7 条评论
​分享
​收藏​感谢
木洛
木洛
大数据领域学习者，NoSQL解决方案专家，阿里云表格存储研发
5 人赞同了该回答
1. HBase是schema free的，加字段完全没问题
2. 用ES存日志数据，成本会很高
3. 偏分析还是偏存储？还是两者结合？应用场景是什么?
4. 推荐的架构：ES给日志建索引（看业务是否需要），日志原始内容存HBase。
发布于 2016-05-07
5
​2 条评论
​分享
​收藏​感谢
Reid Chan
Reid Chan
知乎真的不好玩，拜拜。
3 人赞同了该回答
HBase结构化………

呵

不能加字段 不会用而已ho

选个你会用的架构
发布于 2016-03-11
3
​1 条评论
​分享
​收藏​感谢
Golion
Golion
写代码 画画 ACG TRPG
12 人赞同了该回答
ElasticSearch + Logstash + Kibana
本质上是个搜索引擎，可视化不错，适合简单、实时的场景。不应作为一个存储方案，因为数据很难取，只能用ES来搜。

Hbase + Hadoop
海量数据、大计算量，适合持久存数据，适合做深度的数据分析。

如果题主要做实时、动态的计数，则推荐ES。
如果题主要跑些月报表什么的，则推荐Hbase。
编辑于 2016-03-29
12
​2 条评论
​分享
​收藏​感谢
知乎用户
知乎用户
十年饮冰，难凉热血 EX Automation ENG
3 人赞同了该回答
才5gb的日志，对es技术栈来说太小意思了，你可以查找一下携程网的技术slide 《TB级日志的秒级检索》 Elasticsearch logstsh kiabana是开源日志检索系统的主流技术，存大数据一点问题没有，有的问题就是贵公司舍不舍得拨款那么多机器来存数据
发布于 2016-05-29
3
​添加评论
​分享
​收藏​感谢
李卓然
李卓然
努力成为一名优秀的码农
2 人赞同了该回答
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的朋友贴一贴配置和数据量，互相交流

发布于 2017-05-27
2
​添加评论
​分享
​收藏​感谢
三线城市五流码农
三线城市五流码农
2 人赞同了该回答
这两个功能有重叠。
本质不一样
如果知识简单的存储  读取。就用es好了
如果将来业务会偏向复杂那么
推荐使用
推荐用ES给日志建索引，日志原始内容存HBase。这样数据搜索效率达到最高。
发布于 2016-05-26
2
​1 条评论
​分享
​收藏​感谢
YING zz
YING zz
语言的瘾者
2 人赞同了该回答
hbase面向列非常好加字段的！
es适合搜索和分析小规模数据，速度快过hbase。
hbase稳定可靠，而且可以通过mr spark等大批量拉取数据。
不过你这种5g的数据扔哪没啥区别，开心就好。
编辑于 2016-03-11
2
​4 条评论
​分享
​收藏​感谢
face hog
face hog
oh, fuck me
1 人赞同了该回答
hbase存多读少，不适合高并发查询，适合存数据；
es是全文检索，适合日志分析日志统计之类。
ps：hbase是面向列存储的nosql数据库，怎么就成了结构化的了？
编辑于 2016-04-01
1
​添加评论
​分享
​收藏​感谢
日志易
日志易
日志易，日志分析更容易
ELK相关的几个问题是否关注：

1、运维管理方不方便。ELK是三个独立的系统，没有统一的部署、管理工具，需要分别部署及管理这三套系统。

2、多部门协调办公吗，ELK没有用户认证及权限管理。

3、Elasticsearch存在严重的安全漏洞，没经验的用户很可能中招，被黑客入侵。

4、······

全球500亿条数据被 Elasticsearch 勒索者删除，中国受灾排第二

每天 5G 的数据量可以轻松的现在日志易

编辑于 2017-12-21
0
​添加评论
​分享
​收藏​感谢
Jerry
Jerry
程序员
我觉得elasticsearch可能更有优势点，首先日志多种多样，结构不统一，es这种非结构化存储更方便灵活。再者，es的查询速度非常快，如果你的日志是实时打入的，那么利用es的可视化工具kibana，利用luence语法，可以筛选出相应的日志信息，特别是对于多台机器，统一日志都在es中，不用到指定机器查询。
发布于 2017-09-06
0
​2 条评论
​分享
​收藏​感谢
smartweb
smartweb
横跨人工智能与金融的杀马特韦伯
看存储的目的，仅仅为了保存，hbase，如果批量任务 hbase 如果实时查询elasticsearch
发布于 2017-06-01
0
​添加评论
​分享
​收藏​感谢
知乎用户
知乎用户
起来！不愿做奴隶的人们
如果仅仅是存储，稍有分析需求，或分析需求实时性要求不高，可以用hbase。

反之用es，太方便了

编辑于 2017-04-22
0
​添加评论
​分享
​收藏​感谢
陈阿福说
陈阿福说
数据分析师
5g es完全没问题，同时配套的web之类的也有了。会节省很多时间。
发布于 2016-05-24
0
​添加评论
​分享
​收藏​感谢
金色木叶枫
金色木叶枫
喜欢开源，爱好开源
选择elasticsearch  还是hbase主要是取决于你的业务场景和需求，如何通过日志进行一些搜索和分析统计工作可以考虑使用elasticsearch,logstash,kibana可视化组合棒棒的，每日5GB这个不是什么大的数据量
发布于 2016-03-26
0
​添加评论
​分享
​收藏​感谢
xuguokun
xuguokun
IT
我个人觉得，es注重的还是检索，hbase擅长的是读写操作，所以还需要看见你的应用场景
发布于 2016-03-21
0
​1 条评论
​分享
​收藏​感谢