TimesTen Scaleout：极致OLTP的横向扩展架构

Oracle TimesTen Scaleout：一种用于极致 OLTP 的新型横向扩展内存数据库架构

1 引言

Oracle TimesTen内存数据库 [1] 是面向OLTP应用程序的行业领先的内存数据库，已被数千名客户采用。
TimesTen Scaleout 以 TimesTen 内存数据库 作为构建模块，是一种新型的无共享横向扩展内存数据库，专为 OLTP 工作负载设计。
TimesTen Scaleout 的架构支持在由节点或元素组成的集合或网格中实现透明的横向扩展。向 TimesTen Scaleout 网格中添加更多元素，可以提高整体内存数据库的读写事务吞吐量和容量。
除了弹性可扩展性，TimesTen Scaleout 还具备完整的 SQL、标准数据库API、ACID 事务、内置容错和高可用性。在接下来的章节中，我们将首先描述开发用于事务处理的通用横向扩展内存关系数据库管理系统所面临的挑战，然后提供一些性能结果。

2 数据分布

在任何分布式数据库中，表中的行必须分布在计算节点上，这是不言而喻的。与数据分布相关的设计挑战如下：

2.1 选择合适的数据分布策略

所有分布式数据库都面临如何将表的行分布在不同节点上的问题，并且必须解决最大化可扩展性以及数据访问局部性之间的冲突目标。
TimesTen Scaleout 通过支持相应的数据分布方案类型，力求实现以下三个目标：

目标1：在节点之间均匀分布大表
对于需要从多个元素访问的较大表，最具可扩展性的分布机制是哈希分布（使用一致性哈希 [2] 的变体）。这允许通过表中分布键的哈希值均匀分布表的内容。此分布方案在 TimesTen Scaleout 中为默认方案。

目标 #2：优化父子表之间的连接表
为了尽量减少远程元素访问，最好将子表行与其父行共置（例如，将客户与订单共置）。TimesTen Scaleout 提供了一种称为引用分布的分布方案来实现此目的。这种分布方式类似于 Oracle数据库 中的引用分区 [3]，可将子行和父行共置在同一元素上。此类分布还支持多级层次结构（例如，客户、订单和订单项）。这类父子访问在 OLTP 工作负载中极为常见。

目标 #3：优化对小型以读为主表的访问
小型且频繁访问的参考表可以在所有元素上进行完全复制。这使得涉及该表的所有查找和连接操作都可以在本地处理。复制非常适合小型、以读为主的维度表，例如价格表、目录表、项目列表等。
例如，为在线购物应用提供服务的数据库可能会使用以下分布方案：

表名	分布方案
C E	D
DE	按引用分发
加利福尼亚州	D

2.2 提供位置透明性

扩展型数据库必须提供单一系统映像。表中的行分布在多个节点上这一事实对于连接到数据库的应用程序应该是透明的。应用程序必须能够连接到任意元素，并高效地访问来自任何其他元素的数据。TimesTen Scaleout 中的分布式SQL执行计划包括函数迁移和行数据传输操作符，这些操作符对网格内数据的物理位置不敏感。

2.3 透明处理拓扑变化

扩展架构必须处理由于网格内节点数量变化而导致的在线重新配置。当网格缩小或扩大时，数据需要移动和重新平衡。在线分布式数据库系统面临的一个经典挑战是在数据重新分布期间发生的服务中断。
TimesTen Scaleout 的设计允许数据重新分布在后台进行。由于查询执行计划不依赖于行的物理位置，因此在数据重新分布期间，任何查询或 DML 仍可执行。

2.4 允许位置感知访问

在第2.2节中提到，TimesTen Scaleout 提供完全位置透明性。然而，存在一类性能关键型应用，它们能够从直接连接到托管相关数据的元素中获益。例如，当用户发起手机通话时，中间层应用层理想情况下会将该请求定向至托管该用户数据的元素。
TimesTen Scaleout 提供了用于此目的的数据依赖路由API，该API允许应用程序根据分布键的值将记录映射到元素。通过使用此API，数据位置感知的应用程序可以节省一些网络往返。

3 高可用性

