作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/f1e59ca3

前言

随着企业数据需求的不断增长，它们越来越依赖于健壮且可扩展的数据库解决方案来管理这些数据。TiDB 和 Amazon Aurora 作为两种突出的技术，提供了独特的功能和优势。本文深入剖析并评估了 TiDB 和 Amazon Aurora 这两个数据库平台的独特特性、性能指标、可扩展性选项以及易用性。

产品架构

在比较 TiDB 和 Amazon Aurora 的架构差异时，需要深入了解这两种截然不同的数据库设计和管理方法。两种数据库架构都属于计算存储分离架构，这种设计对于大规模基于云的数据库至关重要，在可扩展性、可靠性和成本效率方面相对于传统的单体架构提供了显著的优势。

PingCAP 开发的 TiDB 提供了一个分布式 SQL 架构，强调通过多个扩展维度实现水平可扩展性。Amazon Aurora 采用了一种类似于传统关系型数据库的方法，但在存储可扩展性方面进行了重大改进。架构上的区别凸显了数据管理、可扩展性和性能优化的不同方法，也反映了现代企业在数据处理和管理方面面临的各种需求和挑战。

TiDB 架构

TiDB 的优势在于其计算和存储分离。TiDB 集群由以下三个主要组件组成，如下所示的图表所示：

1. TiDB server：这是一个无状态的 SQL 层，与 MySQL 兼容，将计算与存储解耦以简化扩展。每个节点都可以处理读取和写入操作。

2. Placement Driver (PD) ：PD 是一个集群管理器，可以实时动态平衡数据负载，缓解热点，并支持自定义调度策略的实现。

3. 存储服务器：这是一个分布式存储层，提供内置的高可用性和强大的 ACID 一致性，可以自动扩展到数百个节点和数 PB 的数据。

TiDB 的架构允许在多个维度上进行扩展，如数据量、并发性和查询复杂性，同时保持强一致性，并提供了云管理的额外好处。

Amazon Aurora 架构

Amazon Aurora 的架构也实现了计算和存储的分离。Amazon Aurora 的组件包括：

1. Aurora 数据库引擎：专为云构建，用于处理查询和事务。

2. 分布式、容错存储：自动跨多个可用区（AZs）进行复制。

Aurora 的设计重点在于读取性能、数据持久性和数据量的可扩展性，同时强调自动化管理任务。

对比分析

TiDB 和 Amazon Aurora 都提供了水平可扩展性。Aurora 的计算层类似于更传统的单主多读模型，而 TiDB 的架构则提供了多写多读实现的优势。其他不同点包括：

1. 数据一致性：TiDB 使用 Raft 一致性算法来确保强数据一致性，而 Aurora 则依赖跨多个可用区的写操作的 quorum 机制。

2. 灵活性：TiDB 的 MySQL 兼容性和其分布式特性为部署和扩展提供了灵活性。而 Aurora 与 AWS 生态系统更紧密地集成。

可扩展性对比

TiDB 可扩展性

TiDB 的可扩展性是通过其核心组件 TiKV、TiDB Server 和 TiFlash 来实现的，它们分别应对数据量、并发量和工作复杂工作负载的扩展需求。

使用 TiKV 扩展数据容量

TiKV，作为 TiDB 平台的核心分布式键值存储引擎，在 TiDB 中扮演着至关重要的角色。它负责以分布式的方式存储实际数据，并提供了以下关键功能：

• 可扩展性

TiKV 使 TiDB 能够根据数据量水平扩展。随着数据量的增长，可以简单地向集群中添加更多的 TiKV 节点。这样，数据就会被分散到更大数量的节点上，防止任何单一节点成为瓶颈。水平扩展是处理不断增长的数据量并保持高性能的关键。

• 数据分片

TiKV 自动将数据分割成小的、可管理的块或“区域”（regions）。随着数据量的增加，这些 Regions 会被分布到集群中的 TiKV 节点上，确保数据的均衡分布和存储可扩展性。这种分片策略不仅有助于管理和维护数据，还可以提高查询性能和系统的整体可扩展性。

使用 TiDB 扩展并发量

TiDB Server 是 TiDB 平台的 SQL 层，负责处理 SQL 查询。TiDB Server 将 SQL 查询转换为 TiKV 可以理解的键值操作，从而实现了 TiDB 与 TiKV 之间的交互。

TiDB Server 是无状态的，因此不需要持久化存储任何数据状态信息。这种设计使得 TiDB Server 可以很容易地进行水平扩展，以增加可以并发处理的读写连接数。

使用 TiFlash 扩展复杂工作负载

TiFlash 是 TiDB 的列式存储扩展，旨在高效地处理复杂的分析查询。它不仅能处理复杂的工作负载，还能实现实时 HTAP 能力。

