您认为谁会更好地配置PostgreSQL-DBA或ML算法？ 如果是第二次，那么现在是时候该思考一下汽车取代我们时该怎么办了。 否则就不会实现，重要的决定还是应该由人们做出。 隔离级别和对事务稳定性的要求可能应该由管理员保留。 但是索引很快就可以用来确定您自己的机器。
HighLoad ++上的Andy Pavlo谈到了未来的DBMS，您现在可以“接触”。 如果您错过了此演讲，或者更喜欢接收俄语信息，请在相应的翻译部分进行删节。
这将与卡内基梅隆大学关于创建自主DBMS的项目有关。 术语“自治”是指无需任何人工干预即可自动部署，配置和配置自身的系统。 开发这样的内容可能需要大约十年的时间，但这就是Andy和他的学生正在做的事情。 当然，创建自主的DBMS需要机器学习算法，但是，在本文中，我们将仅关注该主题的工程学方面。 考虑如何设计软件以使其独立。
关于演讲者： Andy Pavlo是卡内基梅隆大学的副教授，在他的领导下创建了
“自我管理”的DBMS PelotonDB以及
ottertune ，后者有助于使用机器学习来调整PostgreSQL和MySQL配置。 Andy和他的团队现在是自我管理数据库的真正领导者。
我们想要创建一个自主DBMS的原因是显而易见的。 管理这些DBMS工具是一个非常昂贵且耗时的过程。 在美国，DBA的平均年薪约为8.9万美元。 换算成卢布，每年可获得590万卢布。 您付给人们的这笔巨额资金只是为了关注您的软件。 使用该数据库的总成本中约有50％由此类管理员和相关人员的工作支付。
当涉及到大型项目（例如我们在HighLoad ++上讨论的项目）并且使用数以万计的数据库时，其结构的复杂性超出了人们的理解。 每个人都从表面上解决此问题，并尝试通过最小的努力来优化系统，以实现最佳性能。
如果在应用程序和环境级别配置DBMS以确保最佳性能，则可以节省整数。
1970-1990年的自适应数据库
自主DBMS的概念并不新鲜；它们的历史可以追溯到1970年代，当时关系数据库首次被创建。 然后它们被称为自适应数据库（Self-Adaptive Databases），在他们的帮助下，他们试图解决数据库设计的经典问题，直到今天人们仍在努力解决这些问题。 这是索引的选择，数据库模式的分区和构造以及数据放置。 当时，开发了可帮助数据库管理员部署DBMS的工具。 实际上，这些工具的工作就像今天的现代工具一样。
管理员跟踪应用程序执行的请求。 然后，他们将此查询堆栈传递给调整算法，该算法会建立一个内部模型，说明应用程序应如何使用数据库。
如果创建的工具可帮助您自动选择索引，则可以构建图表，从中可以查看每列的访问频率。 然后将此信息传递给搜索算法，该算法将搜索许多不同的位置-尝试确定哪些列可以在数据库中建立索引。 该算法将使用内部成本模型来表明，与其他指标相比，这一特定模型将提供更好的性能。 然后，该算法将建议应该对索引进行哪些更改。 现在，是时候参加这个人了，考虑这个建议，不仅要决定它是否正确，而且还要选择合适的时间来实施它。
当用户活动减少时，DBA应该知道如何使用该应用程序。 例如，在星期天凌晨3:00，这是数据库查询的最低级别，因此此时您可以重新加载索引。
正如我所说，当时所有的设计工具都以相同的方式工作-
这是
一个非常老的问题 。 我的科学主管的科学主管在1976年写了一篇有关自动索引选择的文章。
自调整数据库，1990–2000年
实际上，在1990年代，人们致力于解决同一问题，只是名称从自适应数据库更改为自调整数据库。
算法略胜一筹，工具略胜一筹，但从总体上讲，它们的工作方式与以前相同。 处于自动调整系统运动最前沿的唯一一家公司是Microsoft Research及其自动管理项目。 他们开发了真正出色的解决方案，并且在90年代末和00年代初，他们再次提出了一系列建立数据库的建议。
Microsoft提出的关键思想与过去不同-他们没有让自定义工具支持自己的模型，而是实际上只是重用了查询优化器成本模型来帮助确定一个索引相对于另一个索引的收益。 如果您考虑一下，这是有道理的。 当您需要知道单个索引是否可以真正加快查询速度时，如果优化程序不选择索引大小，则无关紧要。 因此，优化器用于确定他是否会真正选择某项。
2007年，Microsoft Research发表
了一篇文章 ，对十年来的研究进行了回顾。 它很好地涵盖了路径各部分中出现的所有复杂任务。
在
自动调整数据库时代，另一个突出的任务是
如何对调节器进行自动调整。 数据库控制器是某种配置参数，可以在运行时更改数据库系统的行为。 例如，几乎每个数据库中都存在的参数是缓冲区的大小。 或者，例如，您可以管理设置，例如阻止策略，磁盘清理的频率等。 由于近年来DBMS调节器的复杂性显着增加，因此这个主题变得很重要。
为了说明问题的严重性，我将回顾一下我的学生在研究了许多PostgreSQL和MySQL版本之后所做的事情。
在过去的15年中，PostgreSQL中的调节器数量增加了5倍，而MySQL则增加了7倍。
当然，并非所有的监管机构都实际控制任务执行过程。 例如，其中一些包含文件路径或网络地址，因此只有一个人可以配置它们。 但是其中有几十个确实会影响性能。 没有人能抱得那么多。
云数据库，2010年……
更进一步，我们发现自己处于2010年代的今天。 我称之为云数据库时代。 在这段时间内，已经做了很多工作来自动化云中大量数据库的部署。
使主要云提供商感到担忧的主要事情是如何托管租户或如何从一个租户迁移到另一个租户。 如何确定每个租户将需要多少资源，然后尝试在计算机之间分配资源，以最大化生产力或以最小的成本匹配SLA。
亚马逊，微软和谷歌解决了这个问题，但主要是在运营层面。 直到最近，云服务提供商才开始考虑配置单个数据库系统的需求。 这项工作对普通用户不可见，但是它决定了公司的高层。
总结具有自主和非自主系统的数据库的40年研究，我们可以得出结论，这项工作还不够。
为什么今天我们不能拥有真正自治的自治系统？ 这有三个原因。
首先，所有这些工具，除了云服务提供商分配的工作负载之外
，本质上仅是
建议性的 。 也就是说，根据所计算出的选项，一个人必须就此建议是否正确做出最终的主观决定。 而且，有必要观察系统一段时间以决定随着服务的发展，所作的决定是否仍然正确。 然后在将来将知识应用到您自己的内部决策模型中。 可以为一个数据库完成此操作，但不能为数万个数据库完成。
下一个问题是
任何措施都只是对某种事物的反应 。 在我们检查的所有示例中，工作都与过去工作负载中的数据一起进行。 有一个问题，有关它的记录被传送到仪器，他说：“是的，我知道如何解决这个问题。” 但是解决方案仅涉及已经发生的问题。 该工具不会预测未来的事件，因此不会提供准备行动。 一个人可以执行此操作，并且可以手动执行，但工具不能执行。
最后一个原因是，在所有解决方案中都
没有知识的转移 。 这就是我的意思：例如，让我们在第一个数据库实例上的一个应用程序中使用一个工具，如果将其放在另一个数据库实例上的另一个应用程序中，则可以基于使用第一个数据库时获得的知识数据帮助建立第二个数据库。 实际上，所有工具都从头开始工作，它们需要重新获取有关正在发生的一切数据。 人的工作方式完全不同。 如果我知道如何以某种方式配置一个应用程序，则可以在另一个应用程序中看到相同的模式，并且可能更快地进行配置。 但不是这些算法之一，也不是这些工具之一仍然可以这种方式工作。
为什么我确定是时候改变了？ 这个问题的答案与为什么超级数据数组或机器学习变得流行的问题大致相同。
设备的质量越来越好 ：生产资源在增加，存储容量在增加，硬件容量在增加，这加快了学习机器学习模型的计算速度。
我们已经可以使用高级软件工具。 以前，您需要是MATLAB或低级线性代数的专家才能编写一些机器学习算法。 现在我们有了Torch和Tenso Flow，它们使ML可用，当然，我们已经学会了更好地理解数据。 人们知道将来的决策可能需要哪种数据，因此他们不会像以前那样丢弃大量数据。
我们研究的目标是弥合自主DBMS中的这一圈子。 与以前的工具一样，我们可以提出解决方案，但是算法不会自动依赖人-解决方案在您需要专门部署时是否正确，而是会自动完成。 然后，在反馈的帮助下，他将学习并随着时间的推移变得更好。
我想谈谈我们目前在卡耐基梅隆大学从事的项目。 在它们中，我们以两种不同的方式解决问题。
在第一个-OtterTune中，我们寻找调整数据库的方法，将它们视为黑匣子。 也就是说，在不控制系统内部部分而仅观察响应的情况下
调整现有DBMS的方法。
考虑到系统应该自主运行的事实，Peloton项目是关于
从头开始创建新数据库的 。 需要制定哪些调整和优化算法-无法应用于现有系统。
让我们按顺序考虑两个项目。
水獭
我们开发的现有系统调整项目称为OtterTune。
想象一下，数据库已配置为服务。 这样做的想法是，下载繁重的数据库操作的运行时度量标准会占用所有资源，并且建议的调节器配置也会作为响应，在我们看来，这将提高生产率。 它可以是延迟时间，带宽或您指定的任何其他特征-我们将尝试找到最佳选择。
OtterTune项目中的主要新功能是
能够使用先前调整
会话中的数据并提高后续会话的效率。 例如，采用PostgreSQL配置，该配置具有我们从未见过的应用程序。 但是，如果它具有某些特征或以与我们在应用程序中已经看到的数据库相同的方式使用数据库，那么我们已经知道如何更有效地配置此应用程序。
在较高级别上，工作算法如下。
假设有一个目标数据库：PostgreSQL，MySQL或VectorWise。 您必须将控制器安装在同一域中，这将执行两项任务。
第一种是由所谓的收集器执行的-收集有关当前配置数据的工具，即 查询从应用程序到数据库的执行时间指标。 收集器收集的数据将加载到优化服务Tuning Manager中。 数据库在本地还是在云中都可以使用。 下载后，数据将存储在我们自己的内部存储库中，该存储库存储了以前进行的所有测试设置会话。
在给出建议之前，您需要执行两个步骤。 首先，您需要查看运行时指标，并找出哪些指标真正重要。 以下示例显示了MySQL返回的指标，但在InnoDB上使用
SHOW_GLOBAL_STATUS 。 并非所有这些都对我们的分析有用。 众所周知，在机器学习中，大量数据并不总是好事。 因为那样的话，就需要更多的数据来将谷粒与谷壳分离。 在这种情况下，
重要的是要删除不重要的实体 。
例如，有两个度量：
INNODB_BUFFER_POOL_BYTES_DATA和
INNODB_BUFFER_POOL_PAGES_DATA 。 实际上，这是相同的指标，但是单位不同。 您可以进行统计分析，查看指标之间的高度相关性，并得出结论，将两者都用于分析是多余的。 如果您丢弃其中之一，则学习任务的规模将减少，并且获得答案的时间将减少。
在第二阶段，我们只对监管机构进行同样的操作。
MySQL中 有 500个调节器 ，当然，并不是所有
调节器都非常重要，但是不同的应用程序对不同的应用程序很重要。 有必要进行另一次统计分析，以找出哪些调节器确实影响目标功能。
在我们的示例中，我们发现三个
INNODB_BUFFER_POOL_SIZE ，
FLUSH_METHOD和
LOG_FILE_SIZE对性能的影响最大。 它们减少了事务性工作负载的延迟时间。
还有其他与监管机构有关的有趣观点。 在屏幕截图中，有一个名为
TIMED_MUTEXES的调节器。 如果您参考MySQL的工作文档，则在第45.7节中将指出此调节器已过期。 但是
机器学习算法无法阅读文档 ，因此不知道
该文档 。 他知道有一个可以打开或关闭的调节器，要花很长时间才能了解它不会影响任何东西。 但是您可以事先进行计算，然后发现调节器什么也不做，也不会浪费时间进行设置。
经过分析，使用
高斯过程模型 （一种相当古老的方法）将数据传输到我们的配置算法中。 您可能听说过深度学习，我们正在做类似的事情，但是没有深度网络。 我们使用
GPflow ，这是一个用于处理基于TensorFlow在俄罗斯开发的高斯过程模型的软件包。 该算法提出了一个建议，该建议应改善目标函数； 此数据将传输回控制器内部的安装代理。 代理通过执行重置来应用更改-不幸的是，它将不得不重新启动数据库-然后该过程再次重复。 收集更多的运行时指标，将其传输到算法，对提高和提高生产率的可能性进行分析，发布建议，依此类推。
OtterTune的关键功能是算法仅需要有关运行时指标的信息作为输入。 我们不需要查看您的数据和用户请求。 我们只需要跟踪读写操作即可。 这是一个有力的论据-属于您或您的客户的数据不会透露给第三方。 我们不需要看到任何请求，该算法仅基于运行时指标运行，因为它为监管机构提供了建议，而没有为物理设计提供建议。
让我们看一下OtterTune演示。 在该项目的网站上，我们将运行Postgres 9.6，并通过TPC-C测试加载系统。 让我们从初始PostgreSQL配置开始，该配置是在Ubuntu上安装时部署的。
首先，运行TPC-C测试五分钟，收集必要的运行时指标，将其上载到OtterTune服务，获取建议，应用更改，然后重复该过程。 我们待会儿会再谈这个。 数据库系统在一台计算机上运行，Tensor Flow服务在另一台计算机上运行，并在此处加载数据。
五分钟后，我们刷新页面（此部分结果的演示
此刻开始）。 刚开始时，在PostgreSQL的默认配置下，每秒有623个事务。 然后，在收到建议并应用一次更改之后，事务
数量增加到每秒2300 。 值得认识到的是，该演示已经启动了几次，因此该系统已经具有一组先前收集的数据。 这就是为什么解决方案如此之快的原因。 如果系统没有以前收集的数据会怎样？ 该算法是一种逐步的功能，逐渐可以达到这一水平。
经过一段时间和五次迭代，最佳结果是2600。我们从每秒600笔交易开始，能够达到2600的值。出现了小幅下降，因为算法决定在达到良好结果后尝试使用另一种调节调节器的方法。 结果是有余地，因此性能没有发生大幅度下降。 收到负面结果后，该算法重新配置并开始寻找其他调节方式。
我们得出的结论是，您不应该担心启动一个错误的策略，因为该算法将探索解决方案空间并尝试各种配置以达到SLA协议的条件。 尽管您始终可以配置服务，以便算法仅选择改进的解决方案。 随着时间的流逝，您将获得所有最好的结果。
现在回到我们的对话主题。 我将告诉您有关Sigmod中发表的
文章的现有结果。 我们使用OtterTune为TPC-C配置了MySQL和PostgreSQL，以提高吞吐量。
比较这些DBMS的配置，这些配置在Ubuntu首次安装时默认部署。 接下来，运行一些开源配置脚本，这些脚本可以从Percona和其他与PostgreSQL合作的咨询公司那里获得。 这些脚本使用启发式过程，例如必须为硬件设置特定缓冲区大小的规则。 我们还具有Amazon RDS的配置，该配置已经具有您正在使用的设备的Amazon预设。 然后将其与手动设置昂贵的DBA的结果进行比较，但要以它们具有20分钟并且可以设置所需参数的条件为条件。 最后一步是启动OtterTune。
对于MySQL，您可以看到默认配置远远落后于脚本，脚本工作得更好，RDS更好。 在这种情况下，数据库管理员-Facebook上领先的MySQL管理员显示了最佳结果。
OtterTune输给了男人 。 但是事实是，有一个特定的调节器禁用了日志清理的同步，这对于Facebook而言并不重要。 但是，我们拒绝访问此OtterTune调节器，因为算法不知道您是否同意丢失最后5毫秒的数据。 我们认为，此决定应由一个人做出。 也许Facebook同意这样的损失，我们不知道这一点。 如果我们以相同的方式调整此调节器，则可以与该人竞争。
这个例子说明了我们如何保守，因为最终决定必须由人来决定。 因为ML算法不了解数据库的某些方面。
对于PostgreSQL，配置脚本可以很好地工作。 RDS的性能稍差一些。 但是，值得注意的是，这方面的OtterTune指标超过了人。 直方图显示了由威斯康星州高级PostgreSQL专家顾问建立数据库之后获得的结果。 在此示例中，OtterTune能够找到日志文件大小与缓冲池大小之间的最佳平衡，从而平衡了这两个组件所使用的内存量并确保了最佳性能。
主要结论是，OtterTune服务使用了这样的算法和机器学习，与非常非常昂贵的DBA相比，我们可以获得相同或更好的性能。 这不仅适用于数据库的一个实例，而且我们可以将工作扩展到成千上万个副本，因为它仅仅是软件，而是数据。
佩洛顿
我要谈的第二个项目称为Peloton。 这是我们在卡耐基梅隆大学从头开始构建的全新数据系统。 我们称其为自我管理DBMS。
这个想法是要找出如果您控制整个软件堆栈可以做出更好的改变。 由于对系统的每个片段的了解，有关整个程序周期的知识，如何使设置比OtterTune更好。
它如何工作：我们将
具有增强功能的机器学习组件集成到数据库系统中，可以在运行时观察其行为的各个方面，然后提出建议。 而且，我们不仅限于调整调节器的建议，就像在OtterTune服务中发生的那样，我们希望执行我之前谈到的整个标准动作集：选择索引，选择分区方案，垂直和水平缩放等。
佩洛顿 系统的名称 可能会更改。 我不知道在俄罗斯如何，但是在我们美国，术语“细 气管球”的意思是“无所畏惧”和“完成”，而在法语中 ，术语 “排”。 但是在美国，有一家 Peloton 健身车公司 有很多钱。 每当出现提及他们的消息时，例如新开的商店或电视上的新广告，我所有的朋友都会写信给我：“看，他们偷了你的主意，偷了你的名字。” 广告中展示了骑着健身自行车的美丽人群，而我们根本无法与之抗衡。 最近， Uber宣布了一个名为 Peloton 的新资源计划器 ，因此我们不能再将其称为我们的系统。 但是我们还没有一个新名称，因此在本故事中，我仍将使用该名称的当前版本。考虑一下该系统是如何在高层次上工作的。 例如，以目标数据库为例，我重复一遍，这是我们的软件，这是我们使用的软件。 我们收集的工作负载历史记录与我之前显示的相同。 不同之处在于，我们将生成预测模型，以使我们能够预测未来的工作负载周期将是什么，未来的工作负载需求将是什么。 这就是为什么我们将此系统称为自我管理DBMS。
自我管理DBMS的基本思想类似于具有自动控制功能的汽车的思想。
一辆无人驾驶的车辆可以看到自己的前方，可以看到道路上前方的东西，可以预测如何到达目的地。 独立数据库系统的工作方式相同。 您应该能够展望未来，并就一周或一个小时内的工作量得出结论。 然后，我们将这些预测数据传递给在Tensor Flow上运行的计划组件-我们称之为大脑。
这个过程与伦敦AlphaGo作为Google Deep Mind项目一部分的工作相呼应，在顶层，所有工作都在类似的情况下进行：蒙特卡洛搜索树，搜索结果是必须执行的各种操作才能实现期望的目标。
以下算法大致确定操作方案：
- 源数据是一组必需的操作，例如，删除索引，添加索引，垂直和水平缩放等。
- 产生一系列动作，最终导致最大目标功能的实现。
- 除第一个条件外，所有条件都将被丢弃，并应用更改。
- 系统查看产生的效果，然后该过程一次又一次重复。
不要经常求助于无人驾驶汽车的比喻，但这就是它们的工作方式。 这称为计划范围。
观察道路上的地平线后，我们为自己设定了一个假想的点，然后我们开始计划一系列行动以达到地平线上的该点：加速，减速，左转，右转等。 然后，我们将所有需要执行的操作从脑海中抛弃，将其执行，然后再次重复该过程。 无人机每秒运行30次这样的算法。 对于数据库，此过程要慢一些，但思路仍然相同。
我们决定
从头开始创建自己的数据库系统
，而不是在 PostgreSQL或 MySQL 之上构建东西 ，因为老实说，与我们想要做的相比，它们太慢了。 PostgreSQL很漂亮，我很喜欢它，并且在我的大学课程中使用它，但是创建索引需要太多时间，因为所有数据都来自磁盘。
与汽车类似，可以将PostgreSQL上的自主DBMS与无人货车相比。 卡车将能够识别出道路前方的狗并绕着它走，但如果它在汽车正前方撞到车道上则无法。 因此，由于卡车的操纵性不足，不可避免地会发生碰撞。 我们决定从头开始创建一个系统，以便能够尽快应用更改并找出正确的配置。
现在，我们已经解决了第一个问题，并发表
了有关深度学习和经典线性回归相结合以自动选择和预测工作负载的文章。
但是还有一个更大的问题，对于这个问题，我们还没有一个好的解决方案-
行动目录 。 问题不在于如何选择动作，因为Microsoft的人员已经做到了这一点。 问题是，如何根据部署之前和部署之后发生的情况来确定一项措施是否胜过另一项措施。 如果人的命令创建的索引不是最佳的，该如何撤消操作，如何取消该操作并指出取消的原因。 此外，就我们自己的系统与外界的交互而言，还有许多其他任务，我们还没有解决方案，但我们正在努力解决。
顺便说一句，我将讲一个有关知名数据库公司的有趣故事。 该公司有一个自动索引选择工具，该工具有问题。 一位客户不断取消该工具推荐和应用的所有索引。 这种取消发生的频率很高，导致工具挂起。 他不知道进一步的行为策略应该是什么，因为提供给一个人的任何解决方案都会受到负面评价。 当开发人员转向客户并问：“为什么要取消所有关于索引的建议和建议？”，客户回答说，他只是不喜欢他们的名字。 人们很愚蠢，但是您必须对付他们。 对于这个问题，我也没有解决方案。设计自主DBMS
给定创建自治数据库系统的两种不同方法，现在让我们讨论如何设计DBMS使其具有自治性。
让我们关注三个主题：
再次回到关键点：数据库系统必须为机器学习算法提供正确的信息，以便随后采用更好的决策。 我们应该减少无用数据的传输量，以提高接收响应的速度。
, , , .
PG_SETTINGS , .
, , , .. , .
, , , , .
, , , .
:
- . , , .
- . , , -1 0, .
- , . , . 64- , 0 2 64 . , .
, . , 10 , , 10 . , .
- , . , , . , , , .
, , , . , . , , , — . , .
, , , . , .
, , . , : , , , , . - Oracle, , .
, , .
, , . , , , . - , , , . : PostgreSQL , .
, , , .
- , , , . , , . RocksDB, MyRocks MySQL.
RocksDB . , . , , , . RocksDB, .
, , , , . MyRocks . — :
ROCKSDB_BITES_READ, ROCKSDB_BITES_WRITTEN . , , . , . , .
, , , .
, , open source. , .
, ,
. MySQL , . , . 5 , 10 , , . 5 , — .
, . — PostgreSQL .
— . , . , , , , .
. , — SLA. , .
, . , . , . , .
, - , . , , - , . , , , — , -, , .
, , , .
, . , , , , 5- . downtime, .
, , , , , . , , , , .
Oracle autonomous database
Oracle . 2017 Oracle , . , Oracle, , « , Oracle 20 ».
. , , , , , . CIDR , . , : «, , , . , , , Oracle ?» , — ., , , Oracle. , .
,
— , , , - .
—
, . , , , 2000- . , Oracle , . , : , — - .
, . , , .
—
. , . : JOIN. . . , . .
Oracle. Microsoft 2017 SQL Server, . IBM DB2 00- , «LEO» — . , 1970-, Ingres. , JOIN, , . .
, , .
, , . , , . , , .
, , — , , , . , , , . , , .., .
HighLoad++ , HighLoad++ Siberia . , 39 , , highload- - .
HighLoad++ , . , UseData Conf — 16 , . , .