硬件和软件故障是现实中的常态，必须在任何扩展架构中加以处理。扩展型数据库必须能够应对单个组件的临时或永久故障，例如：
1. 临时故障：网络故障、进程或主机崩溃可能导致临时故障或异常。
2. 主机永久故障：主机永久故障会导致所有进程丢失，并可能造成主机上存储的所有数据丢失。
3. 整个网格故障：数据中心断电或人为错误可能导致整个网格故障。
因此，TimesTen Scaleout 包含以下故障处理能力：

3.1 K‐安全性

每个元素都通过一种称为 K‐安全性的透明容错机制自动复制：事务所做的更改会在元素的所有副本之间自动复制。该元素的一组副本被称为副本集。可以从副本集中的任意元素读取和修改所有数据。只要每个副本集中至少有一个元素可用，数据库就会继续保持完全可用。

3.2 快速客户端故障转移

任何遇到故障（例如关闭的套接字或超时）的客户端连接将自动故障转移到一个活动元素。工作负载可以在重新连接后继续运行。在大多数情况下，应用程序受到的唯一影响是响应时间稍有延长。

3.3 故障元素的快速恢复与追平

故障元素可以通过从同一副本集内的同级元素获取日志进行追平，或通过复制其内容来恢复数据。在故障元素追平期间，DML 仍可在活动元素上继续运行，因此当某个元素发生故障时，不会造成数据库可用性的损失。

3.4 在线备份

可用一种在线备份机制，该机制可创建特定时间点备份镜像，之后可以从该镜像进行恢复，无论是在同一 TimesTen Scaleout 数据库内还是在不同的 TimesTen Scaleout 数据库中。

4 分布式SQL执行

TimesTen Scaleout 基于 TimesTen 内存数据库，支持功能完整的 SQL 语言。如前所述，TimesTen 内存数据库主要针对极端 OLTP 使用场景而设计。然而，它也非常适合混合联机事务处理（HTAP）应用程序，并支持用于报表和批处理操作的复杂SQL。
本节列出了一些值得注意的 SQL 执行引擎挑战：

4.1 高效的分布式访问

访问 TimesTen Scaleout 的应用程序通常不知道数据的位置。此类分布式系统面临的挑战是，无论数据位于何处，都要提供高效且一致的性能。OLTP 应用程序的一个要求是使带有等值谓词的简单 SQL 语句极为高效。
TimesTen Scaleout 可以保证此类 SQL 语句执行时最多只需要 2 次网络往返。事实上，如果谓词作用于表的分布键，则最多只需 1 次网络往返。

4.2 二级索引

对于哈希分布表，通过其分布键访问行是快速且高效的，因为可以通过分布键计算出行的位置。
通过非分布键查找行则更为困难。可以创建全局二级索引以优化查找。这样可保证查找行最多需要 2 次网络往返。但是，在插入/更新行时会带来额外开销，因为必须同时更新行及其索引。
或者可以创建本地二级索引。由于被索引的数据与数据本身共存，因此维护成本要低得多。对非分布键的查找将广播到网格的每个元素。在每个元素上，SQL引擎将使用本地索引来高效地查找行。每个元素都可以并行访问。

4.3 分布式连接

在分布式系统中，表之间的连接执行起来可能非常昂贵。
这是因为满足连接条件的行通常位于网格的不同元素上。
为了计算连接，必须先通过网络传输行，然后才能进行连接计算。
如果满足连接条件的所有行都共置在同一元素上，则连接操作会变得更加高效。因此，对于父子关系， TimesTen Scaleout 支持引用分布以实现父子行的共置，从而确保网络中不会发生行数据传输。

4.4 全局序列

在扩展型架构中，支持严格单调序列号通常开销很高。
每次序列更新都需要经过中央协调器，这会使中央协调器成为瓶颈。对于来自与协调器所在节点不同的节点的更新，还需要额外的网络通信。
另一种方法是保证一种较弱的单调性形式。在这种情况下，每个元素被分配一批序列号，并且在元素本地范围内访问序列号可确保单调性和高效性。每当一个元素用完一批序列号时，它会联系中央协调器获取新的一批。这意味着我们不保证网格中各元素之间的单调性。然而，对于大多数应用程序而言，这种较弱的排序形式通常是可接受的。

4.5 参照完整性

