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会是一个更好的抉择。

留神，本节中的剖析仅实用于写入事务，读取不受此剖析影响。