YugabyteDB 2.0 版本的外围性能之一是与 PostgreSQL 兼容的 YugabyteDB SQL（YSQL）API。在这篇文章中，咱们将从性能和可扩展性两个方面，比拟 YSQL 与其余两个兼容 PostgreSQL 的分布式 SQL 数据库——Amazon Aurora PostgreSQL 和 CockroachDB。
SQL 基准测试表明，YSQL 的可扩展性是 Amazon Aurora 能达到的最大吞吐量的 10 倍。此外，对于相似的硬件配置，YSQL 和 Amazon Aurora 相比，吞吐量进步了近 2 倍，提早却只有后者的一半。
分布式 SQL 数据库将 RDBMS 的 SQL 语言和事务处理性能与 NoSQL 数据库特有的云原生性能，例如高可用性，可伸缩性，容错性和地理分布，联合在一起。
基准设置
下表总结了这些数据库的设计要点。咱们在这里明确不思考 Aurora PostgreSQL 的多主机设置，因为它侵害了数据的一致性。
写性能在本文中，咱们将钻研这些数据库以下几个方面的性能和可扩展性：
扩大写
扩大读
扩大连贯
分布式事务
以下所有基准测试都是在 AWS 云的俄勒冈区进行的。YugabyteDB 2.0 部署在一个跨多可用区的类型为 i3.4xlarge 的三节点群集上（每个节点上有 16 个 vCPU）。整个部署架构能够显示为上面的 UI 屏幕截图。
CockroachDB（版本 19.1.4）配置与 YugabyteDB 雷同。Aurora PostgreSQL 部署在类型为 db.r5.4xlarge 的双节点上（每个节点上有 16 个 vCPU）。一个节点是主节点，另一个节点是备用节点，用于在其余可用区中进行疾速故障转移。此设置如下所示。
请留神，CockroachDB 仅反对串行化隔离，而 YugabyteDB 和 Amazon Aurora 同时反对串行化和快照隔离。Amazon Aurora 甚至反对较低的提交读隔离级别，这也是它的默认设置。这篇文章中的基准测试应用所有数据库中的默认设置，对于只有简略插入和非汇集索的程序来说，这些默认设置足以保障正确性。
写性能
在这个基准测试中，咱们将 5000 万的惟一键值数据用预编译绑定的 INSERT 语句，插入了具备 256 个线程并发写入的数据库。在此期间，没有对数据库的读操作。基准后果如下所示。
这些数据仅仅是展现 YSQL 性能的开始，YugaByteDB 的外围存储引擎 DocDB 同时反对 YSQL 和 YCQL，具备更高的吞吐量。和 YSQL 很类似并且运行在 DocDB 上的半关系型 YCQL API 更加成熟，因而性能更好，如下图所示。
咱们正在 YSQL 查问层中进行其余改良，以实现更好的性能来以匹配 YCQL。
写扩大
那当咱们须要扩大时怎么办呢？
咱们曾经在上表中指出，AWS Aurora 无奈程度扩大写入。在 Aurora 中扩大写入的惟一办法是垂直扩大，这意味着必须使单个节点更坚硬。就 vCPU 而言，Aurora 的最大扩大写 IOPS，取决于 vCPU 的最大可用节点。
YugabyteDB 每秒写入量超过 100 万
因为 YugabyteDB 既具备高性能又具备程度可扩展性，因而咱们筹备用一个试验将每秒的写操作扩大到百万级别。试验抉择了型号为 c5.4xlarge 的实例，部署在单可用区，领有 100 个节点的 YugabyteDB 集群上（每个节点 16 个 vCPU 和 1TB 存储）。该集群名为 MillionOps，如下图所示。
该群集可能实现每秒 126 万次的写入，提早却仅有 1.7ms！
Aurora PostgreSQL 每秒 168K 的写入瓶颈
上述基准测试后果（每秒写入 28K）是运行在具备 16 个 vCPU（db.r5.4xlarge 实例）的机器上。可是 Aurora 可用的最大实例具备 96 个 vCPU（db.r5.24xlarge 实例），资源比上述基准测试所用的 16 个 vCPU（db.r5.4xlarge 实例）多 6 倍。假如写入随着机器大小扩大，那么具备多个表的 Aurora 数据库的最大写入吞吐量的下限为每秒 168K。即便 Amazon Aurora 能够存储多达 64TB 的数据，但这种吞吐量瓶颈仍将在可用存储的利用方面带来理论挑战。在达到写吞吐量下限之后，惟一的抉择是在应用程序层将数据层手动分片，这是一项简单的工作。
相比之下，YugabyteDB 集群的每秒写入量随节点数线性扩大。一个具备 12 个节点的 YugabyteDB 集群可能超过下面提到的每秒 168K 的写入吞吐量。下图比拟了这两个数据库的写扩大性能。
读扩大
两种数据库都能实现读扩大，然而：
Aurora 中读扩大实现的同时，提供了过期的读数据，就义了数据的一致性。
如果必须在 Aurora 中查问只读正本，那么利用程序设计可能会变得更加简单。
让咱们看看如何在这些数据库中实现读扩大。
为了扩大数据库，Aurora PostgreSQL 文档形容了以下内容。
咱们曾经发现了实例扩大会带来写入吞吐量的下限。让咱们来看看 Aurora 中的读扩大。读和写在 Aurora 中是独自离开的节点在执行。为了进行读扩大，应用程序要负责从多个读端点中进行显式地读取。
首先，这意味着应用程序须要在设计中明确蕴含要连贯的端点。这升高了应用程序的开发速度，因为要连贯到哪个端点成为应用程序体系结构的一部分，并且可能不是一件容易的事，尤其是在设计故障转移计划的时候。
其次，更重要的问题是，从正本中读取数据将返回过期的数据，这可能会侵害数据的一致性。为了读到实在的数据，应用程序必须从主节点读取数据（这个主节点还解决所有写操作）。因为单个节点须要保障读统一，因而这个架构的读吞吐量取决于最大节点的性能（相似于咱们对写性能所做的剖析）。
相比之下，YugabyteDB 将所有节点视为完全相同。这能够通过以下形式改善性能：
应用程序只须要连贯到集群中的一个随机节点，其余的由数据库解决。数据库的所有节点都能够放在一个负载均衡器前面。
执行读取时，群集的所有节点都能够参加，因而读取吞吐量要高得多。
用集群感知的 JDBC 驱动程序打消负载均衡器
为了进一步简化操作，咱们正在钻研规范 JDBC 驱动程序的集群感知版本，称为 YugabyteDB JDBC。这些驱动程序能够连贯到集群的任何一个节点，并从由 YugabyteDB 主动保护的集群成员中“发现”所有其余节点。
诸如节点增加，删除和故障之类的事件被异步推送到这些客户端驱动程序，从而导致应用程序时候取得最近的集群成员身份信息。应用反对群集的 JDBC 驱动程序，咱们不再须要手动更新负载均衡器前面的节点列表或治理负载均衡器的生命周期，从而使根底构造变得更加简略和麻利。
扩大连贯
扩大连接数是 PostgreSQL 广泛关怀的问题。Aurora PostgreSQL 数据库的连接数是有限度的。下表从 AWS 文档中总结了不同实例大小下，倡议采纳的数据库连接数。
该表显示，即便在最大的 Aurora PostgreSQL 数据库中，倡议的最大连接数也才为 5000（只管文档中提到的实践最大值为 262,142）。这限度了具备许多微服务和大规模的云原生应用程序的性能。
YugabyteDB 能够在集群中的每个节点上指定连接数。每个节点的默认连接数是 300（可配置），在咱们的示例中设置 3 个节点，最多可取得 900 个连贯。然而扩大连贯很容易。通过抉择 6 个具备 8 个 vCPU 的实例（而不是 3 个具备 16 个 vCPU 的实例），咱们无效地将连接数减少了一倍，达到 1.8K，同时放弃资源不变！同样，通过抉择具备 8 个 vCPU 的 24 个实例（大抵相当于具备 96 个 vCPU 的最大 Aurora 群集），部署能够扩大到超过 1 万个连贯。
分布式事务——提早 VS 扩展性
YugabyteDB 是一个能够程度写扩大的数据库。这意味着集群的所有节点都同时处于激活的状态（而不是像 Aurora 那样仅是一个主节点）。为了实现程度写的可伸缩性，数据被无缝地分成小块，称为分片，而后将他们散布在集群的所有节点上。
当 YugabyteDB 须要执行分布式事务时，它须要在不同的分片上执行写操作，最终是对近程节点的 RPC 调用。这样的后果是，数据库可能必须通过网络执行 RPC 调用能力解决用户终端的事务，这会同时影响到最终用户看到的提早和吞吐性能。应用 Amazon Aurora，整个事务在主节点上进行解决，没有近程 RPC 调用。
这成为两种设计的根本架构折衷，因而在抉择之前须要认真思考。然而原始性能数据是什么样的呢？为了确定这一点，咱们执行了一个基准测试，将 500 万惟一键值数据插入到一个具备非汇集索引列的数据库表中。在此期间没有对数据库的读操作。
应用基准测试剖析衡量计划
以下是这些分布式 PostgreSQL 数据库中非汇集索引基准测试的后果。这些基准测试应用 128 个写线程并行写了 500 万个事务（每个事物写两个键）。这些基准测试是通过上述列出的标准配置执行的。
YugabyteDB 在执行波及主表和索引的多分片分布式事务之前，须要进行 3 - 4 次近程 RPC 调用。这导致了绝对更高的提早和更低的吞吐量。在上述基准中，YugabyteDB 事务的写提早为 22ms，而 Aurora PostgreSQL 仅为 6ms。此外，一个 3 节点（16 vCPU）YSQL 集群的写吞吐量仅为 5.3K，而 Aurora PostgreSQL 的写吞吐量却为 20K。
让咱们来看看当扩大上述写入的工作量时会产生什么。咱们在前一节曾经探讨过，Aurora PostgreSQL 最多只能扩大到 96 个内核，或者说，Aurora PostgreSQL 所有通过应用程序和索引执行在各种表上事务的写入下限为每秒 120K。通过 YugabyteDB，一个 63 节点的集群每秒能够传递 120K 事务，一个 106 节点的集群每秒能够传递 200K 事务。
这意味着，如果您的数据库实例永远不须要解决超过每秒 120K 的事物量，Aurora PostgreSQL 会是一个很棒的抉择。如果未来扩充规模很重要，那么 YugabyteDB 会是一个更好的抉择。
留神，本节中的剖析仅实用于写入事务，读取不受此剖析影响。