• 复杂工作负载

TiFlash 允许 TiDB 随着工作负载复杂度的增加而扩展。对于涉及大量扫描、聚合和计算的分析查询，TiFlash 利用其列式存储架构提供了更快的查询处理速度。列式存储使得 TiFlash 能够仅读取查询中所需的列，而不是整行数据，从而显著减少了 I/O 开销并提高了查询效率。

• 实时 HTAP

TiFlash 通过实时从 TiKV 同步数据，实现了 HTAP 能力。这意味着同一个平台可以高效地处理事务性工作和分析工作负载，并随着这些工作负载的复杂性和需求的增加而扩展。TiFlash 与 TiKV 保持实时同步，确保分析查询能够访问到最新的数据。这种实时同步能力使得 TiDB 能够支持需要同时处理在线事务和离线分析的混合工作负载场景。

TiDB 的架构在多个维度上都具有出色的扩展能力，包括通过 TiKV 处理更大的数据量、通过 TiDB 服务器管理更高的并发性，以及通过 TiFlash 应对复杂的分析工作负载。这种多维度的可扩展性使得 TiDB 成为面对多样化和不断演变的数据管理挑战的企业的灵活且强大的选择。

Aurora 可扩展性

Amazon Aurora 的架构被设计用于跨不同维度提供可扩展性，主要关注数据量和读并发量。Aurora 数据库通过两个关键组件实现了这种可扩展性：分布式存储和额外副本实例。

使用 Aurora 分布式存储扩展数据容量

Aurora 使用了一种分布式、容错且能够自我修复的存储系统，该系统会随着数据量的增加而自动扩展。存储层与计算层是分离的，存储层支持：

• 自动扩展：Aurora 存储系统的一个显著特点是其能够自动以 10GB 为增量进行扩展，最高可达 128TB。存储容量会随着数据库的需求增长而增长，无需手动干预或停机进行扩展。

• 数据分布和持久性：Aurora 在多个可用区中存储数据的副本，确保了高持久性和可用性。这种存储的分布式特性还有助于数据库的整体性能和可扩展性，因为它允许对数据进行并行和分布式处理。

使用副本实例扩展读并发量

Amazon Aurora 允许创建最多 15 个读副本来处理高读取流量。这些副本与主实例共享相同的底层存储，从而最小化了复制延迟并确保数据一致性。其他功能包括：

• 负载均衡和读取扩展：读副本可用于平衡读取负载，有效地扩展数据库的容量以处理高水平的读取流量。这对于具有高读写比率的应用程序特别有用，主实例可以专注于处理写操作，而读副本则处理读查询。

• 提高可用性：除了为读取操作提供可扩展性外，这些读副本还增强了数据库的整体可用性和容错能力。如果主实例发生故障，其中一个读副本可以迅速提升为新的主实例，确保最小的中断时间。

Aurora 的架构通过创新的分布式存储系统解决了可扩展性问题。它不仅可以随着数据量的增长而轻松扩展，还通过使用读副本来为读取密集型工作负载提供可扩展性。这种双重方法使得 Aurora 能够高效地处理大型且不断增长的数据集，同时保持对读取密集型应用的高性能和可用性。

对比分析

TiDB 和 Aurora 在数据库可扩展性方面采取了不同的方法，每种方法都针对不同的使用案例和性能需求进行了定制。以下是关于这两种架构在 PingCAP 自己的比较测试中展现的一些关键点。

TiDB 提供了一个全面的可扩展性解决方案，涵盖数据量、并发性和工作负载复杂度三个维度。其组件——TiDB Server、TiKV 和 TiFlash——为事务性和分析型工作负载提供了水平可扩展性，这一特性通过其实时混合事务分析处理（HTAP）能力得到了增强。这使得 TiDB 特别适用于需要同时处理事务和实时分析的场景，为处理大型数据集、高并发和复杂查询提供了一种平衡的方法。

与 TiDB 不同，Aurora 专注于数据量和读取并发的扩展。其架构在自动扩展存储以管理大数据量方面表现出色。通过读副本，Aurora 可以显著提高读取吞吐量，从而为读取密集型应用提供显著的性能提升。

然而，Aurora 的架构在写入可扩展性方面显示出局限性，因为它依赖于单个主实例来处理写入操作。这种设计选择使 Aurora 成为具有高读写比率的应用程序的理想解决方案，其中管理大数据集和确保高读取性能是首要任务。对于写入密集型工作负载，Aurora 可能不是最有效的选择。

虽然 TiDB 和 Aurora 都提供了强大的可扩展性，但它们的架构差异使它们适用于不同类型的工作负载。TiDB 适用于需要平衡读写场景和实时分析的情况，而 Aurora 则更适合读取密集型应用且对大数据存储有较高要求的情况。

可靠性对比

