Performance Neo4j按射程性能匹配

我有以下设置：

大约150万个

IpRangeBlock

类型的节点，由

start

和

end

属性组成-它们都是Long类型。

start

属性上有一个索引

然后我要做的是找到一个包含给定IP的范围。因此，例如，对于ip

0.0.0.2

，我将其转换为long，然后在所有节点上执行比较

n.start=2

我运行的密码查询如下所示：

MATCH (n:IpRangeBlock) WHERE n.start <= {ip} AND n.end >= {ip} RETURN n LIMIT 1

MATCH（n:IpRangeBlock），其中n.start={ip}返回n LIMIT 1

---

一切都很好，不过正如我提到的，对于我拥有的150万个节点，Neo4j可能需要20秒才能找到匹配范围。我的问题是，有没有办法加快这个操作，或者是我的数据库设计中的错误

好的，我尝试缓存节点引用并在应用程序端执行比较。正如您所预料的，拉取这么多节点需要时间

所以我尝试了另一种方法——我检查了我们的数据集，结果发现所有ip范围的

start

和

end

属性都以相同的第一个八位字节开始。我使用这些八位组作为分组节点，以快速缩小可能IP范围的子集。这很有效，因为我们的数据集实际上分布在所有ip范围内。现在，不是比较100k节点的属性，而是每个查询“只”进行大约8-10k的比较

---

我知道这不是一个完美的方法，但对我来说很有效。我是从。

得到这个想法的。您使用的是哪个版本？我认为范围查询的索引已经在2.3中添加了。特别是如果您对属性使用普通的精确索引，那么范围查询将使用它。虽然这可能只是形式

value

。可能不是

n.prop1

。但是一定要确保你有一个索引，然后查看你的查询是否符合索引。2.3.1-当我对相关查询运行

PROFILE

时，我看到它在执行计划的第一阶段调用

NodeIndexSeekByRange

。你的

IpRangeBlock

节点上有很多属性吗？归还了多少？它可能会花费时间返回dataNope，它只有

开始

和

结束

+每个关系大约5个关系。我总是使用LIMIT选项来运行它，因此，如果我是正确的，它应该只抓取一个节点。我应该在这两个属性上创建索引吗？它只设置在

开始

一个按钮上。