在多级自连接的图形式查询上改进Postgres性能(与Neo4j比较)

Abe*_*ker 10 sql postgresql neo4j

Neo4j在其营销中提出的一个主张是关系数据库不擅长做多级自联接查询:

在此输入图像描述

我发现代码库对应于索赔的书,并将其翻译成Postgres:

CREATE TABLE t_user (
  id bigserial PRIMARY KEY,
  name text NOT NULL
);

CREATE TABLE t_user_friend (
  id bigserial PRIMARY KEY,
  user_1 bigint NOT NULL REFERENCES t_user,
  user_2 bigint NOT NULL REFERENCES t_user
);

CREATE INDEX idx_user_friend_user_1 ON t_user_friend (user_1);
CREATE INDEX idx_user_friend_user_2 ON t_user_friend (user_2);

/* Create 1M users, each getting a random 10-character name */
INSERT INTO t_user (id, name)
  SELECT x.id, substr(md5(random()::text), 0, 10)
  FROM generate_series(1,1000000) AS x(id);

/* For each user, create 50 random friendships for a total of 50M friendship records */
INSERT INTO t_user_friend (user_1, user_2)
  SELECT g1.x AS user_1, (1 + (random() * 999999)) :: int AS user_2
  FROM generate_series(1, 1000000) as g1(x), generate_series(1, 50) as g2(y);
Run Code Online (Sandbox Code Playgroud)

这些是Neo4j正在比较的各种深度的查询:

/* Depth 2 */

SELECT
  COUNT(DISTINCT f2.user_2) AS cnt 
FROM
  t_user_friend f1 
  INNER JOIN
    t_user_friend f2 
    ON f1.user_2 = f2.user_1 
WHERE
  f1.user_1 = 1;

/* Depth 3 */

SELECT
  COUNT(DISTINCT f3.user_2) AS cnt 
FROM
  t_user_friend f1 
  INNER JOIN
    t_user_friend f2 
    ON f1.user_2 = f2.user_1 
  INNER JOIN
    t_user_friend f3 
    ON f2.user_2 = f3.user_1 
WHERE
  f1.user_1 = 1;

/* Depth 4 */

SELECT
  COUNT(DISTINCT f4.user_2) AS cnt 
FROM
  t_user_friend f1 
  INNER JOIN
    t_user_friend f2 
    ON f1.user_2 = f2.user_1 
  INNER JOIN
    t_user_friend f3 
    ON f2.user_2 = f3.user_1 
  INNER JOIN
    t_user_friend f4 
    ON f3.user_2 = f4.user_1 
WHERE
  f1.user_1 = 1;

/* Depth 5 */

SELECT
  COUNT(DISTINCT f5.user_2) AS cnt 
FROM
  t_user_friend f1 
  INNER JOIN
    t_user_friend f2 
    ON f1.user_2 = f2.user_1 
  INNER JOIN
    t_user_friend f3 
    ON f2.user_2 = f3.user_1 
  INNER JOIN
    t_user_friend f4 
    ON f3.user_2 = f4.user_1 
  INNER JOIN
    t_user_friend f5 
    ON f4.user_2 = f5.user_1 
WHERE
  f1.user_1 = 1;
Run Code Online (Sandbox Code Playgroud)

我几乎能够重现这本书声称的结果,对1M用户,50M友谊获得这些执行时间:

| Depth | Count(*) | Time (s) |
|-------|----------|----------|
| 2     | 2497     | 0.067    |
| 3     | 117301   | 0.118    |
| 4     | 997246   | 8.409    |
| 5     | 999999   | 214.56   |
Run Code Online (Sandbox Code Playgroud)

(这是深度5查询EXPLAIN ANALYZE)

我的问题是,有没有办法提高这些查询的性能,以达到或超过Neo4j在深度级别5的执行时间~2s?

我试过这个递归CTE:

WITH RECURSIVE chain(user_2, depth) AS (
  SELECT t.user_2, 1 as depth
  FROM t_user_friend t
  WHERE t.user_1 = 1
UNION
  SELECT t.user_2, c.depth + 1 as depth
  FROM t_user_friend t, chain c
  WHERE t.user_1 = c.user_2
  AND depth < 4
)
SELECT COUNT(*)
FROM (SELECT DISTINCT user_2 FROM chain) AS temp;
Run Code Online (Sandbox Code Playgroud)

