elasticseach 和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自成体系,维护起来稍微好点;当然这个是相对的,绝对来说都不会容易。比如新功能开发,比如成本控制等等。。。

你可能感兴趣的:(hbase)