比较 TiDB 和 Aurora 的可靠性时，需要考察它们如何处理数据持久性、容错性和整体系统稳定性。

TiDB 可靠性

TiDB 的分布式架构增强了其可靠性。数据在 TiKV 层被存储并在多个节点上复制，这意味着单个节点的故障不会导致数据丢失。默认情况下数据会被复制三份，副本数量也可由用户配置。TiDB 还提供了额外的功能来增强其可靠性：

• 自动故障转移：TiDB 提供了自动故障转移机制。如果 TiKV 节点发生故障，系统会自动为受影响的数据区域选举新的领导者，确保系统连续可用。

• 一致性和隔离性保证：TiDB 提供了强一致性和隔离性保证，这对于事务可靠性至关重要。它使用 Raft 共识算法进行数据复制，确保多个副本之间的一致性。

TiDB 的无状态计算层

TiDB 中的计算层 TiDB Server 是无状态的，这意味着这些 Server 本身不存储任何数据，而是处理 SQL 查询并与 TiKV 节点进行交互以进行数据存储和检索。TiDB 的无状态计算层对整体可靠性的影响主要体现在以下几个方面：

• 故障容忍: 由于数据存储在分布式的 TiKV 节点中，即使发生服务器故障，其他 TiDB 服务器也可以继续处理请求而不会出现任何数据丢失。

• 扩展性和负载均衡: TiDB 的无状态计算层使得 TiDB 服务器可以轻松地扩展以处理增加的负载。通过添加更多的 TiDB 服务器，系统可以水平扩展以应对更高的查询请求量。这种可扩展性确保了系统即使在重负载下也能保持性能和可靠性。

• 简化运维及升级: 由于 TiDB 服务器是无状态的，它们可以独立地进行升级、维护和替换，而不会对数据的可用性或完整性造成影响。这大大简化了运维任务，降低了因维护操作导致系统停机的风险。

Aurora 可靠性

Aurora 的分布式、自我修复存储系统通过跨多个可用区自动复制数据，实现了高数据持久性和可用性，从而降低了数据丢失的风险：

1. 读副本故障转移：Aurora 通过其读副本功能增强了可靠性。在主实例出现故障的情况下，Amazon Aurora 可以将一个读副本提升为主实例，从而最小化停机时间。

2. 备份和恢复：Aurora 提供连续备份到 Amazon S3，并支持时间点恢复（PiTR）。这确保了可以在保留期间内的任何一秒恢复数据，从而增强了数据保护。

3. 隔离性和持久性：虽然 Aurora 提供了 ACID 保证和隔离级别，但其对读扩展性的关注意味着写操作集中在主实例上。这可能会成为单点故障，但由其强大的备份和恢复机制所缓解。

对比分析

TiDB 通过多个组件的分布式特性，提供了高度的容错性和数据冗余。Aurora 依靠其健壮的存储层和跨多区域的复制来确保数据的持久性。这两个系统都提供了以下功能：

• 故障转移和恢复：TiDB 的故障转移发生在其分布式节点内部，而 Aurora 则通过提升读副本来实现故障转移。

• 数据保护：连续备份和时间点恢复（PiTR）是 Aurora 的强项，而 TiDB 通过其分布式架构和实时同步机制来确保数据保护。

• 单点故障：TiDB 的分布式架构最大程度地减少了单点故障的可能性。相比之下，Aurora 的写操作依赖于主实例，这可能是一个潜在的弱点，尽管通过其备份和恢复功能得到了缓解。

TiDB 和 Aurora 都提供了高可靠性，但它们的实现方式有所不同。TiDB 的分布式架构提供了固有的冗余和容错能力，而 Aurora 则依赖于其健壮的存储系统以及有效的备份和恢复机制来确保数据的持久性和系统的稳定性。

多租户能力对比

TiDB 提供了两个非常有趣的功能：放置规则（Placement Rules）和资源控制（Resource Control）。当这两个功能一起使用时，它们能够实现复杂的数据管理和隔离，这在多租户环境中特别有用。

这些功能是 TiDB 独有的，Aurora 中并不具备，它们允许对数据放置和资源分配进行精细控制，使得 TiDB 成为需要复杂多租户配置的场景中极具吸引力的选择。

放置策略

TiDB 中的放置规则（Placement Rules）旨在控制集群内数据的物理位置。它们允许管理员指定数据如何在各个节点之间分布。这对于优化性能、确保数据本地性、以及遵守数据主权和隔离要求至关重要。

通过放置规则，可以基于地区、区域或主机等因素来指定数据的存储位置。这在多租户环境中特别有用，因为出于法律或性能原因，不同租户的数据可能需要被隔离或存储在特定的位置。

资源管控

