Built in sharding in PostgreSQL

Published on:
Tags: postgresql

PostgreSQL 内建 sharding 支持,粗略翻译自 https://wiki.postgresql.org/wiki/Built-in_Sharding

Introduction

内建支持 sharding 最大的挑战是,如何用最小的代码修改实现。大部分社区的 sharding 修改支持都修改了很多 PostgreSQL 的代码,这也导致这些不能被 Postgres 社区那些不需要 sharding 的人接受。有了 FDW 之后,就有了在有限代码修改情况下实现内建 sharding 支持的可能。

基于 FDW 的这种 sharding 设计,是基于 NTT 开发的 Postgres-XC,大概已经有 10 年了。Postgres-XL 是基于这个设计的一种更加灵活的实现。

Enhance Existing Features

  • 已完成?提升 FDW 的基础设计和 postgres_fdw。特别的,好的性能要求合理的把一些操作推送到子节点(foreign shards)。在 Postgres 9.6 中,join, sort, update, delete 都可以推送到字节点了。聚合的 pushdown 将在 Postgres 10 中支持。FDW 表已经可以作为继承表出现。
  • 提升分区支持有效提升 existence of shards。幸运的是,单节点的分区支持也需要重构才能提升性能和更多优化。例如,executor-based partition pruning.
  • 给 FDW 请求增加并行支持。这样能允许节点并行执行,这个可能会通过多个异步的链接来实现。

New Subsystems

还需要开发一些子系统:

  • 允许表可以复制到所有节点,以允许更多的 join pushdown。这个可以通过 trigger 或者逻辑复制来完成。
  • 实现一个子模块,以使用新的分区系统表来提交符合提交的查询的 FDW 查询。
  • 实现一个子模块收集 FDW 查询的结果返回给用户。
  • 实现全局事务管理器以便更加高效的允许子节点原子的提交事务。这个可能会通过 prepared 的事务来实现,还有某种在 crash 之后清理那些 preapared 的事务的事务管理器。例如 XA。
  • 实现全局快照管理器,以允许子节点可以看到一致性的快照。(是不是 serialisable 事务模式会避免跨节点快照冲突?pg_export_snapshot() 或者 hot_standby_feedback 是不是会有帮助?) 多节点的备份的一致性也需要这个支持。
  • 实现支持 create, manage, report on shards 这些用户 API。

Use Cases

有四种可能的用户案例和不同的需求:

  • 跨节点在只读节点上面执行只读聚合查询,例如数据仓库
    这种是最简单的场景,不需要全局事务管理,全局快照管理,并且因为聚合,所以子节点返回的数据量也是最小的。
  • 跨节点在只读节点上面执行只读非聚合查询
    这种会给调度节点压力,需要收集和处理很多子节点返回的数据。这种也能看到 FDW 传输机制等级。
  • 跨节点在可读写节点执行只读查询
    这个需要全局快照管理来保证子节点返回数据的一致性
  • 跨节点执行读写查询
    这个需要全局快照管理器和全局事务管理器

Comments