Geekly articles weekly

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

嗨哈布罗夫斯克 今天，课程将从PostgreSQL课程的第一组开始。 在这方面，我们想告诉您本课程的公开网络研讨会是如何进行的。



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

该网络研讨会由EPAM Systems的Google Cloud Practice Delivery Manager Valery Bezrukov主持。

当树木很小的时候...


首先，让我们回想一下DBMS的选择是如何在上世纪末开始的。 但是，这并不困难，因为在那时，选择DBMS始于Oracle 。



实际上，在90年代后期-上世纪90年代初期，如果我们谈论工业可扩展数据库，则没有特别的选择。 是的，有IBM DB2，Sybase和一些其他数据库出现和消失了，但是总的来说，它们对Oracle的影响并不那么明显。 因此，当时工程师的技能以某种方式与现有的唯一选择联系在一起。

Oracle DBA应该能够：

  • 从发行版安装Oracle Server
  • 配置Oracle Server：

  • init.ora;
  • listener.ora;

-创建：

  • 表空间
  • 方案
  • 使用者


-备份和还原；
-进行监测；
-处理次优请求。

同时，不是特别需要Oracle DBA：

  • 能够选择最佳的DBMS或其他数据存储和处理技术；
  • 提供高可用性和水平可伸缩性（这并不总是DBA问题）；
  • 对主题领域，基础架构，应用架构，操作系统有很好的了解；
  • 执行数据的加载和卸载，以及在不同DBMS之间的数据迁移。


总的来说，如果我们谈论当时的选择，那么它类似于80年代后期在苏联商店中的选择：



我们的时间


从那以后，当然，树木长大了，世界变了，它变得像这样：



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



在这里应该注意的是，云占据了它们的利基市场，其普及度正在增长。 如果您阅读了同一份Gartner报告，我们将看到以下结论：

  1. 许多客户正在将应用程序迁移到云。
  2. 新技术首先出现在云中，而不是它们将永远迁移到无云基础设施的事实。
  3. 随用随付的定价模型已经很熟悉。 每个人都只想为自己使用的东西付费，这甚至不是趋势，而只是事实的陈述。

现在呢


今天，我们都在云中。 我们遇到的那些问题是选择的问题。 即使我们只谈论本地格式的DBMS技术选择，它也非常庞大。 我们还提供托管服务和SaaS。 因此，选择每年变得越来越复杂。

除选择问题外， 限制因素也适用：

  • 价格 。 许多技术仍然需要花钱。
  • 技能 。 如果我们谈论的是自由软件，那么就会出现技能问题，因为自由软件需要具有足够能力的人进行部署和操作。
  • 功能的 。 并不是说，即使基于相同的Postgres，在云中可用并构建的所有服务都没有与Postgres On-premises相同的功能。 这是您需要了解和理解的基本因素。 而且，此因素比了解单个DBMS的某些隐藏功能变得更加重要。

DA / DE正在等待什么：

  • 对主题领域和应用架构有很好的了解；
  • 考虑到任务选择正确的DBMS技术的能力；
  • 在现有限制的情况下选择最佳方法来实施所选技术的能力；
  • 执行数据迁移和迁移的能力；
  • 实施和操作所选解决方案的能力。

以下基于GCP的示例演示了如何根据数据的结构来安排处理数据的特定技术的选择：



请注意，架构中缺少PostgreSQL，所有都是因为它隐藏在Cloud SQL术语下。 当我们进入Cloud SQL时，我们需要再次做出选择：



应该注意的是，这种选择并不总是很清楚，因此应用程序开发人员通常会凭直觉进行指导。

总计：

  1. 距离越远，选择问题就越相关。 即使仅查看GCP，托管服务和SaaS，也只有在第4步才会提到RDBMS（并且附近有Spanner）。 另外，第5步通常显示PostgreSQL的选择，并且它旁边还有MySQL和SQL Server，也就是说，有很多，但是您需要选择 。
  2. 我们决不能忘记诱惑背景的限制。 通常每个人都想要一个扳手，但是价格昂贵。 结果，一个典型的查询看起来像这样： “请为我们做Spanner，但是就Cloud SQL的价格而言，您是专业人士！”



怎么办


在不假装成最终真理的情况下，让我们说以下几点：

需要改变学习方式：

  • 像在DBA之前教过的那样学习是没有意义的；
  • 对一种产品的知识不再足够；
  • 但是要了解一个级别的数十个对象是不可能的。

您不仅需要知道多少产品，还需要知道：

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

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

真实案例


在最近的过去，您必须为移动应用程序做一个后端。 在开始进行工作时，已经开发了后端并且可以实施了，开发团队在此项目上花费了大约两年的时间。 设置了以下任务：

  • 制作CI / CD；
  • 审查架构；
  • 全部投入运作。

该应用程序本身是微服务，并且从零开始并立即在GCP中开发了Python / Django代码。 对于目标受众，假设将有两个区域-美国和欧盟，并且流量是通过全球负载均衡器分配的。 所有工作负载和计算工作负载都在Google Kubernetes Engine中工作。

至于数据，有3种结构：

  • 云存储
  • 资料储存库；
  • Cloud SQL（PostgreSQL）。



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

对于我们的情况，选择Cloud SQL是出于以下原因：

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

  • PostgreSQL的
  • MariaDB;
  • 的MySQL
  • 甲骨文
  • SQLite的

因此，从该列表中直观地选择了PostgreSQL（事实上，它不是Oracle）。

缺少的是：

  • 该应用程序仅在两个地区部署，并且计划出现在第三名（亚洲）；
  • 该数据库位于北美地区（爱荷华州）；
  • 对于客户而言，担心由于 DBMS停机而导致欧洲和亚洲的访问延迟以及服务中断。

