SQL 数据库如何在 21 世纪生存：云、Kubernetes 和 PostgreSQL 多主机

哈布罗夫斯克的居民们大家好。 第一组课程今天开始 “PostgreSQL”。 在这方面，我们想向您介绍一下本课程的公开网络研讨会是如何进行的。

В 下一次公开课 我们讨论了SQL数据库在云和Kubernetes时代面临的挑战。 同时，我们研究了 SQL 数据库在这些挑战的影响下如何适应和变异。

举办了网络研讨会 瓦列里·别兹鲁科夫，EPAM Systems 的 Google Cloud 实践交付经理。

当树还小的时候...

首先，让我们回想一下上世纪末 DBMS 的选择是如何开始的。 不过，这并不会很难，因为当年 DBMS 的选择就开始了，结束了 神谕.

在 90 世纪 2 年代末和 XNUMX 年代初，工业可扩展数据库基本上没有选择。 是的，IBM DBXNUMX、Sybase 和其他一些数据库来了又去，但总的来说，它们在 Oracle 的背景下并不那么引人注目。 因此，那个时代工程师的技能在某种程度上与存在的唯一选择联系在一起。

Oracle DBA 必须能够：

• 从分发包安装 Oracle Server；
• 配置 Oracle 服务器：

• 初始化.ora；
• 监听器.ora；

- 创造：

• 表空间；
• 计划；
• 用户；

— 执行备份和恢复；
——进行监测；
— 处理次优请求。

同时，Oracle DBA 也没有特殊要求：

• 能够选择最佳的 DBMS 或其他技术来存储和处理数据；
• 提供高可用性和水平可扩展性（这并不总是 DBA 的问题）；
• 对学科领域、基础设施、应用程序架构、操作系统有良好的了解；
• 加载和卸载数据，在不同的 DBMS 之间迁移数据。

总的来说，如果我们谈论当时的选择，它类似于 80 年代末苏联商店的选择：

我们的时代

当然，从那时起，树木长大了，世界发生了变化，变成了这样：

DBMS市场也发生了变化，从Gartner的最新报告可以清楚地看到：

在这里应该指出的是，越来越受欢迎的云已经占据了自己的利基市场。 如果我们阅读同一份 Gartner 报告，我们会看到以下结论：

1. 许多客户正在将应用程序迁移到云端。
2. 新技术首先出现在云中，事实上它们不会迁移到非云基础设施。
3. 按量付费的定价模式已变得司空见惯。 每个人都想只为他们使用的东西付费，这甚至不是一种趋势，而只是一个事实的陈述。

现在怎么样？

今天我们都在云端。 我们面临的问题是选择问题。 即使我们只讨论本地格式的 DBMS 技术的选择，它也是巨大的。 我们还有托管服务和 SaaS。 因此，选择只会变得一年比一年困难。

除了选择问题之外，还有 限制因素:

• 价格。 许多技术仍然需要花钱；
• 技能。 如果我们谈论自由软件，那么技能问题就出现了，因为自由软件需要部署和操作它的人有足够的能力；
• 功能性。 并非所有在云中可用并构建的服务（即使是在同一个 Postgres 上）都具有与本地 Postgres 相同的功能。 这是一个需要了解和理解的重要因素。 此外，这个因素比了解单个 DBMS 的某些隐藏功能更重要。

现在对 DA/DE 的期望：

• 对主题领域和应用程序架构有很好的理解；
• 能够根据手头的任务正确选择适当的 DBMS 技术；
• 在现有限制的情况下选择实施所选技术的最佳方法的能力；
• 执行数据传输和迁移的能力；
• 实施和操作选定解决方案的能力。

下面的例子 基于GCP 演示如何根据数据结构选择一种或另一种处理数据的技术：

请注意，PostgreSQL 未包含在架构中，这是因为它隐藏在术语下 SQL云。 当我们使用Cloud SQL时，我们需要再次做出选择：

应该注意的是，这种选择并不总是明确的，因此应用程序开发人员通常会受到直觉的指导。

合计：

1. 走得越远，选择的问题就越紧迫。 即使您只关注 GCP、托管服务和 SaaS，也只会在第四步中提到 RDBMS（Spanner 就在附近）。 另外，第4步出现了PostgreSQL的选择，旁边还有MySQL和SQL Server，即 一切都有很多，但你必须选择.
2. 我们决不能忘记在诱惑的背景下的限制。 基本上每个人都想要一把扳手，但它很贵。 因此，典型的请求如下所示： “请为我们制作一个 Spanner，但就 Cloud SQL 的价格而言，你们是专业人士！”

