postgresql - Pentaho 的预期性能如何？

Question

我正在使用 Pentaho 创建 ETL，并且非常注重性能。我开发了一个 ETL 过程，将 163.000.000 行从 Sql server 2088 复制到 PostgreSQL，需要 17 小时。

我不知道这个性能有多好或多坏。您知道如何衡量某个过程所需的时间是否合适吗？至少可以作为一个引用来了解我是否需要继续在性能方面投入大量精力。

此外，我想知道在ETL过程的前2分钟加载2M行是否正常。我计算加载所有行需要多长时间。预期结果是 6 小时，但随后性能下降，需要 17 小时。

我一直在 goole 中进行调查，但没有找到任何时间引用，也没有任何关于性能的解释。

Answer 1

分而治之，并通过排除法进行。

首先，为您的查询添加一个 LIMIT，这样它需要 10 分钟而不是 17 小时，这将使尝试不同的事情变得更加容易。

进程是否在不同的机器上运行？如果是这样，请测量网络带宽利用率以确保它不是瓶颈。传输大文件，请确保带宽确实存在。

这些进程是否在同一台机器上运行？也许一个人正在让另一个人缺乏 IO。源和目标是同一个硬盘吗？不同的硬盘？固态硬盘？你需要解释一下...

检查两个进程的 IO 和 CPU 使用情况。一个进程是否最多占用 1 个 cpu 核心？

某个进程是否会占用其中一个磁盘的最大空间？检查iowait、iops、IO带宽等

有多少列？两个 INT、500 个 FLOAT，还是每行包含 12 MB PDF 的巨大 BLOB？这些情况下的性能会有所不同...

现在，我假设问题出在 POSTGRES 端。

创建一个与目标表相同的虚拟表，其中包含:

• 完全相同的列(CREATE TABLE 虚拟 LIKE 表)
• 没有索引，没有约束(我认为这是默认的，仔细检查创建的表)
• BEFORE INSERT 触发器返回 NULL 并删除该行。

行将被处理，但不会插入。

现在速度快吗？好的，所以问题出在插入上。

再做一次，但这次使用未记录的表(或临时表)。这些没有任何抗崩溃性，因为它们不使用日志，但是对于导入数据来说，这是可以的......如果它在插入过程中崩溃，你无论如何都会将其清除并重新启动。

仍然没有索引，没有约束。速度快吗？

如果慢 => IO 写入带宽问题，可能是由其他东西击中磁盘引起的如果快=>IO就OK，问题还没发现!

在表加载数据后，逐一添加索引和约束，看看是否有，比如说，使用慢 SQL 函数的 CHECK，或者在没有索引的表中进行 FK 之类的东西。只需检查创建约束需要多长时间。

注意:在这样的导入中，您通常会在导入后添加索引和约束。

我的直觉是，由于配置中的检查点设置太低，数据量很大，PG 正在疯狂地检查点。或者类似的问题，可能与随机 IO 写入相关。您将 WAL 放在快速 SSD 上，对吗？