在 Neo4j 中模拟分区

Question

我试图用以下两个查询来测试这个以模拟 Neo4j (v3.1) 中的分区：

Q1: MATCH (a:USER { UID:362})-[:FRIEND]->(b) WHERE b.PARTITION=1 RETURN COUNT(b) Q2: MATCH (a:USER { UID:362})-[:FRIEND]->(b) WHERE b:P1 RETURN COUNT(b)

我希望（也讨论过here）Q2 会更快，因为它只会检索P1 标签，而Q1 需要在过滤之前检索所有节点。事实证明，Q1 的速度要快得多，当我更改查询以遍历更深的 [:FRIEND*1..5] 时，这一点变得更加明显。

编辑：UID 上有索引，PARTITION 上没有索引。

使用嵌入式 Neo4j 的查询计划如下（由于某种原因不显示 DBhits）。

Q1

+-------------------+----------------+------------------+-----------------------------+
| Operator          | Estimated Rows | Variables        | Other                       |
+-------------------+----------------+------------------+-----------------------------+
| +ProduceResults   |            191 | COUNT(b)         | COUNT(b)                    |
| |                 +----------------+------------------+-----------------------------+
| +EagerAggregation |            191 | COUNT(b)         |                             |
| |                 +----------------+------------------+-----------------------------+
| +Filter           |          36341 | anon[33], a, b   | b.PARTITION == {  AUTOINT1} |
| |                 +----------------+------------------+-----------------------------+
| +Expand(All)      |         363412 | anon[33], b -- a | (a)-[:FRIEND]->(b)          |
| |                 +----------------+------------------+-----------------------------+
| +Filter           |         105719 | a                | a.UID == {  AUTOINT0}       |
| |                 +----------------+------------------+-----------------------------+
| +NodeByLabelScan  |        1057194 | a                | :USER                       |
+-------------------+----------------+------------------+-----------------------------+

Total database accesses: ?

Q2

+-------------------+----------------+------------------+----------------------------------+
| Operator          | Estimated Rows | Variables        | Other                            |
+-------------------+----------------+------------------+----------------------------------+
| +ProduceResults   |            214 | COUNT(b)         | COUNT(b)                         |
| |                 +----------------+------------------+----------------------------------+
| +EagerAggregation |            214 | COUNT(b)         |                                  |
| |                 +----------------+------------------+----------------------------------+
| +Filter           |          45909 | anon[33], a, b   | a:USER AND a.UID == {  AUTOINT0} |
| |                 +----------------+------------------+----------------------------------+
| +Expand(All)      |         459085 | anon[33], a -- b | (b)<-[:FRIEND]-(a)               |
| |                 +----------------+------------------+----------------------------------+
| +NodeByLabelScan  |         134181 | b                | :P1                              |
+-------------------+----------------+------------------+----------------------------------+

Total database accesses: ?

对这背后的原因有什么想法吗？

Answer 1

先观察几个：

1. 它可能没有什么不同（考虑到查询计划），但有没有理由你不把 Q2 写成MATCH (a:USER { UID:362})-[:FRIEND]->(b:P1) RETURN COUNT(b) ?
2. 用户的 uid 没有索引或约束？

区别似乎是 Q1 和 Q2 选择了不同的切入点。 Q1 选择 User，Q2 选择 P1，这似乎更有效。不过，我不会（考虑到计数）期望查询时间会有巨大差异。 Q1 的一个副作用是，您可能会通过对 User 的扫描将所有内容加载到内存中。

如果您真的想加快速度，请在用户（UID）上放置一个索引。结合 P1 标签，应该会真正降低点击次数。

希望这会有所帮助。

问候， 汤姆