然而它仍然很慢,深度4需要5s而深度5需要48s(EXPLAIN ANALYZE)

Vla*_*nov 7

我想从一开始就注意到,比较关系数据库和非关系数据库并不是类似的比较.

随着数据的更新,非关系数据库可能会维护一些额外的预先计算的结构.这使得更新速度稍慢并且需要更多磁盘空间.您使用的纯关系模式没有任何额外的内容,这使得更新尽可能快,并将磁盘使用率降至最低.

我将专注于使用给定模式可以完成的任务.


起初我会做一个复合索引

CREATE INDEX idx_user_friend_user_12 ON t_user_friend (user_1, user_2);
Run Code Online (Sandbox Code Playgroud)

一个这样的指数就足够了.

然后,我们知道总共只有1M用户,因此最终结果不能超过1M.

5级查询最终生成312.5M行(50*50*50*50*50).这不仅仅是最大可能的结果,这意味着有很多重复.

所以,我会尝试实现中间结果并在过程的早期消除重复.

我们知道Postgres实现了CTE,所以我试着用它.

像这样的东西:

WITH
CTE12
AS
(
    SELECT
        DISTINCT f2.user_2
    FROM
        t_user_friend f1 
        INNER JOIN t_user_friend f2 ON f1.user_2 = f2.user_1
    WHERE
        f1.user_1 = 1
)
,CTE3
AS
(
    SELECT
        DISTINCT f3.user_2
    FROM
        CTE12
        INNER JOIN t_user_friend f3 ON CTE12.user_2 = f3.user_1
)
,CTE4
AS
(
    SELECT
        DISTINCT f4.user_2
    FROM
        CTE3
        INNER JOIN t_user_friend f4 ON CTE3.user_2 = f4.user_1
)
SELECT
    COUNT(DISTINCT f5.user_2) AS cnt
FROM
    CTE4
    INNER JOIN t_user_friend f5 ON CTE4.user_2 = f5.user_1
;
Run Code Online (Sandbox Code Playgroud)

最有SELECT DISTINCT可能需要排序,这将允许使用合并连接.


据我所知,从https://explain.depesz.com/s/Sjov上面的查询的执行计划,Postgres不够聪明,做了一些不必要的排序.此外,它使用散列聚合SELECT DISTINCT,这需要额外的排序.

因此,下一次尝试将明确地为每个步骤使用具有适当索引的临时表.

另外,我将idx_user_friend_user_12索引定义为唯一.它可能会为优化器提供额外的提示.

看看以下内容如何表现会很有趣.

CREATE TABLE temp12
(
    user_2 bigint NOT NULL PRIMARY KEY
);
CREATE TABLE temp3
(
    user_2 bigint NOT NULL PRIMARY KEY
);
CREATE TABLE temp4
(
    user_2 bigint NOT NULL PRIMARY KEY
);

INSERT INTO temp12(user_2)
SELECT
    DISTINCT f2.user_2
FROM
    t_user_friend f1 
    INNER JOIN t_user_friend f2 ON f1.user_2 = f2.user_1
WHERE
    f1.user_1 = 1
;

INSERT INTO temp3(user_2)
SELECT
    DISTINCT f3.user_2
FROM
    temp12
    INNER JOIN t_user_friend f3 ON temp12.user_2 = f3.user_1
;

INSERT INTO temp4(user_2)
SELECT
    DISTINCT f4.user_2
FROM
    temp3
    INNER JOIN t_user_friend f4 ON temp3.user_2 = f4.user_1
;

SELECT
    COUNT(DISTINCT f5.user_2) AS cnt
FROM
    temp4
    INNER JOIN t_user_friend f5 ON temp4.user_2 = f5.user_1
;

DROP TABLE temp12;
DROP TABLE temp3;
DROP TABLE temp4;
Run Code Online (Sandbox Code Playgroud)

作为显式临时表的额外奖励,您可以测量每个额外级别所需的时间.