情景：在我的项目中有一个超级节点，存在上千万条边，每个边的属性都是特异的，我想从这个超级节点出发，通过某一个属性值查找终点，通过match方法查找一个终点耗时大约为1s
问题：
1、属性的储存是列表式储存吗？还是类似与哈希表似的储存。
2、想达到上面的随机查找终点，有什么地方可以优化吗？
边上的属性默认是一个大的 blob 存在 k-v 的 value 上，从给定点探索边过程中，会在存储测按照条件全反序列化出来然后过滤掉不匹配的。
优化的点：
- 现在 MATCH 默认会多做一些事情，如果是这个一跳用 GO FROM 去查会更快一些
- 此外，其实在非定点探索的场景，通过条件反查定位点、边这种非图的情况下，可以优化的方式就是类似于关系型数据库那样索引属性列，当一种特定的情况，就是这个边上的这个属性能匹配出来的边的条件只会定位到你这个起点的边的时候，这个索引是能提速你这个场景的，因为这时候是按照属性列顺序存了一份数据，可以直接定位到那个边，但是如果这个属性值并不能精确过滤出这个起点的边，那就不划算了，具体方法是建立边上这个属性的索引，然后 LOOKUP 查。
因为我还在理解和尝试您说的内容，所以暂时还没有结论性的回复，其中“具体方法是建立边上这个属性的索引”，您说的应该是通过这种 CREATE TAG INDEX IF NOT EXISTS player_index_1 on player(name(10), age);方式为属性构建索引吧
edge index，不是 tag index，是边上的属性哈
索引是用来从所有的里边查起始的边、点的，正常来说你这个探索查询是和索引无关的，第二条只有很强的条件，比如边上的属性是一个 id 那种比较唯一的条件才可能刚好有帮助。
否则用第一个点，用 go，这样比 match 少了取对面点的操作
嗯嗯，您说的对，我复制错误了。另外，我明白您意思了，多谢您了
1 个赞
按您的方法我已经能更快的获得结果，但就像您说的这种更倾向与属性唯一的情况。目前的速度可能已经能够满足我的需求，但我还是有些贪心，所以看您能不能帮我继续改进
情况：
前面提到我有上千万条边的超级节点，边中的属性都是唯一的，所以按您说的构建索引后，能够通过属性快速获得指定的边。但现在我现在有多个这种超级节点，每个超级节点都有自己的特定编号，由于lookup不能指定边的一个顶点，所以输出了好几个边，
需求：能不能指定其中一个超级节点，然后使用lookup会更快
1 个赞
LOOKUP 是从属性出发去找点、边，是图上的一个反模式查询（因为它本质上是表结构，不是图结构）
所以应该只能是先 LOOKUP 再 pipeline 然后过滤掉不需要的起点的边哈。
只要涉及到了起点再出发，就是图探索，就和 LOOKUP 没关系了哈，除非 pipeline 前边是用于构造 LOOKUP 中的 WHERE 条件。
因为 LOOKUP 之中，key 是 prop，value 是 vid/edge id(src,dst,type,rank)
好奇你现在的方法是我说到的哪一条路？
是对边的属性构建了索引，“除非 pipeline 前边是用于构造 LOOKUP 中的 WHERE 条件”，这句话可能可以解决我的问题，GO FROM 274877906946 （这个就是超级节点）OVER xlb REVERSELY WHERE properties(edge).loc == 16138453 YIELD dst(edge)这种方法是我想要的结果，但现在是LOOKUP ON xlb WHERE xlb.loc == 16138453 YIELD dst(edge);所以怎么改进会比较好一些
16138453 有可能重新 model 成为一个点么？这样可以从 16138453 出发到 274…46，不需要边索引
重新model是什么意思啊 
懂您意思了，重新model的话会增加太多的点了，上千万条边，就要重新生成上千万个顶点了
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。