这是一个创建于 2480 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个分析系统, 需要按照日期和一个 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
liprais 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