二十二 hugegraph 存在的一些性能问题

数据情况

因为存储了一些transaction的信息导致数据量在 2T，30亿的量级，在做一些基于 时间范围查询和一些统计类查询的时候存在较大的问题；

问题汇总

• 对于某个索引字段，求 max值 很难；hugegraph 的max 算子没有计算下推的，主要是通用框架考虑； 比如在cassandra中，这个字段为索引表的primary key，其实可以 select * from table order by primary key desc limit 1 就是 最大值；但是也仅仅是单机，如果是集群又会变得更难；分布式nosql 的统计类信息比较麻烦；
• Edge 的range_index 效率远远低于 vertex的range_index; 总的来说，g.E().has(p1, between(a,b)) 这种range查询很慢，主要是先去查询 索引表，然后根据边的 id 查询 g_oe 表。这个过程是 onebyone 的，也就是说索引表查回来1万条id，就要查1万次g_oe表，无法使用 in list 查询，因为 g_oe的表设计并没有一个 edge id，而是一个 复合 primary key，无法做inlist 查询；
  为了处理这个问题，尽量在设计schema 要考虑结构，比如 类似的数据存到 虚拟 vertex节点中，他可以使用 inList 回查的；
  另外可以利用一些冗余数据，处理回查的情况，但是要牺牲存储空间；
• order by 算子没有下推，其实一些索引的查询是支持orderby的，但是目前cassandra 是拉回到内存计算，没有下推；一定要使用的话，可以自己写程序直接查cassandra 底层表；
• range index 处理不了 string+ long 这样的多个字段的分区， 比如我 address， 和 时间戳； 一个address 下面可能有几百万的transction，所以最好是 address + 时间戳的 双 partition；hugegraph目前无法处理，这个只能自己 增强，或者在额外的表里面做；
• g.V(id).outE().has('a','b'), 执行计划 中 outE 是不做index 查询的，transaction很多的情况下很麻烦；
• range(0,1000)查询的时候，是把取上线，所以越到后面会越慢；
• g.V().hasId().out().hasId() 类似这种pattern也没有优化的；

遗留问题，大数据存储，分布式下，如何做count，max，min这些查询？

有 超级节点如何处理

• 需要按照某种逻辑划分，比如 按照timestamp（min,hour, day）, adress; 多个健值需要能够联合做 partitionkey；
• 在transaction 类的数据中，使用 time_range 做索引是很正常的；
• 交易的图太大了，在schema的设计上必须要按照常用的应用场景来做优化；

cassandra 索引效率其实很低

• 比如建立了一个block_number 的索引，如果有1000条记录，需要回查1000次。由于分布式设计，原则上1000次就是要计算1000词partitionkey，做一千次磁盘；所以一般都是为查询建立表； 比如 把blocknumber做成 paritionkey； 查询 block_number=11 的数据，我们可以 去查 10-20之间的数据块，然后再内存中过滤， 一定要减少 磁盘读写的次数