该怎么办？

在不声称是最终真理的情况下，让我们说以下内容：

我们需要改变我们的学习方式：

• 按照以前教授 DBA 的方式进行教学是没有意义的；
• 仅仅了解一种产品已经不够了；
• 但在一个层面上了解几十个是不可能的。

您不仅需要知道产品的价格，而且还需要：

• 其应用程序的用例；
• 不同的部署方式；
• 每种方法的优点和缺点；
• 类似和替代产品，以做出明智的最佳选择，而不是总是偏爱熟悉的产品。

您还需要能够迁移数据并了解与 ETL 集成的基本原理。

真实案例

最近，有必要为移动应用程序创建一个后端。 当工作开始时，后端已经开发完毕并准备好实施，开发团队在这个项目上花了大约两年的时间。 制定了以下任务：

• 构建 CI/CD；
• 审查架构；
• 将其全部投入运行。

该应用程序本身是微服务，Python/Django 代码是直接在 GCP 中从头开始开发的。 至于目标受众，假设有两个区域——美国和欧盟，流量通过全球负载均衡器分配。 所有工作负载和计算工作负载都在 Google Kubernetes Engine 上运行。

至于数据，有3种结构：

• 云储存;
• 数据存储;
• 云 SQL (PostgreSQL)。

有人可能想知道为什么选择 Cloud SQL？ 说实话，这样的问题近年来引起了某种尴尬的停顿——有一种感觉，人们对关系数据库变得害羞了，但尽管如此，他们仍然继续积极地使用它们;-)。

就我们的案例而言，选择 Cloud SQL 的原因如下：

1. 如前所述，该应用程序是使用 Django 开发的，它有一个用于将持久数据从 SQL 数据库映射到 Python 对象的模型 (Django ORM)。
2. 该框架本身支持相当有限的 DBMS 列表：

• PostgreSQL；
• 玛丽亚数据库；
• MySQL；
• 甲骨文;
• SQLite的。

因此，从这个列表中相当直观地选择了 PostgreSQL（好吧，实际上不是 Oracle 可供选择）。

缺少什么：

• 该应用程序仅在 2 个地区部署，第三个地区出现在计划中（亚洲）；
• 该数据库位于北美地区（爱荷华州）；
• 客户方面担心可能 访问延迟 来自欧洲和亚洲以及 打扰 在役 如果 DBMS 停机。

尽管Django本身可以并行处理多个数据库，并将它们分为读和写，但应用程序中并没有那么多的写（90%以上是读）。 总的来说，一般来说，如果可以的话 欧洲和亚洲主要基地的只读副本，这将是一个折衷的解决方案。 那么，这有什么复杂的呢？

困难在于客户不想放弃使用托管服务和 Cloud SQL。 Cloud SQL 的功能目前还很有限。 Cloud SQL 支持高可用性 (HA) 和只读副本 (RR)，但同一 RR 仅在一个区域支持。 在美洲区域创建数据库后，您无法使用 Cloud SQL 在欧洲区域创建只读副本，尽管 Postgres 本身并不阻止您这样做。 与谷歌员工的通信毫无结果，最终以“我们知道问题所在并正在努力解决，总有一天问题会得到解决”的承诺告终。

如果我们简要列出 Cloud SQL 的功能，它将如下所示：

1. 高可用性（HA）：

• 在一个区域内；
• 通过磁盘复制；
• 不使用 PostgreSQL 引擎；
• 可进行自动和手动控制 - 故障转移/故障恢复；
• 切换时，DBMS 有几分钟不可用。

2. 只读副本 (RR)：

• 在一个区域内；
• 双机热备；
• PostgreSQL 流式复制。

此外，按照惯例，在选择技术时，您总是会面临一些问题 限制:

• 客户不想创建实体并使用 IaaS，除非通过 GKE；
• 客户不想部署自助服务 PostgreSQL/MySQL；
• 好吧，总的来说，如果不是因为它的价格，Google Spanner 会很合适，但是 Django ORM 无法使用它，但这是一件好事。

考虑到这种情况，客户收到了后续问题： “你能做一些类似的事情，让它像 Google Spanner 一样，但也可以与 Django ORM 一起使用吗？”

解决方案选项号 0

我首先想到的是：