TiDB 中的资源控制（Resource Control）负责管理和分配 CPU、内存等系统资源。它支持将查询和事务进行逻辑分组，以实现差异化的资源分配和管理。

通过使用资源控制，管理员可以确保不同的租户或工作负载获得适当的资源。在多租户设置中，这是至关重要的，因为它有助于防止资源竞争并确保公平的资源分配。

Placement 规则和资源控制在多租户部署中的组合是 TiDB 独有的功能。尽管 Aurora 提供了强大的性能和可扩展性特性，但它并未为多租户提供同样精细程度的数据放置和资源分配控制。

价格与成本对比

比较 TiDB 和 Aurora 的定价涉及到理解它们各自的定价模型。这些模型受到资源使用、存储、网络和附加功能的影响。定价可能会因地区、实例类型和特定配置的不同而有所变化，而且这两个服务可能都会为长期承诺提供不同的定价层级或折扣。

TiDB 价格

TiDB 的全托管云部署选项采用了基于资源的定价模型。费用是根据所消耗的计算和存储资源来计算的，这包括 TiDB、TiKV 和 TiFlash 节点的大小和数量。其他定价元素包括：

• 可扩展性和灵活性：定价可以根据使用情况进行调整，这意味着随着资源的扩展，需要支付更多费用，而当减少资源时，费用也会相应减少，为不同工作负载提供了灵活性。

• 额外成本：额外成本可能包括网络带宽、备份存储和数据传输费用。这些费用可能会根据传输的数据量和特定用例而有所不同。其中一些费用以请求单位（Request Unit，简称 RU）作为计量单位来表示。TiDB 中有多种服务采用 RU 作为其成本结构的计量单位，这些服务包括入站数据迁移和出站变更数据捕获（CDC）。

• 免费层：TiDB 提供了以 TiDB Serverless 形式提供的免费层，最多可支持 5GB 的数据和每月 5000 万个 RU。这允许开发人员在承诺付费计划之前先试用该服务。

Aurora 价格

Aurora 的定价主要基于运行的实例。这包括每个数据库实例类型每小时的费用，这些费用根据实例的容量和性能而有所不同。其他定价元素包括：

• 存储和 I/O 成本：除了实例成本外，Amazon Aurora 还会收取数据库存储和 I/O 吞吐量的费用。存储成本是按 GB- 月计算的，而 I/O 成本则基于请求的数量。

• 备份和数据传输成本：Amazon Aurora 提供自动备份功能，并为此类备份的存储收取费用。此外，数据传输费用也适用，特别是针对从 AWS 环境外部传输的数据。

• 只读副本成本：如果使用只读副本来扩展读取操作，这些副本的收费与主实例类似。

对比分析

TiDB 的定价更侧重于整体资源使用情况，包括计算和存储节点。而 Aurora 的定价则主要基于实例，并额外收取存储和 I/O 操作的费用。以下是两者之间的更多关键差异：

• 可扩展性成本：两个服务都会随着使用量的增加而调整成本，但它们的扩展方式不同。TiDB 提供了更精细的计算和存储独立扩展选项，这对于某些工作负载来说可能更具成本效益。

• 备份和数据传输：两个服务都会对备份和数据传输收费，但这些费用的具体规定可能有所不同。

• 免费层和试用期：两个服务都可能提供免费层或试用期，这对于新用户评估这些平台非常重要。

虽然 TiDB 和 Amazon Aurora 都提供了可扩展的、按需付费的定价模型，但它们的定价结构细节有所不同。这反映了它们架构上的差异和针对的用例。用户应该考虑他们的具体需求，包括资源需求、可扩展性和附加功能，以确定对其用例来说最具成本效益的解决方案。

结论

TiDB 作为一个高度灵活和可扩展的解决方案脱颖而出，尤其擅长处理需要实时事务处理和分析处理的复杂、数据密集型场景。其分布式架构，包括 TiKV、TiDB Server 和 TiFlash，提供了跨多个维度的无与伦比的可扩展性，确保即使在要求最苛刻的应用环境中也能提供稳健的性能。此外，TiDB 在多租户部署中的独特功能提供了 Amazon Aurora 无法提供的数据管理和资源分配水平。

Aurora 专注于 AWS 生态系统内的读取可扩展性和自动化管理，非常适合读写比例较高的应用。其架构强调数据量的可扩展性和读取并发性，使其成为寻求可靠、云原生关系型数据库服务的高读取并发企业的有力竞争者。然而，与 TiDB 相比，Aurora 在写入可扩展性方面的限制以及对多租户控制的粒度较低可能是某些用例的决定性因素。

最终，选择 TiDB 还是 Aurora 将取决于工作负载的具体要求、读写操作之间的期望平衡，以及对高级多租户功能的需求。

引用

本文引用及翻译自《Amazon Aurora vs TiDB 白皮书》