上面fetch出来有数据的player.name 是 “name10000000”， 下面LOOKUP ON查询的player.name是“name100000”,请先确认下name为“name100000”的数据是否真实存在哈
我测试了下，在建立索引的情况下，查询真实存在的数据时是可以通过lookup on查询出来的，查询不存在的数据时，返回Execution succeeded (Time spent: 600/1008 us)
可以查询出来了， 请问一下可以遍历这个vertex tag下的所有的顶点数据不带查询条件么？ 还有就是使用 类似sql的 In 条件怎么用呢？
- 目前好像还不可以遍历某tag或者edge的所有数据
- nebula的比较运算符udf_is_in() 类似sql的in，具体应用示例在这 https://docs.nebula-graph.com.cn/manual-CN/2.query-language/2.functions-and-operators/comparison-functions-and-operators/
udf_is_in() 第一个参数为要比较的值。
nebula> YIELD udf_is_in(1,0,1,2);
======================
| udf_is_in(1,0,1,2) |
======================
| true |
----------------------
nebula> GO FROM 100 OVER follow WHERE udf_is_in($$.player.name, "Tony Parker"); /*由于udf_is_in 后面可能变更，所以该示例可能失效。*/
===============
| follow._dst |
===============
| 101 |
---------------
nebula> GO FROM 100 OVER follow YIELD follow._dst AS id | GO FROM $-.id OVER follow WHERE udf_is_in($-.id, 102, 102 + 1);
===============
| follow._dst |
===============
| 100 |
---------------
| 101 |
---------------
批量插入单线程模式下， nebula性能可达到arangodb 5~6倍。
单条插入： arangodb(1000~1250条/s) nebula （550条/s）
统计查询1000w耗时: arangodb（2~3s）nebula(9~12s， 已建索引)
分页查询1000w耗时， 200条/页: arangodb（2~3s）nebula(9~12s， 已建索引)
条件查询：arangodb(6~7s， 未使用索引), nebula(9~12s， 已建索引)
我想问下两个使用的存储引擎都是rocksdb， 为啥性能差别这么多呀，是我自己测试的方式有问题么？
上边的统计查询，使用索引时的查询语句是什么？
LOOKUP ON player where player.age > 0 | yield count(*) ， 忘了是通过管道链接的还是不用加管道就可以,总数据量在1000W。
还有就是单条插入的性能和arangodb也差了一倍，这个有点差异。
批量性能吊打arangodb但是批量的场景还是比较少的呀。
集群架构是什么样的？有几个storage节点？
另外单条插入和批量插入的性能对比，对于nebula来说都是走的同一套逻辑。
单机默认配置，无任何修改。
我知道走的同一套逻辑，批量插入直接就是拼语句么，所以相比arangodb那种需要序列化并解析对象列表方式来说要快的多。
请问下，这里的时间是除法吗。 就是花了600除以1008us 