1

我正在运行一个 Python 脚本，它处理许多不同指标的时间序列数据，然后将结果写入 Postgres 数据库。

时间序列假设 40 个 epoch，作为real[40]数组列存储在数据库中。

当一次将所有 40 个 epoch 的输出写入表时，（所有行的批量更新），一切似乎都运行良好。IE

UPDATE my_table SET
  arr_col_1 = {1, 2, 3, ... 40},
  arr_col_2 = {1, 2, 3, ...40},
  ...
  arr_col_90 = {1, 2, 3, ...40};

但是，将各个时期的结果迭代地写入阵列中的每个位置似乎会占用硬盘驱动器上的所有可用空间，例如

UPDATE my_table SET
  arr_col_1[1] = 1,
  arr_col_2[1] = 1,
  ...
  arr_col_90[1] = 1;

UPDATE my_table SET
  arr_col_1[2] = 2,
  arr_col_2[2] = 2,
  ...
  arr_col_90[2] = 2;

-- repeat x 38 more times

迭代策略的原因是为了容纳更多的行，40 个 epoch 的结果不能同时放入内存。

据我所知，UPDATE查询会在某些情况下删除和重写行数据，但我不清楚这种情况何时发生以及这可能与数组有什么关系。有没有办法在不导致数据库膨胀的情况下迭代地更新大量行的数组？

4

2 回答 2

4

正如其他人正确提到的，这种方法不太适合 PostgreSQL 的操作模式。

但是，您可以使用称为 HOT 的优化：

  • 用fillfactor小于 100 的值声明您的表，以便INSERTs 在每个块中留出可用空间：

    ALTER TABLE my_table SET (fillfactor = 50);

    此设置仅影响未来的活动，您必须重新组织表格才能影响现有数据。如果您更新表中的每一行，您可能需要一个低至 30 的设置才能生效。

  • 确保更新的列上没有索引。

然后 PostgreSQL 可以使用“HOT update”并即时回收死表条目，这避免了对 autovacuum 的需要，这显然无法跟上您的表。

检查表n_tup_hot_upd的pg_stat_user_tables行中的列，看看它是否正常工作。

于 2019-03-11T07:07:59.920 回答
2

Postgres 使用 MVCC，它执行写时复制。

将UPDATE整行复制到新行，旧行被标记为删除，但删除本身仅在真空期间发生，这由 autovacuum 守护程序定期发生。

您可以通过运行自己释放空间

VACUUM

你有多少磁盘空间用完了？我从未听说过与非大型数据库有关的此类问题。

于 2019-03-11T01:07:12.393 回答