上周简单的手动测了ldbc的short query，对比了neo4j和nebula，发现nebula效果不太好https://discuss.nebula-graph.com.cn/t/topic/12098。
nebula调优
后来对nebula进行了一些调优
- storage 打开 query concurrency
- storage block cache设置为64G
- 导数后进行手动compact
测试配置
这周对nebula和neo4j继续对比测试了ldbc的complex query，对结果有一些疑问，想拿来讨论一下
-
测试数据集：LDBC SNB interactive SF100（100G）
-
测试平台：单台服务器ubuntu20，512GB内存，多块ssd组成raid0容量13TB，处理器Intel(R) Xeon(R) Gold 5320 CPU @ 2.20GHz
-
测试系统：neo4j社区版4.4.17，nebula 3.3
-
cache配置：neo4j jvm heap 20G，page cache 64G。 nebula单个storaged，block cache 64G
-
ldbc driver使用：nebula：https://github.com/vesoft-inc/ldbc_snb_interactive_implementations/tree/nebula1.2.0/nebula 。neo4j：https://github.com/ldbc/ldbc_snb_interactive_impls/tree/v1-dev/cypher
-
ldbc driver配置： 测试线程=1，每一轮只测一类query，共测14轮，覆盖complex query 1~14。每一轮warmup操作数为0，测试操作数为10~100不等（因为有的query跑的特别慢），无short query和update
测试结果
neo4j数据导入后，数据存储大小134G，创建索引后总大小154G
nebula数据导入并创建索引，手动compaction后，125G
时间单位：秒
*query7 nebula是跑出了错误，没有进行重跑
根据结果可以发现，同一个query中neo4j基本上最大时间都高于nebula，但是在ic1，ic3，ic5，ic9，ic10，ic11中，neo4j的最小时间远低于nebula，同时平均时间也低于nebula，推测是neo4j的page cache效果比nebula的block cache更好。
还有一些比较奇怪的地方在于，nebula有几个query跑的远慢于neo4j，比如ic3，ic5，ic12等，还没有进行具体的分析
nebula的ic14特别快，但看到 https://github.com/vesoft-inc/ldbc_snb_interactive_implementations/tree/nebula1.2.0/nebula 中的readme里最下面的配置里ic10和14都设置为了false，是nebula对ic10和ic14的实现有什么问题吗？
请求社区大佬指导QAQ