Neo4j 索引（使用 lucene）如何在后台工作？答案

【问题标题】：How does Neo4j indexing (using lucene) work under the hood?Neo4j 索引（使用 lucene）如何在后台工作？
【发布时间】：2014-10-29 17:00:03
【问题描述】：

关于 Neo4j 中的 lucene 索引以及在查询和遍历期间如何使用它们的几个问题。基本上，关系存储在磁盘上的方式（链表），在我看来，任何图形遍历都需要顺序访问节点的所有关系——不确定在这种情况下如何使用索引。更具体地说：

1）当节点属性被索引时，它如何用于诸如“我的所有女性朋友的朋友”（性别被索引）之类的查询。我看到使用索引的唯一方法是首先找到朋友的所有朋友，然后向 lucene 提交查询以获取所有女性。它是否比仅在内存中进行比较更快？

2) 当关系属性被索引时。由于关系存储在链表中，因此如果不按顺序遍历列表，就不可能获得节点的关系子集。我想我们总是可以使用 node_ids 来索引关系，但这似乎很愚蠢——我们最终将邻接列表存储在 lucene 和 Neo4J 中

【问题讨论】：

【解决方案1】：

索引不用于遍历。

它们仅用于在图表中找到您的起点。

根据关系类型和方向，您只能从节点遍历关系的子集。

对于您的查询 1，您不需要关于性别的索引，因为它会返回图表中大约 50% 的人。但是您会使用索引进行初始用户查找（我）

在 :User(name) 上创建索引；

MATCH (m:User {name:"Me"})-[:FRIEND]->(other:User) WHERE other.gender = "女性" 返回其他；

2) 是的，你是对的。

您可以这样做，但只有当您拥有大量关系（数百万）并且想要访问其中的一小部分时才需要这样做。

因此，如果这是您的用例，关系索引可能会有所帮助。关系实际上是用节点 ID 和关系属性索引的

【讨论】：

谢谢迈克尔！只是如果我们有 10 种类型的关系，遍历所有类型只是为了找到一种类型听起来效率不高。但我想性能仍然是恒定的（节点/关系的数量越来越多），而不是日志（n）的 RDBMS B-树
就我而言，我想找到所有符合特定条件（性别、年龄、距离等）的 3 级朋友。根据网络大小，遍历将返回 1000（20 个朋友/用户）到 100,000+（50+ 个朋友/用户）匹配。从 neo4J 检索好友列表并在其他地方（Lucene 甚至具有适当索引的 RDBMS）执行过滤是否更有意义？