PG-EU 2015 集群峰会
PG-EU 2015 集群峰会
此活动于 10 月 31 日星期六 9:00-13:00 在 维也纳万豪酒店 举行，作为 2015 年欧洲 PostgreSQL 大会 的一部分。会议的目标是讨论内置分片（sharding）的可能性，以最小的后端代码更改或添加来实现。 这些电子邮件线程提供了一些背景信息
会议将分为四个部分（答案以斜体显示）
期望
- 外部 Postgres 分片项目的历史，包括商业和开源项目，例如 Netezza、Greenplum、Postgres XC/XL、pg_shard
- 内置分片是一个理想的目标吗？优势/劣势
有人担心，即使修改了 FDW API，它也可能不足以满足所有用例。
- 现在是内置分片的合适时机吗？与外部/内置复制进行比较
可能始终需要外部解决方案，就像现在需要复制一样。 在添加支持内置分片的功能时，我们应该尽可能地不阻止外部分片解决方案使用这些功能。
- 基于协调器的架构可以接受吗？
可以，但应该有计划用于多协调器和无协调器架构。
- 跨工作节点结果集发送是必要的吗？ 例如 pg_shard
是的，可能内置，也可能只适用于外部项目。
- 我们针对哪些工作负载？ 只读、读写？ 短查询、长查询？
所有工作负载，但我们可能无法通过内置技术完成所有工作负载。 我们需要添加分片基础设施，然后才能确定它解决了哪些工作负载。
- 我们的目标设计是针对多少个集群？
可能是几个，几十个，甚至可能是几千个。
- 这是为了高可用性（HA）吗？
虽然用户想要 HA，但几乎所有带有协调器的系统都比使用流式复制和副本的系统可靠性更低，因此通常而言，基于协调器的分片不适用于高可用性。 非协调器分片解决方案可能会实现这一点，但还没有人提出这种系统的设计方案，尽管如果实现，它将需要某种 Paxos 或领导者选举协议。
- 我们需要轻松地添加/删除节点吗？
是的，设计应该考虑到这一点。
设计
- 现有的 Postgres 功能是否已经足够发展，以使内置分片成为一个合理的目标？ FDW、并行性
大家一致认为，这些功能应该得到足够增强，以使内置分片概念验证实现的基准测试成为可能。 然后我们可以考虑它能很好地处理哪些工作负载。 是的，这似乎有点倒退，但我们只能从 Postgres XC/XL 中猜测这将如何运作。
- 现有的 Postgres 功能可以增强，以使非分片和分片用例受益吗？
是的，情况显然如此。
- 还需要什么？ 原子提交、原子快照、分区 API
没有讨论。
- 这种方法的局限性是什么？ 它不会做什么？
没有讨论。 我认为在我们拥有完整的功能之前，我们无法知道答案。
- 这些局限性可以接受吗？ 在这些局限性下，内置分片是否足够有用？
我们不知道。
- 一个或多个协调器？
必须有多个，尽管可能不会在初始实现中。 对 Postgres XC/XL 的基准测试表明，通常需要多个协调器才能获得良好的结果。 但是，内置分片可能没有 XC/XL 的相同局限性，因此同样，我们必须等到它可以测试后才能知道。
实现
- FDW 缺少哪些东西？
没有讨论，但该列表通常是已知的。
- 需要哪些并行性功能？
没有讨论。
- 原子提交和原子快照是否足够？
没有讨论。
- 添加节点状态注册表？
大家一致认为，节点状态注册表将有助于分片和其他用例。
演示
讨论了幻灯片。
- pg_shard (Marco/Citus Data) [2]
讨论了幻灯片。
评论与担忧
来自 Simon Riggs，在准备会议记录后。
所有与会者都同意，某种形式的集群/分片是可取的，但并没有达成一致，认为这与 FDW 相同。
人们普遍担心，FDW 方法完全不适合用于为分片解决方案提供支持。 没有人解释过这将如何运作，即使在开始工作之前将设计发布到 Hackers 是标准做法。 会议上没有提供幻灯片或讨论。 许多开发人员都担心 FDW；尽管这从未讨论过，所以具体有多少人同意或不同意尚不清楚，但在作者看来，可能超过 50% 的经验丰富的黑客都持这种观点。 这在会议之前已经多次讨论过，在会议期间没有任何改变。
没有人反对扩展 FDW API，但那与它成为设计分片的正确方法完全是两回事。 FDW 缺陷的清单通常不是已知的（对我而言），也没有在任何地方记录下来。
因此，虽然没有人希望阻止 FDW 的工作，但许多人表示希望 FDW 不阻碍其他方法。
上面关于协调器的讨论似乎不正确。 为什么协调器会降低任何东西的健壮性？ 所有/大多数系统都有多个/备用协调器。
只有一点大家达成了一致：”我们需要一个节点注册表”。 “节点状态注册表”没有提及；我们讨论了尽可能将外部服务器、复制槽、复制源、集群名称和复制连接的概念整合到一个概念中。
