PostgreSQL列存增加更新和删除功能

PostgreSQL列存增加更新和删除功能

Hydra是企业级数据仓库的开源替代品。速度快且功能丰富，开发人员可以更快的构建更好的分析。支持列存PG的更新和删除是#1客户功能请求，现在GA了。之前博文“如何为分析构建最快的PG数据库”中，回顾了Hydra团队如何将列存、向量化和查询并行化添加到PG中，以及使用ClickBench的基准测试结果。目前对WHERE进行了向量化。但未用SIMD，声称很快会提供。平均下来，查询性能比基本PG提高了23倍！这也太夸张了吧，可以弄下来测试下，文末有源码地址。

如何工作

更新和删除是关系型数据库中一些最常见的功能。虽然append-only存储对不可变数据很有用，但缺乏其他数据库任务所需的灵活性。PG中的更新和删除并不是物理删除，而是在heap存储的tuple header中标记删除。

Hydra实现

列存储功能依赖于columnar schema中的几个元数据表。例如columnar.stripe表包含事务当前可见的所有stripes，这些信息用来读取和定位列存表的stripes。

Heap表通过MVCC在并发环境中提供数据的一致性版本。每个SQL语句可以看到一段时间之前的快照数据，而不管底层数据的当前状态如何。您可以想象当两个并发事务处于活动状态时的情况 - A 和 B。如果事务 A 向表中添加行，那么另一个事务将无法看到它们，因为事务 B 中的条目将不可见，即使columnar.stripe它们对事务 A 可见。

每个stripe包含15个chunk，每个chunk最多包含10,000行，每个chunk的元数据存储在columnar.chunk。该表可以根据chunk的最小值和最大值过滤chunk。每个chunk列在该表都有记录，因此执行过滤（WHERE）时，将根据最小值和最大值在读取chunk前检查这些值。

由于Hydra列存最初不可变，仅能追加，需要一些方法来标记列存外更新和删除的行。为此，添加了一个columnar.row_mask堆表来检查是否应跳过一行，从而模拟DML功能。

表的定义columnar.row_mask：

CREATE TABLE row_mask (
    id BIGINT NOT NULL,
    storage_id BIGINT NOT NULL,
    start_row_number BIGINT NOT NULL,
    end_row_number BIGINT NOT NULL,
    mask BYTEA,
    PRIMARY KEY (id, storage_id, start_row_number, end_row_number)
) WITH (user_catalog_table = true);

ALTER TABLE columnar.row_mask ADD CONSTRAINT row_mask_stripe_unique
UNIQUE (storage_id, start_row_number);

每个columnar.row_mask条目都与一个写入的chunk相关联。当刷写stripe时，也会为stripe中的每个chunk创建一个条目。该表几乎是完全静态的——除了mask之外的所有列都不会改变。mask是一个字节数组，其中每个位对应块中的一行--对于每个块，最多使用 1125 个字节。最初所有位都设置为零（可见）。当删除一行时，我们会将相应的位设置为1，表示扫描时应跳过该行。

Hydra的列存DELETE命令使用每个row_mask行的mask列逻辑标记已经删除的行，并在未来查询中隐藏他们。UPDATE命令类似，组合DELETE和INSERT操作，但是不会为逻辑删除的元组和新插入的元组之间留下任何链接。

列存表并发修改时锁表粒度是全表。

最佳实践

检查行是否被删除有一些开销——每扫描 100 万行大约需要 2 毫秒。只有在未过滤的情况下才会检查行，因此性能取决于WHERE查询中的子句。此外，不会检查没有删除行的块，这意味着未修改数据的性能非常快。

更新和删除数据的速度远不如插入数据快，因此应该谨慎进行。如果我们预计数据不会更改，则列式存储效果最好。由于每个事务都会创建一个stripe，因此理想情况下，您应该在单个批处理事务中执行尽可能多的更新。我们将在未来的版本中研究优化此行为。

下一步

计划通过VACUUM回收未使用的空间。通过堆表来对其进行并发控制。

GitHub分支地址：https://github.com/hydradatabase/hydra。

原文

https://blog.hydra.so/blog/2023-03-02-columnar-updates-and-deletes