人们相信，未来就是数据库即服务。 每个人都值得发起DBA并转到公共云，或努力通过Docker在Kubernetes上创建私有云吗？ #RuPostgres频道上来自Data Egret的三位专家-Alexei Lesovsky，Viktor Yegorov和Andrey Salnikov-现场直播了他们对哪种云模型适合的项目的看法。
讨论的主持人和主持人是Postgres.ai的创始人和RuPostgres.org社区的联合创始人Nikolay Samokhvalov。
在剪切下-对话记录。
-今天，我们将讨论云端的Postgres。 我将首先提出一个棘手的问题：难道您已经有一半以上的客户已经在云中了吗？阿列克谢：我想不是。 感觉不到一半。 每个人要么坐在自己的数据中心，要么租铁。
但是在谈论云之前，让我们定义一下术语。 我们所说的“云”是什么意思：亚马逊，谷歌云，数据库即服务？
-我将区分在Amazon EC2实例（或Google的类似物）上准备的云中的Postgres，在粗略地说，您可以在其中通过ssh登录并更正配置，并且在直接访问时可以在Postgres的控制下（英语为“托管”）进行控制在文件级别或没有ssh，但是只能连接和执行SQL查询。 原则上应分开考虑。 我的第一个问题是关于托管Postgres的。阿列克谢：这类客户基本上不到一半。
维克多：嗯，在第一种情况下-我们从云中获得什么显着的优势？ 云的含义是什么？
-在第一种情况下，使用各种现代工具，例如patroni和kubernetes（我们将分别讨论它们），您可以获得弹性，微服务以及所有这些。 这不同于一块铁。 就像“宠物与畜群”一样-宠物对铁的态度逐渐演变成与虚拟机和畜群的关系。 您已经不知道在那里安装了哪种腺体。 您没有订购它们，没有与供应商合作，没有考虑拓扑。 您可以节省时间。维克多：是的。 在我看来，第一种情况只是简化了购买新铁的过程。 您知道您需要什么：多少个内核和RAM，什么驱动器。 然后您从虚拟机提供的产品中选择一个虚拟机。 很快 但是否则，您仍然必须正常配置和维护该服务器。
-您如何看待虚拟机增加的开销（虚拟机内部的进程不是裸机，性能开销还是管理困难）？ 你们有没有测量过？Alexei：如果您可以控制虚拟机监控程序，则可以衡量开销。 在公共服务中不是-它们所提供的是您所使用的。
我五年前测得，可以在家中部署的常规虚拟化系统（KVM，Xen）的开销，大约是7-8％。 此外，它取决于虚拟机的设置和工作负载。 例如，与为Rails后端提供服务的Unicorn相比，Redis和Postgres的开销要大得多。
也许现在的数字有所不同。
-与Victor所说的优点相比，即使是5-7％的开销也是可以接受的。
以及您如何改变客户的构成：是否有向托管基础发展的趋势？
阿列克谢：不。 趋势恰恰相反。 使用RDS之类的人员缺乏管理和管理的灵活性。 结果，在EC2实例中，我们的态度“与宠物相似”。
维克多：这种情况迫在眉睫。 有些客户的主要生产基地非常繁忙。 自然地，它们被放置在分配的铁片上并受到持续的监督。 但是随着公司的成长，开发需要大量的测试和开发实例，并且它们会进入虚拟化。 也就是说，这是一个混合案例：在测试和开发环境下，可以购买硬件或租赁虚拟机。 但是生产仍然使用正常的硬件。
-是否使用Amazon RDS？Alexey：相反，我们的客户拒绝RDS。 正如我所说，原因是管理缺乏灵活性。
实例崩溃了，在某些情况下，仅通过租用功能更强大的熨斗就无法解决问题。
您自己无法解决许多问题-仅在支持的帮助下。
-可以举出例子吗？ 似乎最近亚马逊收购了OpenSCG-那些本应具备Postgres内部专业知识的伟人。 我从我自己的经历中知道，有一次考试。 如果您在Amazon RDS支持下打开了一张票，并且偶然发现一个无法帮助您的人，则只需关闭票，然后再次将其打开，即可获得更加称职的票。Alexey： OpenSCG当然是一个专业团队。 但是，购买这样的团队并不能消除100％的可能情况。 有些问题是第一次出现。 我们也会发生这种情况。
在后者中，在一个PostgreSQL 10.6副本中，尽管没有负载，但客户在主机上的平均负载突然增加了30–40个单位。 如此难以理解的地下敲门声。 它不会产生很大的影响，但是负载平均弹跳的图像是很难理解的。 她惹恼了客户的管理员。 我们有两个假设，造成这种情况的原因是什么，但是到目前为止，我们还无法测试它们，因为该系统具有生产力，并且无法在此处快速完成所有工作。
这样的“地下敲门声”每年大约发出一次，您便开始创造性地完成任务。 Amazon RDS的实例数量更多，安装和票证数量更多，各种情况都更大。
安德鲁：我想补充一下比较RDS和EC2实例。
我们有一个在RDS上进行生产的客户。 他寻求建议。 开发电路位于Microsoft Azure中，显然，Azure最初被视为主要的云服务。
我将开发电路库从Azure拖动到EC2中的Amazon，以更接近生产环境，而预测问题也更接近产品数据库。
尽管EC2服务器的简单程度是RDS实例的两倍，并且测试负载高于产品，但在我设置后的开发电路中，其结果要比生产中的RDS实例的亚马逊要好得多。
我怀疑由于客户公司内部缺少PostgreSQL专业知识，因此RDS与默认配置一起使用。 我们扭曲所有设置。
结果，客户印象深刻。 我向管理部门提出了一个建议，而不是使用RDS来管理和配置简单实例。
-顺便说一下，如何衡量，哪个更好，哪个更坏？安德鲁：客户查看了他的应用程序的指标，数据下载和处理的速度。
-我们现在正在责骂RDS，但它具有巨大的优势-它消除了与部署，备份，复制相关的许多麻烦。 你同意吗安德鲁：是的。 而且，最有可能的原因是，客户端仍然留在RDS中的主要原因是所提到的缺乏PostgreSQL专业知识。 他们可以通过RDS获得所需的一切，而只是为实例支付更多的费用。
-除了Amazon RDS，还有其他基于云的托管postgres。 您是否遇到过例如Yandex服务？Andrei：我遇到了他们的虚拟机，但我不是很喜欢它们-NVMe驱动器在那里不是很诚实。 实际上，存在通过网络连接的驱动器。
-诚实的NVMe（本地驱动器）也是一个问题。 Google和Amazon具有NVMe，但驱动器是临时的。 如果重新启动实例，则会丢失所有数据，因为您已获得另一个虚拟机。Andrei：他们在Yandex Cloud上对我说，他们在数据库即服务中拥有诚实的NVMe，但是我还没有遇到过该服务。 显然，在资源提供级别上存在稍微不同的体系结构。
他们非常努力地将DB作为服务使用，因为他们将其用于服务。 只是外部客户和内部使用有不同的切入点。
-您怎么看，俄罗斯Postgres在云端有什么前景？ 会起飞还是不起飞？安德鲁：Yandex拥有一支优秀的团队，经验丰富，并且具有很好的专业知识。 我认为它们会起飞。
首先，他们自己运营着许多Postgres（其项目中有1000多个数据库），并且 漏洞利用后，所有圆锥体和酸痛部位都会迅速解决并修复。 我认为将为客户提供质量相当好的最终服务。
并且需要这样的解决方案。 选择一家刚开始时出于各种原因而无法在Postgres方面拥有必要专业知识的初创公司：昂贵，他们不了解重点，尝试其他技术。 对他来说，这是一个很好的解决方案，因为在此类服务中，有限的“扭曲”不应该被扭曲，并且我认为，如果有的话，将会获得技术支持。
的确，Yandex Cloud仍处于起步阶段，目前没有提供太多功能。
-我们在聊天室提出了一个问题：您如何看待发布虚拟机时某人实际上可以坐在此计算机上（节流，节省时间）的事实？
维克多：是的，有这样的经历。 我只想提一提。 有些客户部署了自己的虚拟化系统。 他们不时要求查看一些非产品服务器，但情况却令人费解：我们没有观察到该服务器在该服务器上损坏的原因。 然后，我们将问题重定向到他们的管理员，并请求查看主机上正在发生的情况。
-该怎么做，亚马逊有类似的作用吗？ 有什么方法可以确定您被“挤压”了吗？ pgbench驱动？阿列克谢：我不记得了。 但是通常的方法是确定偷窃时间。 通常，在监视图上，我们看不到任何大的值。
-我觉得您不太喜欢托管Postgres。 是由于RDS接管您的工作吗？阿列克谢：不。 这很可能是由于我们根本没有它。 托管Postgres很好，因为您只需单击一个按钮即可部署基础架构。 只要您是一家初创企业，并且只需添加或读取数据而无需任何复杂的逻辑，一切就可以了。 例如，当您越过特定的界限时，您开始执行很多JOIN，执行复杂的SQL，则出现了优化查询的任务，RDS停止了丢失。 它需要更多的自由和影响力，但是可用的工具无法帮助您解决与Postgres自身内的资源处置相关的深层问题。 只有一个机会来增加铁片的力量：支付更多的钱-得到的。
安德鲁：对RDS的厌恶并没有对工作的恐惧。 问题不同。 假设一家初创公司采用RDS，他会给他们一切。 但是他并没有增加他在Postgres的专业知识。 接下来，假设有一个启动镜头。 负载在增加-写作和阅读已经增加。 在缺乏专业知识的情况下，初创企业必须寻找人才。 严重的DBA来了，发现他们无法从RDS中获得更多收益，但是从常规EC2实例中很有可能获得更高的性能，如我之前提到的示例。 如果允许使用RDS，也许我们可以调整和改进数据库，但我们没有。
-访问问题已得到解决。 有托管的Postgres提供ssh访问（甚至完全是root用户），例如，来自芬兰的Aiven小型公司。 默认情况下，他们不授予超级用户访问权限，但创始人（我曾与他交谈过几次）谈到了他准备根据请求授予访问权限。安德鲁：问题不仅仅在于访问。 为什么我们用纯腺体会更好呢？ 因为我们有很多不同的客户，并且每个客户都有自己的基础架构。 而且基础设施相距甚远，以至于在任何地方都可以使用相同的通用方法，但是我们做不到。 因为有些人拥有自己的硬件，但无法在某个地方托管（根据他们的某些规则和限制），并且有些人还处于云端。
-您想说未使用索引的定义取决于一块铁吗？ 还是其他平凡的东西？安德鲁：从管理的角度来看，云与硬件没有什么不同是数据库架构和未使用索引的定义。 一切都是统一的。
云和真正的硬件之间的区别（在基础之间，特别是在下面的硬件之间的层次中）是所使用的操作系统和虚拟化。 当您拥有大型数据库时，对于驱动器发送和接收数据的速度，内存和处理器的使用效率有多重要，因此减少此层的影响以使数据库最有效地工作非常重要。
-听众的另一个问题：内核设置如何？维克多：在EC2中，此类事情是可定制的。
-除了通常的亚马逊和谷歌，还有知名供应商针对“托管Postgres”类提供的新解决方案。 例如，Nutanix和SAP在2018年宣布创建基于Postgres的解决方案。 您难道不认为所有这些家伙都会导致我们做出一些相同的决定，而只是在您的铁腕上做出决定吗？ 这样您就可以单击按钮并部署新的Postgres，在该位置已经配置了备份和复制。Alexei：在我看来，SAP和其他公司并非完全盈利。 这些是钢铁和软件的大型供应商。 他们生产以赚钱为目标的产品。 至少出售支持。 因此，我们必须研究他们将如何从中受益。 如果这样的产品交付模式对他们有利，那为什么不呢？
-我的意思有点不同。 具体来说，这些人不会在开源中发布任何东西，而是免费赠送。 但是，您是否不认为较小但又活泼的人会做类似的事情？ 也许这将集中在Kubernetes的Operator框架上。 运营商已经在进行一些开发，例如Zalando。 而且您不认为基于云的RDS有助于逐步过渡到此类解决方案吗？ 我们将看到您如何生活，而无需动手掌握配置。阿列克谢：事实证明管理不善。
同样，您将需要有专家来监视所有这些情况，并在出现问题时爬到引擎盖下。
即使是非常Kubernetes的机器，也是非常复杂的，其内部有许多组件。 正式地，这只是五个二进制文件。 但是它们之间的交互作用由大量的文档以及有关聊天室，新闻通讯和Google网上论坛的大量信息来描述。 即 您仍然需要专人负责此厨房。
另外，所有这些都是动态发展的。 向后兼容性因发行版本而异。 即 一切都非常不稳定和不稳定。 当一切都安定下来后，也许我们会得到稳定，可靠的合适产品。 但是到目前为止，一切还不是很顺利。
Victor：我们开始谈论一个事实，那就是我们需要管理额外的基础架构层，以协调Kubernetes。
我不同意他只要按一下按钮就可以按照我们想要的方式进行神奇的工作。 有必要保留相关专家。
第二-我们的客户不断适应业务变化。 因此，数据库中的负载不断变化。 如果我们三个月前舔了所有东西，结果所有请求都可以正常工作，并且一切都很好，那么新的请求可能会在今天或明天到来，或者由于数据更改，现有的请求将停止正常工作。 我们需要分析情况并进入系统设置。 这就是自动化，在我看来，这使这种托管实例非常困难。 我不知道云层何时达到可以适应这种情况的状态。 但是，尽管这是需要完成的工作的重要部分，但是有必要使数据库设置适应传入请求模式的变化。
而且由于云本身是额外的管理负担，因此如果根本不存在该层，对我们来说就更容易了，因为我们可以专注于数据库问题。
如果客户希望生活在云中并拥有专业知识，那么我们对此无可厚非。 最主要的是，我们有机会在数据库变得不太好时，爬上（最好使用ssh），检查所有内容并获得所有统计信息。
Alexey：不一定是ssh。 但是无论如何，都需要诊断工具。 因为通过电子邮件进行的诊断非常漫长而乏味。 当您发送聊天链接到要执行的请求时，这很烦人，而另一方面，客户端单击该链接，复制请求，然后将结果复制给您或发送屏幕截图。 这一直都是。
连接和直接查看，检验您的某些假设并采取进一步行动要容易得多。
-您是否有关于Kubernetes已被使用和Postgres居住的地方的活跃示例？阿列克谢：不幸的是，我没有。 但是我真的很想。 我真的很喜欢Kubernetes，我很了解他的概念和哲学。
在我看来，Kubernetes鼓励人们更多地编程，更多地创建产品，而无需考虑基础设施内部结构等附带问题。
OOP曾经扮演过类似的角色。 它的出现使许多人对该领域产生了兴趣，因为编程变得有些容易了。 Kubernetes还可以自行关闭许多东西，将它们隐藏在引擎盖下，并允许人们专注于创造力并进行更多编程。
Kubernetes实现了对实例，炉床和应用程序的支持。 如果它突然崩溃-那么，Kubernetes将再次启动它。 即 开发人员和管理员无需烦恼和不断跟踪。 我喜欢这种对情况的反应。 跌落时，它将自动重新启动。
, , . — , , . .
– , ?: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .
– - kubernetes_ru. github, Kubernetes: . Postgres, .
, , , . , Kubernetes – , . - IT.
– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .:. .
, . , , . : , . , - . .
– . . , , .: . , . , , – . , , , , .
即 . – , , 70% . . .
, , « », .
– . , , DBA : - , - — , ?: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .
DBA — - «» , .
Kubernetes. , . . , Kubernetes . , volume . 即 , . , .
– ?: .
, . , , . , Postgres ( ). Postgres - . 即 (, ), .
, .
, , . . . .
– ?: - . , , .
, Cassandra. . 即 — , Kubernetes.
, , . , , .
即 . DBA, , – . , , - – .
– ?: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).
: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.
– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .: , , - high availability.
– . — , ?: , - .
Zalando DBA, patroni. 即 , Kubernetes , DBA .
– . DBA, DBA «» «».: , . . , , .
– - Kubernetes? ?: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).
- , , - - -.
: ( Kubernetes ), - . , — — . - , , , , , , .
:. Kubernetes , . , . .
, — . , Postgres- , , . .
: …
– .. : - — dev environment, production – Kubernetes. ...: latency , , . .
– , . .
, HighLoad++ .PS .