• 留在 CloudSQL 中；
• 区域之间不会有任何形式的内置复制；
• 尝试将副本附加到现有 Cloud SQL by PostgreSQL；
• 在某处以某种方式启动 PostgreSQL 实例，但至少不要触及 master。

唉，事实证明这是无法做到的，因为无法访问主机（它完全在不同的项目中）- pg_hba 等，并且在超级用户下也无法访问。

解决方案选项号 1

经过进一步反思，考虑到之前的情况，思路有所改变：

• 我们仍然试图留在 CloudSQL 中，但我们正在切换到 MySQL，因为 Cloud SQL by MySQL 有一个外部主服务器，它：

— 是外部 MySQL 的代理；
- 看起来像一个 MySQL 实例；
- 专为从其他云或本地迁移数据而发明。

由于设置 MySQL 复制不需要访问主机，因此原则上一切正常，但非常不稳定且不方便。 当我们更进一步时，它变得完全可怕，因为我们用terraform部署了整个结构，突然发现外部master不受terraform支持。 是的，Google 有一个 CLI，但由于某种原因，这里的所有东西时不时都能工作 - 有时它被创建，有时它没有创建。 也许是因为 CLI 是为了外部数据迁移而发明的，而不是为了副本。

事实上，此时很明显Cloud SQL根本不适合。 正如他们所说，我们已竭尽全力。

解决方案选项号 2

由于不可能保留在 Cloud SQL 框架内，因此我们尝试制定折衷解决方案的要求。 结果要求如下：

• 在 Kubernetes 中工作，最大限度地利用 Kubernetes（DCS，...）和 GCP（LB，...）的资源和功能；
• 云中缺乏大量不必要的东西（例如 HA 代理）的镇流器；
• 能够在主 HA 区域运行 PostgreSQL 或 MySQL； 在其他区域 - 来自主区域 RR 的 HA 加上其副本（为了可靠性）；
• multi master（我本来不想联系他，但也不是很重要）

.
由于这些要求，p合适的 DBMS 和绑定选项:

• MySQL 加莱拉；
• 蟑螂数据库；
• PostgreSQL 工具

:
- pgpool-II；
——帕特罗尼。

MySQL 加莱拉

MySQL Galera 技术由 Codership 开发，是 InnoDB 的插件。 特点：

• 多主；
• 同步复制；
• 从任意节点读取；
• 记录到任意节点；
• 内置HA机制；
• Bitnami 提供了 Helm 图表。

CockroachDB

根据描述，这东西绝对是炸弹，是一个用 Go 编写的开源项目。 主要参与者是Cockroach Labs（由Google的人创立）。 该关系 DBMS 最初设计为分布式（开箱即用的水平扩展）和容错能力。 该公司的作者概述了“将 SQL 功能的丰富性与 NoSQL 解决方案所熟悉的水平可访问性相结合”的目标。

一个不错的好处是支持 post-gress 连接协议。

PG池

这是 PostgreSQL 的一个附加组件，实际上是一个接管所有连接并处理它们的新实体。 它有自己的负载平衡器和解析器，并在 BSD 许可证下获得许可。 它提供了充足的机会，但看起来有些可怕，因为新实体的存在可能会成为一些额外冒险的来源。

帕特罗尼

这是我最后看到的一件事，而且事实证明，我的目光并没有白费。 Patroni 是一个开源实用程序，本质上是一个 Python 守护进程，允许您通过各种类型的复制和自动角色切换自动维护 PostgreSQL 集群。 事实证明，这件事非常有趣，因为它与立方体集成得很好，并且没有引入任何新实体。

你最后选择了什么？

这个选择并不容易：

1. CockroachDB - 火，但黑暗；
2. MySQL 加莱拉 - 也不错，很多地方都用它，但是MySQL；
3. PG池 — 很多不必要的实体，与云和 K8s 的集成马马虎虎；
4. 帕特罗尼 - 与 K8s 完美集成，没有不必要的实体，与 GCP LB 集成良好。

因此，选择落在了帕特罗尼身上。

发现

是时候简单总结一下了。 是的，IT 基础设施的世界已经发生了巨大的变化，而这仅仅是一个开始。 如果说以前云只是另一种类型的基础设施，那么现在一切都不同了。 而且，云中的创新不断出现，它们将会出现，也许它们只会出现在云端，只有这样，通过初创公司的努力，它们才会转移到本地。

至于SQL，SQL将会存在。 这意味着您需要了解 PostgreSQL 和 MySQL 并能够使用它们，但更重要的是能够正确使用它们。

来源： habr.com