此页面总结了Dim关于如何分布式 PostgreSQL 的想法。

为了获得可用的东西，我们需要重用现有的概念和想法，并将它们混合匹配以解决我们的问题。

我们试图找到解决方案的需求是能够为单个 PostgreSQL 集群使用多台物理机器。

数据位置

有两个问题需要解决：我们希望我们的数据要么分布在多台机器磁盘上（考虑低成本存储设施），要么希望本地副本能够关闭任何节点。

提案主线是使用表空间的概念：它是一个与物理存储位置相关的已知概念。现在将其引导到远程位置。

远程表空间

构建在 8.4 外部数据包装器之上，我们可以设置远程表空间。也许我们需要一个新的 API 来实现这一点，主要思想是在我们被授予必要权限的远程 PostgreSQL 服务器上进行数据访问（读写）。

远程位置必须能够感知“远程表空间”并接受我们的请求，通过拥有必要的外部数据包装器模块吗？

特定的 FDW 模块将负责使 PostgreSQL 服务器能够使用与表空间相关的相同 API，无论是在本地还是远程。

示例

A#= CREATE TABLESPACE local_a;
B#= CREATE FOREIGN TABLESPACE bar SERVER A OPTIONS(tablespace 'local_a');

现在每个在服务器 B 上发生的访问（读取、写入、表创建或扩展等）都必须由服务器 A 完成，服务器 A 也可以在本地使用相同的表空间。安全将像往常一样实现，B 用户例如只能获得读取权限或完全访问权限，而本地 A 用户只能获得读取权限……

物理访问只能通过表空间本地后端完成，通过某些网络级 API 或协议在特定的外部数据包装器中实现。

表空间卷

现在我们能够在远程 PostgreSQL 服务器上存储关系，并能够从那里透明地获取数据，我们想要两个重要特性

本地镜像，用于性能，
单个关系在多个表空间中，用于使用商品硬件存储大量数据。

解决这两个问题的想法是创建一个表空间卷，它是一个表空间外壳，使用一个或多个“真实”表空间（演示语法）。

 CREATE TABLESPACE VOLUME foo_mirror MIRRORING bar;

现在单个关系可以驻留在多个位置，规划器必须了解这一点并选择“最近”的位置。关于数据访问性能指标的统计信息将被收集，以便数据路径现在成为成本估计的一部分。

笔记

成本评估模型是否应该足够动态以考虑负载影响？如果降级的 RAID 阵列在此处产生影响，那就太好了。
应该有一种方法来表明镜像已关闭，并在没有镜像的情况下继续处理：这只是一个优化路径。
同一个表空间可以有多个镜像，考虑每个 PostgreSQL 集群如何知道其本地表空间副本（网络拓扑）可能变得必要。
拓扑对于高可用性是必需的：而不是优化路径，镜像允许关闭一个集群，但仍然可以回答查询。

另一个用例是（演示语法）

 CREATE TABLESPACE VOLUME foo_spreaded SPREADED ON bar, baz, buz;

现在单个关系可以将其数据的一部分存储在与其他数据不同的位置，因此我们需要维护一个哈希系统来了解在哪里可以找到数据。哈希函数可以由用户提供（参见 plproxy）。

非常有用，例如将 30TB 表存储在十个 1TB 系统上，并让用户知道他们的数据在哪里。

同时使用两者

当您有几个 1TB（或更多）远程分区来存储数据时，您将希望能够拥有分区的镜像，以便能够关闭任何节点。并且您希望任何单个集群成为另一个集群的备份（镜像），无论是为了高可用性还是负载均衡（本地访问性能）。

因此，我们将能够制作镜像表空间的分布式表空间，例如。

Dump & Restore 支持

是否需要能够转储和恢复网络表空间拓扑？

似乎没有必要，因为我们将在任何时候恢复到单个集群，并且要么需要在恢复时使用其他节点，但然后您可以从镜像现有表空间开始，要么需要从头开始构建一个新的集群，并设置一个新的拓扑结构。

处理能力共享

现在，数据在任何时候都可能存在于多个集群上，当您拥有同一数据的本地和远程副本，或者单个关系分布在多台机器上时，为什么只有一个 CPU 专注于给定的查询？您希望远程异步 IO，因此您需要每个请求多个 CPU。

这方面的两种实现已经存在

辅助后端

待办事项：解释 Markus 在 [1] 中关于辅助后端、iMessage 队列等的实现。

从属后端

待办事项：再次找到有关它们的 CVS 4.3 时代链接。

PostgreSQL 分布式

内容