1 nebula没有采用双向邻接表的存储方式，vertex和edge都是对应的底层的一行数据，为什么导入点和导入边的速度差这么多呢？单位时间内导入点的速度远远大于边的速度。
2 现在有三台机器 ip1,ip2,ip3，ip1做meta和storage, ip2 ip3 做 graph和storage，每台机子的三个config到底应该怎么设置？如果按这个设置，一个space的数据会分到三台机子上，ip2,ip3组成HA查询集群，我的理解对吗？
- 导入边时 storage会写正向边和方向边，对应底层sst文件有两行数据。 点和边所带的属性类型和数量也会影响导入速度。
ps：你是用什么工具导入的，导入时边和点的并发度和batch量保持一致的吧。 - 关于配置：
ip1机器 配置meta 和storage，
ip2 和ip3机器配置graph和storage，具体配置内容参考文档 Meta服务配置 - Nebula Graph Database 内核手册
space的数据会分到三个机器上的。
- 一个逻辑上的edge 是两个kv，而且这 两个kv在两个不同的partition
- 一般写边的时候，是批量写。 会出现同一个瞬间，是在写同一个起点开始的逻辑边。 这意味着压力瞬间是在同一个partition上的。
我是自己写的spark程序foreachpartition，每个partition一个syncconnection导入。我知道edge占用两行，用的graph500的数据，点边都没有属性，只有id。单个edge的时间远大于两个vertex。batchSize是100-200，是统一的
ip1
meta：meta ip1 local ip1
storage: meta ip1 local ip1
ip2(ip3)
graph: meta ip1 local ip2(ip3)
storage:meta ip1 local ip2(ip3)
这样子对吗？
是这样配置 
边数据我读出来做了2d hash，不是相同 srcId在一个partition里面连着写入的
一个点的邻边，一般都是几十个吧？
这意味着，同一个src开始的 edge key,会有几十个。
和你是否hash没有关系。
我知道你意思，比如边1-2,1-3,1-4，写入时候短时间内 vid=1的partition会成为热点嘛，所以速度慢。
我意思是 我现在做了hash，不是只以srcId做rdd分区，1-2，1-3，1-4在写入时点上不是连续的，并不会让vid=1的partition变成写入热点。
OK。
你测试点和边的时延或者吞吐量差多少？