版本3.2
出现这个异常，求解
1 个赞
先看下文档中的注意事项
无起点线索的查询是依赖索引，或者可以点、边直接 limit 下推的。
你可以之后了解一下索引的概念。
这里要么加一个 WHERE id(a) == “player100” 这样条件
要么改成可以下推的模式 match ()-[e]->() return e limit 3
我觉得，这种设计从一开始就是不合理的，nebula团队需要做的是尽可能多优化，改变这种不合理，而不是找各种理由解释这种不合理设计的原因
3 个赞
一方面是查询必须依赖索引，一方面是建议慎用索引，索引最多可能损失90%的性能，这种其实是自相矛盾的
3 个赞
NebulaGraph 里的一些当前取舍准则是追求分布式大规模场景下可控的性能，所以要求用户明确在特定的查询模式下显式创建索引（假设用户知道自己会涉及那些属性反查点边条件），并且禁止了不能下推的全扫描。
这样的结果就是给用户（相比于其他选择设计的系统情况下）带来了思考的负担，在写查询、规划索引的时候要做额外的决定，这里我们确实可以反思一下，比如是否可以选择支持配置允许全扫描，在测试部署的配置里默认打开（给出warning），生产系统里关闭，或者从其他方面考虑让用户少一些这样的困惑，有时候第一次使用想查出来数据都很困难，甚至每次写查询都要一点点试哪一个可以查哪一个不行。
这个文章有介绍详细的一些信息，其实解决这个困惑的原则就是文中的几条，不过我承认确实对用户来说是额外的负担。
cc @MuYi
1 个赞
我觉得你说的对
2 个赞
这种感觉不太习惯，感觉这种约束性非常强，从图的schema设计到查询，强调了高性能，大数据量，而忽略了图本身，给我的感觉倒像是关系型数据库强转成了图数据结构。不像neo4j,tugraph等那样自由。图数据强调的是关系，广义的网络语义。
1 个赞
等下，这个怎么说？
索引是读和写的权衡：
- 如果你场景主要是读，那肯定得加索引呀。
- 如果大量的写，索引的存在肯定会拖慢插入性能。
这在哪个数据库都一样。
可能就是指：
- 不允许在查询时不指定起点（通过 where 语句）。
- 没有索引默认不能使用 match。
有太多假设。
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。