作者 | Renato Losio
译者 | 平川
策划 | Tina
最近，微软详细介绍了分布式 PostgreSQL 基准测试的结果，比较了 Azure Cosmos DB for PostgreSQL、CockroachDB 与 Yugabyte 的事务处理性能和价格。这几种数据库在实现时做了不同的权衡，测试结果显示，Azure Cosmos DB 的吞吐量更高。同时，他还着重指出了针对分布式数据库进行基准测试所面临的挑战。
根据 GigaOm 基准测试，在事务性能和价格方面，采用 Citus 分布式表的 Azure Cosmos DB for PostgreSQL 优于 CockroachDB Dedicated 和 Yugabyte Managed 这两种全托管分布式数据库。
正如 InfoQ 之前的报道，随着不同的供应商对 PostgreSQL 这个流行的开源关系型数据库进行扩展、重新实现或创建分叉，它正在成为云分布式数据库的新标准。这项由微软赞助的基准测试使用了 HammerDB。这是一个用于对关系型数据进行基准测试的开源工具，由事务性能委员会（Transaction Performance Council，缩写为 TPC）负责管理。微软首席软件工程师 Marco Slot 写道：
GigaOM 使用 HammerDB TPROC-C 对 Azure Cosmos DB for PostgreSQL 和两个类似的托管服务产品（…）进行了基准测试。在最初的基准测试中，GigaOM 使用了 1000 个仓库，产生了大约 100GB 的数据。然而，CockroachDB 和 Yugabyte 的吞吐量之低令人惊讶。在不改变连接数的情况下，增加两者的仓库数量可以提升性能。
图片来源：https://devblogs.microsoft.com/cosmosdb/distributed-postgresql-benchmarks-using-hammerdb-by-gigaom/
有一个非常重要但颇有争议的点是 Citus 的使用。Citus 是 PostgreSQL 中一个用于分发表的开源扩展，它要求开发人员指定一个分发列，即分片键：
Citus 的核心理念一直是：分布式 PostgreSQL 是为大规模、高性能而生的，因为对于其他任何事情，PostgreSQL 都已经足够好。
测试的其他分布式数据库不依赖于分布式列的定义。在 Reddit 上，Slot 承认了其中的区别：
性能差异似乎有点尴尬。我想特别指出的是，使用 Citus 确实需要一些额外的步骤（例如 create_distributed_table）来定义分布式列和协同定位（否则，你只能使用单个节点）。我们的经验是，如果不对相关数据做协同定位，那么传统的事务型 PostgreSQL 工作负载的性能将比单个服务器差许多。
YugabyteDB 开发大使 Franck Pachot 在推特上谈到了这项基准测试，他提了一个问题：
这是比较 Citus（通过两阶段提交协议在 SQL 数据库上实现的分片）与 YugabyteDB 及 CockroachDB （通过全局 ACID 事务在分布式存储上实现的 SQL）吗？弹性、全局一致性、灵活性、自动划分 / 再平衡都不在同一个层次上。它们针对的是不同的用例。
该报告承认，对于不同的部署，不同的分布式数据库可能在不同的特性上胜出，包括响应时间、并发性、容错性、功能、一致性或持久性。Slot 总结道：
分布式系统，尤其是分布式数据库，涉及多个层面的权衡。CockroachDB 和 Yugabyte 做了不同的权衡，它们不需要分布式列（…）不管是扩展 Postgres（如 Citus 所做的），还是创建 Postgres 分叉（如 Yugabyte 所做的），亦或是是重新实现 Postgres（如 CockroachDB 所做的），每一种决定也都是一个权衡，都会对最终用户的体验产生重大的或好或坏的影响。
为了鼓励客户运行与其工作负载相匹配的基准测试，微软共享了辅助脚本，以便他们可以在 Azure Cosmos DB 上运行 HammerDB 基准测试。微软高级软件工程师 Jelte Fennema 展示了如何自动运行基准测试，包括集群设置和销毁。
按照 GigaOm 的说法，Google Spanner Postgres Interface 之所以不在比较范围，是因为该服务不提供运行基准测试所需的 Postgres 兼容性级别。
原文链接：
https://www.infoq.com/news/2023/07/distributed-postgresql-benchmark/
