- Neo4j是使用admin-import工具导入的，因为亿级别的数据使用LOAD CSV命令是根本无法导入的。
- 想问一下你这边对Neo4j有做过什么操作么，Neo4j的版本是否可以提供一下？neo4j的试验是我做的，对于结果数据我有怀疑过，但是多次试验确实结果就是如此。（可见以上mason的部分截图），我不知道是不是neo4j我的使用有不熟悉的地方。
1 个赞
那可否提供正确的写法呢，这个不是我做的，但是应该不至于有这么明显的错误，你实际测试是如何测试的呢？有没有漏建索引或者数据id编码有误呢？
1 个赞
感谢回复。
g.V().has(‘vid’,‘atrr’,‘1111’).bothE().otherV().aggregate(‘x’)是把第一个节点的一度关系好友找到，并聚集在x变量中。紧跟着aggregate(‘x’).has(‘vid’,‘atrr’,‘2222’)表示从x中找到这个实体，而不是全图中找。即，测试的命令变成了从第一个实体（vid:1111）的一度好友中找第二个实体(vid:2222)，然后以找到的第二个实体出发，再找一度关系，后续的where判断就失去了意义。
我认为正确的查找为：
g.V().has(‘vid’,‘atrr’,‘1111’).bothE().otherV().as(‘x’).bothE().otherV().where(has(‘vid’,‘atrr’,‘2222’)).select(‘x’)
这里假设好友关系是不知道方向的，所以用了bothE()，实际中可以用outE()、inE()来替代。
我也是刚接触HugeGraph，如有理解错误的地方，欢迎指正探讨。
你好，想问下，为什么边的数量少的时候nebula比neo4j导入数据的速度会慢呢
因为Nebula导入在这里用的是SST导入，这个导入流程是建立在Spark上面的，需要启动Spark、向Yarn申请executor等操作，所以在小批量数据导入的时候，这个资源申请的流程过长，从而导致导入性能的下降，因此只有在大批量的导入场景下，Nebula SST导入模式才有明显的性能优势。
4 个赞
了解了，sst导入模式可以在哪里找到讲解呢，我怎么找不到。有没有链接。另外neo4j使用的导入模式是什么呢，有没有哪里有讲解。感谢
您好，文档里有讲解
另外，我之前分享了一个单机手动试玩 exchange-SST 的文章，其中的 nebula,spark,exchange 都是在容器里跑起来，也可以作为上手参考
1 个赞
感谢，请问如果用nebula-importer的话会不会更快一点呢
SST 的场景是超大量的批量导入哈（比如微信团队在使用 nebula exchange sst），本质上是用外部的算力并行去做数据的排序，换取批量情况下的导入效率。
非 SST 的情况，无论是 exchange serverwriter(sst 是 exchange filerwriter)，还是 nebula-importer，本质上是通过 nGQL 写语句，理论的写入速度上限是不如 SST 的，不过如果能满足的话，则越轻量越方便。
exchange serverwriter 的优势在于写入的客户端可以利用超过单机的资源去做导入，而 nebula-importer 只能在一个 server 上执行，所以如果 importer 的导入速度如果已经能够满足的话，一般就不用考虑 exchange 了（除非已经有 spark 的基础设施，但是 SST 无论如何都不是首选）。
nebula 的写入性能是非常优秀的，所以很多场景下 importer 就已经能够满足了，而 SST 只是生态里提供的超大规模短时间导入的一个工具选项哈~
这里有我总结的导入工具选择流程图和介绍视频: Nebula Graph Data Import Options - siwei.io
1 个赞
讲解的太好了，非常感谢大佬！
1 个赞
老哥总结的非常好，给你点个赞~
1 个赞