在为Postgres运行性能基准测试时，主要建议是：“自动化！”如果您要测量数据库性能，您可能不得不一遍又一遍地执行同样的基准测试。要么是因为您想要稍微不同的配置，要么是因为您意识到自己使用了一些错误的设置，或者可能是其他原因。通过自动化运行性能基准测试的方式，当发生这种情况时您不会太恼火，因为重新运行基准测试只需要很少的努力（只需要一些时间）。但是，为数据库基准测试构建这种自动化也可能非常耗时。因此，在这篇文章中，我将分享我构建的工具，用于轻松地针对Postgres运行基准测试——特别是针对在AzureDatabaseforPostgreSQL中名为Hyperscale(Citus)的Azure托管数据库服务中运行的Postgres。Citus扩展名。https://docs.microsoft.com/azure/postgresql/hyperscale/https://github.com/citusdata/citus第一部分探讨了不同类型的应用程序工作负载及其特征，以及每一个常用的开箱即用的基准测试。之后，您可以深入了解如何在Azure上将HammerDB与Citus和Postgres结合使用。是的，您还会看到一些示例基准测试结果。为什么首先深入研究不同工作负载和数据库基准测试的背景？因为有比自动化运行性能基准测试的方式更重要的事情：为您选择正确的基准测试！针对不同工作负载的不同基准基准规范与完整的基准套件OLTP工作负载OLAP工作负载HTAP工作负载比较基准测试结果DangersHammerDBTPROC-C如何使用HammerDB、ARM、Bicep和cloud-init对Citus进行基准测试使用更大的Citus数据库集群达到200万NOPMonAzureEnjoybenchmarkingdatabaseperformance针对不同类型的工作负载的不同类型的基准测试每个使用数据库的人都将它用于不同的工作负载，因为每个人都有不同的数据集并运行不同的查询。因此，在比较数据库性能时，根据自己的工作负载运行基准测试将获得最准确的结果。然而，准备一个完全自定义的基准可能需要相当多的工作。因此，您可能希望使用与您自己的工作负载非常相似的工作负载来运行现成的基准测试。基准规范和完整的基准套件可以通过两种不同的方式为您提供现成的基准：基准规范。在这种情况下，文档中描述了如何运行基准测试。它将告诉您如何准备表、如何加载数据以及运行哪些查询。但是你需要手动完成所有这些。完整的基准套件。在这种情况下，您将获得一个运行基准测试的应用程序。您将基准应用程序配置为针对您的数据库服务器运行——一旦完成，它会吐出一些数字来表明它有多好。显然，一个完整的基准测试套件通常是您想要的，因为您可以简单地启动基准测试应用程序并获得结果。如果您只有一个基准规范，您首先需要编写工具来针对您的数据库运行该规范。OLTP（联机事务处理）工作负载数据库的常见工作负载类称为OLTP（联机事务处理）。属于OLTP类别的工作负载向数据库发送大量小型、短期运行的查询（或事务）。OLTP工作负载的一些特征是：插入、更新和删除只影响一行。示例：将商品添加到用户的购物车。读取操作仅从数据库中读取少数项目。示例：为用户列出购物车中的项目。聚合很少使用，当使用时，它们仅用于小型数据集。示例：获取用户购物车中所有商品的总价。创建此类工作负载的应用程序类型通常有许多并发用户，这些用户每秒共同执行许多请求。因此，对于OLTP工作负载，数据库能够同时处理大量此类查询非常重要。应用程序响应时间通常也很重要，因此数据库查询的运行时间不应太长。查询应始终在5秒内完成，大多数查询应在100毫秒内完成，甚至更快。属于OLTP类别的知名数据库基准测试有YCSB（全套）、TPC-C（规范）和HammerDBTPROC-C（全套）。人们通常对这些OLTP基准测试中的两种数字类型感兴趣：YCSB：https://github.com/brianfrankcooper/YCSB/TPC-C：http://tpc.org/tpcc/default5.aspHammerDBC:https://www.hammerdb.com/docs/ch03.htmlTPS吞吐量（每秒事务数）查询延迟，通常在不同的百分位（p95等）OLAP（联机分析处理）工作负载另一种常见的数据库工作负载称为OLAP（联机分析处理）。这是通常在数据仓库上运行的工作负载类型。OLAP工作负载的一些特征是：定期批量插入数据。新数据通常从其他系统批量添加到数据库中。这通常在一天中用户不使用数据库的特定时间完成，例如当地时区的午夜。读取操作通常会读取数据库的大部分内容。这样做的常见原因是回答业务分析师的问题，或者在季度股东大会上公布结果。需要的一些问题示例：去年销量最高的10种产品是什么？上个月有多少新客户加入？回头客产生了多少收入？几乎每个查询都使用聚合。而读取操作读取大部分数据库聚合对于使这些数据易于被人类消化是必要的。查询量大且复杂。为了回答一个查询，往往需要从几个不同的表中收集数据，或者需要将数据与同一个表中的不同数据进行比较。收集和组合这些数据的查询通常在单个查询中使用SQL的许多功能，例如JOIN、CTE、子查询和窗口函数。因为它们结合了如此多的特性，OLAP查询通常变得非常庞大和复杂。与OLTP不同，OLAP系统中的并发用户通常不多。通常一次只运行一个查询（或多个查询）。这些查询的响应时间也远高于OLTP工作负载。OLAP查询通常需要几秒钟甚至几分钟才能完成。但当然，数据库响应时间在OLAP工作负载中仍然很重要，等待查询结果超过20分钟通常是不可接受的。属于OLAP类别的著名基准测试有TPC-H（规范）、TPC-DS（规范）和HammerDBTPROC-H（全套）。这些基准测试以一组使用各种SQL功能的查询为特色，并具有不同级别的复杂性和JOIN数量。TPC-H：http://tpc.org/tpch/default5.aspTPC-DS：http://tpc.org/tpcds/default5.aspHammerDBTPROC-H：https://www.hammerdb.com/docs/ch11.htmlOLAP基准测试可以为您提供两种不同的结果：运行作为基准测试一部分的所有查询需要多长时间运行每个查询需要多长时间，以及每个查询单独测量HTAP（混合事务/分析处理）工作负载另一个类别数据库工作负载称为HTAP（混合事务/分析处理）。此类别包含结合了OLTP和OLAP工作负载的各个方面的工作负载。因此，会有许多活跃用户在运行一些长时间运行的繁重查询时进行小额交易。对HTAP工作负载进行基准测试的挑战比较来自不同运行的HTAP基准测试的数据非常困难。这是因为每次运行基准测试时，您都会得到两个通常显示相反相关性的数字：OLTP部分的TPS吞吐量（每秒事务数）需要为OLAP部分运行分析查询每秒事务数增加，分析查询将需要更长的时间来运行。换句话说，当TPS增加时（好），OLAP查询需要更长的时间（坏）。有两个原因：更多的TPS通常意味着机器的资源（cpu/disk）更忙于处理OLTP查询。这样做的一个副作用是这些资源通常不能用于OLAP查询。一定比例的OLTP事务会将数据插入数据库。所以更高的TPS意味着数据库中的数据量会增长得更快。这反过来意味着OLAP查询将不得不读取更多数据，因此变得更慢。这些数字之间的负相关性使得很难最终确定一个HTAP基准测试运行的结果是否比另一个更好。只有当且仅当两个数字都更好时，你才能得出更好的结论。如果这些数字中的一个更好，另一个更差，那么这就变成了一个权衡问题：您可以决定您认为对您的工作负载最重要的因素：每秒OLTP事务数，或的时间。比较您在网上找到的基准测试结果的危险与其自己运行基准测试，不如比较其他人在线发布的数据。比较其他人运行的基准测试时要小心：配置基准测试的方法有很多种。因此，比较它们通常是苹果和橘子。几个重要的区别是：它是在生产基础设施上运行的吗？当关键的生产功能被禁用时，通常可以实现更高的性能。备份、高可用性(HA)或TLS等安全功能等因素会影响性能。使用的数据集有多大？它适合RAM吗？从磁盘读取比从RAM读取慢得多。因此，如果所有数据都适合RAM，那么对于基准测试的结果非常重要。硬件太贵？显然，预计每月花费500美元的数据库的性能将低于每月花费50,000美元的数据库。使用了什么基准实现？许多供应商发布了TPC基准测试规范的结果，其中基准测试是使用规范的自定义实现运行的。这些实现通常未经验证，因此可能无法正确实现规范。因此，虽然比较您在网上找到的数据库基准测试数字是最简单的，但您可能还想用自己的数据运行自己的基准测试。用于OLTP工作负载的HammerDBTPROC-CHammerDB是一个易于使用的开源数据库基准测试套件。HammerDB可用于运行OLTP或OLAP基准测试。OLTP称为TPROC-C1，基于TPC-C规范。OLAP基准称为TPROC-H，它基于TPC-H规范。HammerDB为许多不同的数据库实施了这些基准测试，这使得比较不同数据库类型的结果变得容易。HammerDB：https://www.hammerdb.com/TPC-C：http://tpc.org/tpcc/default5.aspTPC-H：http://tpc.org/tpch/default5.asphttp://tpc。org/tpch/default5.asp我已经向HammerDB提交了几个PR以改进基准套件。其中一个PR使HammerDBTPROC-C与Citus的Postgres扩展一起工作（因此与分布式PostgreSQL一起工作）。另外两个大大提高了将基准数据加载到Postgres的速度。我所有的PR都已被接受并发布在HammerDB4.4中。因此，从HammerDB4.4开始，您可以针对Citus运行HammerDBTPROC-C基准测试。https://github.com/TPC-Council/HammerDB/pulls?q=is%3Apr+author%3AJelteFhttps://github.com/TPC-Council/HammerDB/releases/tag/v4.4HammerDB为基准测试运行提供的主要数字称为NOPM（每分钟新订单数）。HammerDB使用NOPM而不是TPS（每秒事务数）来使HammerDB支持的不同数据库之间的数字具有可比性。NOPM的测量方式基于官方TPC-C规范中的tpmC指标——尽管在HammerDB中它被称为NOPM而不是tpmC，因为tpmC在技术上用于官方的、经过全面审查的基准测试结果。https://www.hammerdb.com/blog/uncategorized/why-both-tpm-and-nopm-performance-metrics/HowtouseHammerDB,ARM,Bicep,tmuxandcloud-initonCitusonAzureBenchmarkingwithPostgres正如我在开头提到的，运行基准测试时最重要的事情是自动运行它们。根据我的经验，您将（几乎）重新运行相同的基准测试！因此，我围绕HammerDB创建了一个开源基准测试工具（GitHub存储库），以便更轻松地运行基准测试——尤其是针??对在Azure上运行的Postgres的Citus扩展。当您使用Postgres扩展时，涉及两层数据库软件：您同时在Postgres数据库和Postgres扩展上运行。因此，我为Citus创建的开源基准自动化在AzureDatabaseforPostgreSQL托管服务中的超大规模(Citus)选项上运行基准测试。https://github.com/citusdata/citus-benchmark/tree/master/azurehttps://docs.microsoft.com/azure/postgresql/https://docs.microsoft.com/azure/postgresql/hyperscale/的我创建的基准测试工具使用各种东西使运行基准测试尽可能简单：Bicep格式的ARM模板用于配置基准测试所需的所有Azure资源。它提供了您需要的主要内容：Citus数据库集群，特别是AzureDatabaseforPostgreSQL中的超大规模(Citus)服务器组。但它也提供了一个单独的VM来运行基准测试——这个VM也被称为“驱动程序VM”。https://docs.microsoft.com/azure/azure-resource-manager/bicep/overviewhttps://docs.microsoft.com/azure/azure-resource-manager/templates/overviewTmux用于在后台运行基准测试。没有什么比在5小时后重新启动6小时基准测试更糟糕的了，仅仅是因为您的互联网连接中断了。Tmux通过保持基准应用程序在后台运行来解决这个问题，即使您断开连接也是如此。https://github.com/tmux/tmux/wikicloud-init脚本用于启动基准测试。驱动程序VM的ARM模板包含一个cloud-init脚本，该脚本会在Postgres可访问时自动启动基准测试。这样，一旦开始配置过程，您就可以高枕无忧了。配置数据库和驱动程序VM后，基准测试将自动开始在后台运行。https://docs.microsoft.com/azure/virtual-machines/linux/using-cloud-init在撰写本文时，我创建的开源基准测试工具支持运行HammerDBTPROC-C(OLTP)和CH-benCHmark规范(HTAP)的自定义实现。但即使您想运行不同的基准测试，我创建的工具可能对您仍然非常有用。运行另一个基准测试时唯一应该改变的应该是安装和启动基准测试的cloud-init脚本的一部分。随时向存储库发送PR以添加对另一个基准测试的支持。https://github.com/citusdata/citus-benchmark/tree/master/azurehttps://github.com/citusdata/citus-benchmark/blob/6052801fad5c♂acfee203342bbe3c25f1d54b0/azure/driver-vm.bicep#L75-L81Citus数据库配置提示除了自动化基准测试外，在运行基准测试时还应牢记一些与Citus和Postgres相关的事项：不要忘记分发Postgres表面！大多数基准测试工具不内置支持使用Citus扩展分发Postgres表，因此您需要添加一些步骤来分发表。如果可能的话，最好在载入数据之前进行，这样载入数据会更快。选择正确的分布列。使用Citus分布式表时，选择正确的分布列很重要，否则性能会受到影响。什么是正确的分布列取决于基准测试中的查询。幸运的是，我们有文档，其中包含为您选择正确分布列的建议。https://docs.citusdata.com/en/v10.2/sharding/data_modeling.html构建数据集后，对所有表运行VACUUMANALYZE。否则，Postgres的统计数据可能完全错误，您可能会得到非常慢的查询计划。确保您的shard_count是您拥有的工人数量的倍数。否则，分片无法在您的工作人员之间平均分配，并且一些工作人员会比其他工作人员承担更多的负载。一个好的默认shard_count是48，因为数字48可以被许多数字整除。如何使用citus-benchmark工具运行HammerDB基准测试就像我说的，我试图让运行基准测试尽可能简单。所以你需要做的就是运行这个简单的命令（查看“azure”目录中的自述文件以获取详细说明）：https://github.com/citusdata/ch-benchmark/tree/master/azureazure/bulk-run.shazure/how-to-benchmark-blog.runs|tee-aresults.csv上述命令将开始在超大规模(Citus)生产基础设施HammerDBTPROC-C上的几个不同集群大小上运行，HammerDBTPROC-C是AzureDatabaseforPostgreSQLManagedService中的一个部署选项。这些基准运行的结果收集在results.csv文件中。当您查看新创建的results.csv文件时，您会看到类似“c4+2w8”的字符串：c4+2w8：这只是一个简短的方式来说明这个正在运行的集群有一个4vCore协调器（“c”)和2个工人("2w")，都有8个vCore。集群中存在的核心总数也显示在括号中。如您所见，随着您向Citus集群添加更多工作人员，NOPM不断增加。这表明Citus兑现了横向扩展的承诺：只需将更多Citus节点添加到AzureDatabaseforPostgreSQL的集群中，我们的性能就会得到提升。在Azure上使用更大的Citus数据库集群达到200万NOPM上图中的数字是使用相对较小的Citus集群收集的。此图表的主要目的是向您展示使用HammerDB和我创建的开源基准测试工具获取这些数字是多么容易。如果您增加每个数据库节点的vCore数量和/或增加Citus集群中工作节点的总数，您可能会在Azure上观察到更高的Citus基准测试结果。我们可以在SIGMOD'21接受的一篇论文中看到更高的性能和更多的vCores。我们使用了一个协调器和16个核心的8个工作器，那篇论文中的NOPM高得多。我们最近还在一个非常大的Citus数据库集群上运行了HammerDBTPROC-C，并使用我们在Azure上的常规托管服务基础设施实现了高达200万的NOPM。有关此2MNOPMHammerDB结果的更多详细信息：用于此基准测试的AzureDatabaseforPostgreSQL-Hyperscale(Citus)数据库集群有一个64核协调器和20个工作节点，每个节点有32个核心（因此总共有704个核心。）除了与本文前面讨论的示例相比，每个节点运行更多工作节点和更多vCore（有关详细信息，请参见上面的图2），需要修改另一件事以实现2MNOPM事情：HammerDB需要配置为使用更多并发连接.上面图2中所示的早期基准测试示例运行使用了250个连接，但为了让这个大型集群始终保持忙碌，我将HammerDB配置为使用5000个连接。AzureDatabaseforPostgreSQL中的Hyperscale(Citus)服务器组默认为协调器大小提供的连接数，系统将最大用户连接数设置为1000。如需增加，只需联系AzureSupport并请求将Postgres14上的最大用户连接数增加到至少5000-为了安全起见，多一点更好-对于您的超大规模(Citus)服务器组。因此，创建一个可以重现2MNOPM结果的超大规模(Citus)集群仅需一张支持票即可。之后，您可以使用我的基准测试工具在该集群上简单地运行基准测试。享受数据库性能基准测试的乐趣比较数据库或云提供商的性能似乎令人望而生畏。但是利用本博客中提供的知识和工具，在AzureDatabaseforPostgreSQL中对超大规模(Citus)的数据库性能进行基准测试应该容易得多。自己运行任何性能基准测试时，请确保：https://docs.microsoft.com/azure/postgresql/hyperscale/选择与您的工作负载相匹配的基准测试。您的工作负载属于OLTP、OLAP还是HTAP类别？自动运行基准测试。ARM、Bicep、tmux和cloud-init让运行数据库性能基准变得轻而易举。您甚至可以重复使用我编写的开源工具！https://docs.microsoft.com/en-gb/azure/azure-resource-manager/templates/overviewhttps://docs.microsoft.com/en-gb/azure/azure-resource-manager/bicep/overview?tabs=bicephttps://github.com/tmux/tmux/wikihttps://docs.microsoft.com/en-gb/azure/virtual-machines/linux/using-cloud-inithttps://github.com/citusdata/citus-benchmark/tree/master/azure是否要以自我管理的方式在Citus开源上运行您的应用程序是否要在托管数据库服务上运行应用程序在Azure上，使用Citus扩展Postgres很容易。https://www.citusdata.com/getting-started/
