最近，微软详细介绍了分布式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/
本文文字及图片出自 InfoQ
你的反应是：