尽管Django本身可以并行处理多个数据库并通过读写来划分它们，但应用程序中的记录却很少（超过90％-读取）。 总的来说，如果您可以对欧洲和亚洲的主要基地进行复制 ，这将是一个折衷的解决方案。 好吧，有什么复杂的？

困难在于客户不想拒绝使用托管服务和Cloud SQL。 目前，Cloud SQL的可能性是有限的。 Cloud SQL支持高可用性（HA）和只读副本（RR），但仅在一个区域中支持相同的RR。 在美洲地区创建数据库后，尽管Postgres本身不会造成干扰，但无法使用Cloud SQL在欧洲地区进行只读副本。 与Google员工的通信并没有带来任何结果，并以“我们知道问题并正在努力解决问题，总有一天解决问题”的承诺结束。

如果列出Cloud SQL的论文可能性，它将看起来像这样：

1.高可用性（HA）：

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

2.只读副本（RR）：

  • 在一个区域内；
  • 热备用
  • PostgreSQL流复制。

另外，按照惯例，在选择技术时，您总是会遇到一些限制 ：

  • 除通过GKE之外，客户不想生产实体并使用IaaS；
  • 客户不想部署自助服务PostgreSQL / MySQL；
  • 好吧，总的来说，如果不是价格合理的话，Google Spanner会非常适合，但是Django ORM无法使用它，所以事情很好。

在这种情况下，客户收到一个回填问题： “您可以做些类似的事情来使其像Google Spanner一样，但它也可以与Django ORM一起使用吗？”

选件编号0


我想到的第一件事：

  • 留在CloudSQL中
  • 区域之间不会以任何形式进行集成复制；
  • 尝试通过PostgreSQL将副本固定到现有的Cloud SQL；
  • 在某个地方以某种方式启动PostgreSQL实例，但至少master不会碰。

las，事实证明这是无法完成的，因为无法访问主机（通常在另一个项目中），例如pg_hba等，并且在超级用户下仍然没有访问权限。

选项1


经过进一步思考并考虑到以前的情况，思路发生了一些变化：

  • 我们仍然试图将其保留在CloudSQL的范围之内，但我们正在切换到MySQL，因为MySQL的Cloud SQL具有一个外部主服务器，该主服务器：

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

由于设置MySQL复制不需要访问主机，因此基本上一切正常，但是非常不稳定且不便。 而且，当我们走得更远时，它变得完全令人恐惧，因为我们将整个结构部署为terraform，突然发现外部主设备不受terraform的支持。 是的，Google有一个CLI，但是由于某种原因，所有内容偶尔都会工作-它是创建的，不是创建的。 也许是因为CLI的发明是为了向外部进行数据迁移，而不是为副本进行数据迁移。

实际上，这清楚表明Cloud SQL根本不适合这个词。 正如他们所说，我们竭尽所能。

选项2


由于无法将其保留在Cloud SQL中，因此我们尝试制定妥协解决方案的要求。 要求如下：

  • 在Kubernetes中工作，最大程度地利用Kubernetes（DCS，...）和GCP（LB，...）的资源和功能;
  • 云中像HA代理这样一堆不必要的东西所带来的镇流器不足；
  • 能够在主要区域中运行HA PostgreSQL或MySQL； 在其他区域-主区域RR的HA及其副本（出于可靠性考虑）；
  • 多大师（不想与他联系，但这不是很重要）
。
由于这些要求，最终出现了合适的DBMS选项和绑定 ：

  • MySQL Galera;
  • CockroachDB;
  • PostgreSQL工具
：
-pgpool-II;
-帕特罗尼。

MySQL Galera


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

  • 多主
  • 同步复制
  • 从任何节点读取；
  • 记录到任何节点；
  • 整合的HA机制
  • 有一个来自Bitnami的Helm图表。

蟑螂


根据描述，这东西完全是夸张的，是用Go编写的一个开源项目。 主要参与者是蟑螂实验室（由Google的移民创立）。 此关系DBMS最初是为了分布式（即开即用的水平缩放）和容错而创建的。 该公司的作者概述了“将SQL功能的丰富性与NoSQL解决方案熟悉的水平可用性相结合”的目标。

不错的好处是支持postgres连接协议。

pool池


这是PostgreSQL的附加组件，实际上是一个接管所有连接并处理它们的新实体。 它拥有自己的加载程序平衡器和解析器，并已获得BSD许可。 它提供了足够的机会，但看起来有些令人恐惧，因为新实体的存在可能会成为其他冒险活动的来源。

帕特罗尼


这是最后一件事，而且事实证明，这并非徒劳。 Patroni是一个开源实用程序，从本质上讲，它是一个Python守护程序，可让您使用各种类型的复制和自动角色切换自动为PostgreSQL集群提供服务。 事实证明这很有趣，因为它与多维数据集很好地集成在一起，并且没有任何新实体。

最终选择了什么


选择并不容易：

  1. CockroachDB-火，但愚蠢；
  2. MySQL Galera也不错，它在很多地方都使用过，但是MySQL;
  3. Pgpool-很多额外的实体，通常与云和K8s集成；
  4. Patroni-与K8完美集成，无需额外实体，与GCP LB集成良好。

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

结论


现在该总结一下了。 是的，IT基础架构的世界已经发生了巨大变化，这仅仅是开始。 如果以前的云只是另一种基础架构，那么现在一切都将有所不同。 此外，云中的创新不断出现，它们将会出现，也许它们只会出现在云中，然后才通过初创公司的力量将其转移到本地。

至于SQL，SQL将继续存在。 这意味着必须知道PostgreSQL和MySQL，并且您需要能够使用它们，但更重要的是，要能够正确地应用它们。

Source: https://habr.com/ru/post/zh-CN481644/

More articles:


All Articles