在分布式数据库中维护参照完整性可能是一个难以解决的问题，因为父记录和子记录可能位于不同的元素上。
在DML（插入/删除/更新）操作上强制实施完整性约束需要在多个元素之间追踪多层外键以保证一致性。在 TimesTen Scaleout中，用户可以选择使用引用分布将具有父子关系的行进行共置。如果行被共置，则参照完整性可以像在非分布式系统中一样高效地维护。然而，即使行未被共置，参照完整性仍然可以（以更高代价）得到维护。

4.6 物化视图

物化视图在分布式系统中增加了额外的复杂性。物化视图的容器表也是以分布式方式存储的。因此，与全局二级索引类似，物化视图也需要与其基表保持同步。物化视图面临一些与二级索引相同的挑战。

4.7 并行SQL执行

在分布式系统中，执行一条SQL语句通常需要访问网格中的多个元素。当应用程序执行SQL语句时，数据库引擎会计算一个查询计划，并确定哪些元素应参与执行。
为了最大化执行效率，相关元素将并行执行该计划。并行执行通常不需要用于OLTP操作，但对于应用程序中存在的报表和批处理操作而言至关重要（例如，在流式物联网工作负载中，确定在给定时间段内产生最高流量的设备）。TimesTen Scaleout支持并行SQL执行，从而使其成为HTAP应用的理想系统。

5 事务

许多系统通过牺牲事务保证来提供可扩展性。然而， ACID属性对于健壮应用至关重要。
任何分布式数据库上的事务都需要在多个元素上修改数据。分布式提交共识协议用于确保所有参与者之间提交决策的一致性。这些协议必须能够处理参与者（包括事务管理器）的故障。
无需人工干预，即可处理事务的任何阶段以及网络分区问题。
TimesTen Scaleout 通过在每个元素上使用本地存储进行检查点和事务日志的组合来提供事务持久性。默认情况下，为了提供最佳性能，数据库的更新会异步地写入磁盘。由于我们通过 K‐安全性 维护同一数据的多个副本，因此单个元素故障不会导致事务丢失。如果某些数据仅剩一个活动副本，则包含该副本的元素将立即把所有更改刷新到磁盘，并开始同步地将已 committed 的事务写入磁盘。这确保了即使承载最后一个副本的元素发生故障，所有对数据的更改仍然是持久的。对于必须立即实现持久性的重要事务，TimesTen Scaleout 提供了一种强制立即同步磁盘写入的功能。

6 横向扩展基础设施的管理

管理大型分布式系统中的所有主机和软件实例可能是一项挑战。要求数据库管理员在各个主机和实例上单独处理安装、配置和管理工作，既不可行也不具备可扩展性。
TimesTen Scaleout 通过提供集中管理实例来解决此问题。该实例不参与应用程序的 SQL 或事务执行，而是存储有关系统配置、拓扑以及各个组件状态的元数据。
它负责协调在所有已配置主机上的 TimesTen 软件的安装与配置。管理员无需登录其他主机即可完成这些管理操作。
管理服务可以在不中断已配置和部署的网格的情况下重启，但为了确保进一步的容错能力，TimesTen Scaleout 还提供了一个选项来配置第二个管理实例。该实例通过同步复制进行维护，如果第一个实例发生故障，它可以接管对网格的管理。

7 性能结果

TimesTen Scaleout 的性能通常使用电信提供商基准测试（TPTBM）进行衡量，该基准测试已随 TimesTen 数据库版本发布超过十年。此工作负载模拟了示例电信用户群体的行为。如下所示，在典型的 80‐20 读写事务混合情况下，TimesTen Scaleout 可实现每秒 1.44 亿个事务的性能；而在 100% 读取工作负载下，吞吐量超过每秒 12 亿次查询。这两项测量均在 Oracle云基础设施 上使用 64 台密集IO主机完成。

8 结论

总之，TimesTen Scaleout 是一种为高性能 OLTP 应用程序设计的横向扩展内存数据库。我们已经表明，设计企业级横向扩展内存数据库需要应对数据分布、高可用性、分布式SQL执行、分布式事务处理以及集中管理扩展架构等多个方面的挑战。TimesTen Scaleout 能够实现极高的事务吞吐量，超过每秒一亿个事务，同时也能量化极高的读取吞吐量，超过每秒十亿行。