这是一个创建于 3012 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个分析系统, 需要按照日期和一个 index 来查询所有符合条件的 id. 再去重,然后通过 ID 来拿相对的属性.
现有的架构是用 Hbase 来存储数据, 以date_index 为 rowkey, id 作为 qualifier, 查询直接拿 key 去 get, 简单测试发现取得数据的速度达不到要求. 获取两条数据花费接近两分钟... 实际查询需要获取上百条...
再之前的做法是以id为 rowkey, date_index 作为 qualifier 然后使用 Hbase 的 ColumnPrefixFilter 来过滤再取所有的 rowkey, 但是查 doc 发现 filter 会做全表扫描... 鉴于数据量每天的增长大概在百万级, 这个性能会随着运行时间越来越差...
现在的想法是用 ElasticSearch 来做, 直接把属性也索引进去, 求问有没有什么更好的做法...
20 条回复 2017-07-13 19:22:32 +08:00
 | 1 F281M6Dh8DXpD1g2 2017-07-12 16:01:28 +08:00  1 为啥不预先算好 |
 | 2 apoclast 2017-07-12 16:11:02 +08:00 1 elasticsearch 可以, 不过亿级略微困难 |
 | 3 sli OP @liprais 因为查询的这个日期是可选的, 没法预测时间范围...也想过全都提前算好, 把所有可能的时间范围都算一遍...到后期的话, 这个量也是起飞的... |
 | 5 server 2017-07-12 16:23:56 +08:00 1 没有耕坏的地，只有累死的牛，es 还怕这个！！！ |
 | 6 zhmin 2017-07-12 18:58:54 +08:00 via iPhone 1 我觉得是你的 rowkey 没设计好，可以试试用日期和 index 拼接起来，构建 rowkey。亿级的数量，对于 hbase 完全扛得住 |
 | 7 funky 2017-07-12 19:21:56 +08:00 1 上 OLAP kylin |
 | 8 rrfeng 2017-07-12 19:42:05 +08:00 1 两条数据是只 date 范围加 index 联合获取到的 ID 去重之后只有 2 条？ 这个关键在于 index 的区分度啊，不是什么系统能解决的 另外觉得这个 HBase 比 ES 靠谱。 |
| 9 rrfeng 2017-07-12 19:42:15 +08:00 加机器… |
| 10 sli OP @zhmin 现在 rowkey 就是 date 加 index，然后把 id 作为列名，试了下这么取的话，挺慢的...而且 hbase 的 sharding 是按行的，这百万个列全在一个 region，取的时候可能没有真的利用到分布式存储，取连续的行的时候，压力全在一台机子上... |
| 11 sli OP @rrfeng 是按照 date 加 index 这种 rowkey 的方式取了两行，两个一百万列的行，然后取列名去重之后大概还是百万个 ID... |
 | 13 MasterC 2017-07-12 20:29:28 +08:00 impala |
| 17 sli OP @zhmin 是 hbase 取数据慢，spark 可能不太适合这个，hbase 里存的算是对于源数据经过计算之后的中间结果，是在中间结果上做 aggregation 然后展示，要求尽可能实时展示结果...数据量小的话没问题，百万条数据的话 Hbase 就不太能胜任了... |
 | 18 slixurd 2017-07-12 23:47:32 +08:00 1 ElasticSearch 能做到千万级数据 TP99 几十毫秒的性能 不过也取决于磁盘速度,最好能上 SSD/内存 |
 | 20 hienchu 2017-07-13 19:22:32 +08:00 via iPhone 如果是对属性做统计的话，es 在亿级别完全没问题。 |
Select Language