问下nebula分页查询tag总数怎么优化，总数据300多万，加了索引，用这个LOOKUP ON v:nebula_8001_5E08 YIELD id(vertex) | YIELD COUNT(*) AS Player_Count;查询需要40秒，用MATCH (v:nebula_8001_5E08) where v.nebula_8001_5E08.nebulaprojectId == “HUMNAOPERATION” return count(v) as n; 语法查询需要60多秒，需要分页查询，必须知道总数
可以用 limit 来做:
如 LOOKUP ON nebula_8001_5E08 YIELD id(vertex) | YIELD COUNT(*) AS Player_Count; ｜ LIMIT 10
limit 同时支持 offset, 文档: LIMIT and SKIP - Nebula Graph Database 手册
可以先通过 stats 获得该 tag 下点的总数, 然后通过上述方法做分页查询
1 个赞
这个语法查询300万慢了，不想用show stats，因为要实时分页查询，还会带条件分页
你截图的查询可以用上面的方法优化, 但是带过滤条件的用不了, 目前没有优化
纠正下上面的恢复, 如果是查数据的比如
LOOKUP ON nebula_8001_5E08 YIELD nebula_8001_5E08.prop as property,
这样的语句可以通过分页优化效率: LOOKUP ON nebula_8001_5E08 YIELD nebula_8001_5E08.prop as property | LIMIT 0, 100,
可以参照这个帖子:lookup on语句支持分页查询吗 - #8，来自 donghuayanyun
对 count 的话没有办法通过分页优化
我就count优化，其他的语句我都写好了，分页的语句我用的是limit和skip
问下count这块后面会优化么？
目前还没解决，你那边有什么好方式么，后面发现是match + limit 下推查询很慢，count大概40s左右
显然是no 
，数据模型构建已经没办法在细化了，查询优化也到头了，最后查询在预期内仍然无法返回。
唉。只能等nebula官方去做match +limit 和count 优化了，底层才可能解决，业务方面我觉得入点数据和边数据已经很快，600万点1个小时就导入完成了，300万边大概半个小时，就是分页查询那块确实没法优化了
我想请问一下，在其他使用场景上有瓶颈吗，我们在其他日常的查询中都在预期，但是在全路径查询时很难做到预期返回，一般会涉及到10跳以上到未知，类似图探索，你们有这种场景吗
有的，我们全路径查询使用场景有5跳的，查询返回同样很慢，然后是apoc的merge实现没有，后面是自己实现归一消歧的，效果感觉也不好
类似于这种语法，数据量一大就查询很慢很慢，MATCH p=(v:nebula_5B66_751F)-[e*0…5]->(v2) RETURN p ,size(relationships(p)) as age ORDER BY age desc limit 1;
是呢，我们是有一个180万点，450万边的子图，然后在这个范围内做一个点到另一个约束点的查询，跳数无上限，但是不会超过20，查得机器宕机了。
1 个赞
我是1100万点无条件加个limit 卡住 
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。