300万运算/秒 ：VoltDB在电信行业基准测试上可线性扩展性能

01 总 体 概 述

VoltDB受到全球电信软件解决方案提供商的信赖，后者将其作为首选内存数据库来驱动他们部署在全球100多家运营商处的任务关键型应用。VoltDB受到青睐的原因在于其性能和功能不仅能够解决当前挑战，而且还能支持业内各种系统的快速发展。

我们的下述基准测试展示了VoltDB的性能如何满足或超越电信系统的要求，展示了 VoltDB具备的驱动诸如5G 之类的行业革命所需要的高性能、低延迟和线性扩展。

在这个基准测试中，我们在云中测试了VoltDB v8.3，然后观察到了可以随服务器数量线性扩展的性能以及超过300万次运算/秒的速度，并且自始至终只有个位数的延迟。

1.VoltDB和5G发展

5G的出现给电信软件解决方案提供商带来了一些重要挑战。除了新的硬件标准，这种网络进化也需要OSS和BSS的支持IT功能发生转变。通过新服务创建创造额外收入的机会要求OSS和BSS功能具有灵活性和可扩展性， 以便在不断增加的负载下实现新的用例。

这种对系统的要求提升了支持数据库的重要性，其功能不再是简单地存储数据，而是充当一个活跃的实时决策系统。

简而言之，VoltDB是一个电信级数据库，它完全满足主动实时决策系统的要求，例如支持 5G 可能所需要的系统。VoltDB是一个内存关系数据库，具有极其重要和毫不折衷的可扩展性、可编程性和一致性。基于VoltDB构建的应用，无论是在电信、金融还是在零售领域，均具有水平可扩展性，经得起复杂性演变的检验，并且在一致性和正常运行时间方面十分可靠。

理论上，解决方案可由多个用于流、集群管理、数据库存储和内存缓存的开源工具来拼凑，但实际上，这些解决方案达不到要求。它们通常会增加系统间的延迟，在大量服务器上管理多个软件堆栈时的运营成本很高，并且在检测和管理一致性和正确性时会产生客户端编程负担。

VoltDB不仅是高性能数据库，它还提供驱动任务关键型实时电信应用所需的核心架构元素：

• 严格符合ACID要求
• 物化视图、预存程序和用户定义的函数
• 内在高可用性、灾难恢复和多站点跨数据中心复制
• 云/容器准备就绪
• 导入/导出流

当涉及到嵌入正确的数据库来驱动5G应用时，没有任何折衷空间。拥有成熟的企业级数据库（不只是特性和功能，也包括全天候支持和娴熟的专业服务）对于5G的成功至关重要。

02 基 准 测 试

2.1 在线计费系统

在线计费功能是了解5G在系统层面带来的挑战的理想示例。对于不断增加的设备多样性，解决方案不仅必须应对来自数十亿台新连接的设备的连接负载，而且还必须应对执行不同策略的复杂性。

因此，5G网络中的在线计费必须能够随负载和功能复杂性扩展，同时不在一致性或性能方面做出妥协。

2.2 为什么我们需要ACID ?

这些应用的系统架构采用不同的方法来处理这些挑战的影响。大多数应用使用键值存储来获得他们所谓的无限可扩展性的好处，但是这些应用被迫使用自定义机制来实现事务，从而产生一个复杂的系统，这种系统无法兑现关于简单性和可扩展性的最初承诺。

即使最快的键值存储也需要额外的客户端-服务器通信及定制封锁和一致性检查，所有这些都将增加延迟和网络负担。

另一方面，使用传统数据库进行扩展的问题众所周知。我们认为VoltDB 在当今的数据库市场中占据一个独特的位置，它不仅可以解决可扩展性和复杂性的挑战，同时能够保证最高一致性的、严格序列化的ACID事务。

2.3 实现细节

我们测试了由Google Cloud Platform提供的3、9、18 和27节点集群构建的VoltDB 数据库实例，工作负载模拟了一个简化的在线计费应用，预载数据之后，基准测试应用运行10分钟。

我们收集了运行期间每秒事务数(TPS) 和第99百分位延迟的性能统计数据（每个VoltDB 事务是一个单一的应用”运算“，并且术语是可交换的）。来自这些统计信息的图表数据证明了VoltDB具有线性可扩展性来应对不断增加的工作负载，同时能够维持可预测的低延迟。

2.4 应用

该应用主要由一个Java客户端和一个VoltDB数据库组成。实现每个运算的处理逻辑的预存程序同时使用Java 和 SQL 进行编码以在数据库上运行。

基准测试应用管理用户的余额，同时允许他们购买新服务和添加其他的限额， 例如分钟、数据、消息等。客户端依赖数据库来运行具有多个SQL 语句的复杂事务和能够完全保证 ACID特性的条件逻辑。

2.4.1 架构

作为一个关系数据库，VoltDB 中的数据由以下所示的表组成。每个表要么是分区的，其中数据行在不同位置间分布 (sites_per_node * node_count)，要么是复制的，其中每个节点拥有该数据表的完整副本。不常更新的表，例如产品表，是保存为复制表的理想示例。

然而，产品表是主要工作负载的一部分，因为它被用来获取用户试图购买的产品的价格。用户表、使用情况表和余额表被创建为分区表，从而实现高并发性的读写访问。

2.4.2 数据

工作负载在一个稳定的数据集上运行，该数据集根据集群的大小进行扩展。不同集群的起始数据集大小遵循以下比例：

2.4.3 工作负载

工作负载由两个并行运行的操作组成，即分配限额和添加用户/余额。这些操作在Java + SQL中实现，涉及到使用条件逻辑执行多个SQL语句，这些语句提供的好处是减少网络行程和在每个逻辑事务中实现更多工作。

起始数据集加载之后，以相同的频率并行调用工作负载中的两个操作以实现目标吞吐量。两个操作都很复杂，涉及到必须通过连接多个表的数据做出的决定。通过将每个操作实现为VoltDB 预存程序，整个操作将作为一个完整事务成功或失败，并将状态返回给客户端应用：

“

分配额度 — 访问 4 个表。仅在确认用户的账户余额充足时分配额度，并在成功分配之后减少余额。

添加用户/余额 — 访问 2 个表。添加一个新用户到系统或增加某个用户的余额。

2.4.4 衡量标准

基准测试应用在不同的节点配置上运行，以证明VoltDB 在运行高度事务型工作负载时的可扩展性。我们在每种节点配置上捕捉延迟和吞吐量数据点，并使用它们绘制可扩展性曲线。

我们在运行10 分钟后捕捉数据点。此等待期帮助我们确保系统达到中等CPU利用率（介于 55%和 60%之间）的稳定状态，并且每台机器的RAM利用率大致为33%。

2.5 环境

基准测试在Google Cloud实例上进行。节点配置如下：

03 基准测试结果与分析

关于基准测试结果的背景，我们想要说明的是，基于我们与电信客户的对话，针对要求最为苛刻的5G 应用的SLA 是低于5 毫秒的可预测延迟，以及每秒处理 2~6 百万数据行的能力和线性扩展的能力。我们可以在这些严格的SLA的背景下看待基准测试结果。

VoltDB（4 个分区在4 核机器上运行 ）的吞吐量和延迟

这张图表展示了吞吐量与节点数量的近似线性扩展。测试的最大集群含有27个节点。观察到的最高吞吐量是每秒740,703次运算。

上图还表明，对于每个测试的集群大小，第99百分位延迟符合 SLA 所要求的5毫秒（27个节点的集群除外，其延迟略长于5 毫秒）。考虑到5G级电信SLA是所有行业或用例中最为严格的，以及计费应用的复杂性，VoltDB 轻松超越吞吐量和延迟SLA 是一项非常了不起的成就。

VoltDB（16 个分区在16 核机器上运行）的吞吐量和延迟

基准测试在16核机器上运行，该机器更接近于生产系统中的配置，因此可以很好地衡量VoltDB 的性能。同样， VoltDB展现出了线性可扩展性，并在27节点集群上实现了超过每秒300万次运算的吞吐量，因而它可以满足或超越SLA要求。

对于各种集群尺寸，VoltDB 的延迟远低于SLA要求的5毫秒。对于3个节点的较小集群，它的第99百分位延迟略长于3毫秒，而对于其他集群配置，它的延迟低于3 毫秒！

不同VoltDB 集群（4 个分区在4 核机器上运行与16 个分区在16 核机器上运行）的吞吐量比较

不出所料，随着分区大小的增加和内核数量的增加，吞吐量显著增加。对于4核和4个分区的27节点集群，吞吐量低于75K，而对于16核和16个分区的27节点集群，吞吐量超过了每秒300万次运算！

不同 VoltDB 集群（4 个分区在4 核机器上运行与16 个分区在16 核机器上运行）的延迟比较

吞吐量随服务器/分区数量增加而增加的趋势也适用于延迟。拥有16 个分区的最强大的16 核服务器比拥有4个分区的4 核服务器具有较低的第99 百分位延迟。对于4 核机器的 27节点集群，延迟刚刚超过5毫秒，而对于16核机器的27节点集群，延迟低于3毫秒。

3.1 实现高扩展性的秘诀

“如前所述，VoltDB 专为线性扩展而设计。为了实现甚至超过300万次运算/秒的吞吐量，用户只需要简单地添加VoltDB节点，直到获得理想的吞吐量。”

3.2 总体拥有成本（TCO）

除了一流的性能之外，VoltDB还具有比业内任何其他解决方案低得多的TCO。虽然可能有人认为“开源解决方案是免费的”, 但天下没有免费的午餐。

很多最初选择开源解决方案的电信客户在经历众多痛苦之后转向了VoltDB。他们还意识到，开源工具经常在更大的硬件上运行，从而导致非常高的资本开支，并且由于这些解决方案需要代价高昂的开发工作量来进行产品构建、维护和故障检测，运营成本远高于提供全天候产品支持的VoltDB产品许可。

世界最大的电信软件解决方案提供商之一从Redis转向VoltDB，仅在硬件方面就节省了一百万美元。

04 结 论

为了回应传统SQL数据库（如Oracle、IBM 和 SQL Server等等）的不灵活性，NoSQL数据库（例如Redis、Cassandra 和MongoDB等等）已经问世。它们大肆宣称它们能够通过存储和查询非结构化数据来实现扩展，而无需实施关系数据库的结构化概念。

尽管他们最初声称NoSQL数据库不“依赖”于SQL是有好处的，但SQL的标准化、灵活性和在查询大量数据方面的效率无法被替代的现实阻碍了它们进入高性能或任务关键型应用的可行性。

NoSQL厂商试图在顶层支持 SQL 语言的尝试仍然未能实现其目标：提供类似于当前SQL 数据库的基础ACID特性保证。像VoltDB这样的下一代SQL数据库是一个两全其美的解决方案，具有NoSQL 解决方案的可扩展性，以及对5G应用至关重要的高吞吐量、低延迟、高可用性、强大的ACID 事务、实时分析和其他功能。

这项基准测试研究的结果证明，VoltDB 可以提供要求极为苛刻的5G 应用所需的线性扩展、低延迟和高吞吐量， 同时不牺牲一致性。VoltDB超过300万次运算/秒的吞呈量和低于5毫秒的第99百分位延迟可以满足针对5G系统提出的SLA，而NoSQL数据库远不能满足电信应用的性能和延迟要求。如果您想要运行基准测试，我们建议您从我们的公共存储库下载应用源代码，然后亲自尝试：

https://github.com/VoltDB/app-telco-charging

如果您对VoltDB的工业物联网大数据低延迟方案感兴趣，欢迎私戳，进入到我们的官方微信交流群。

VoltDB中国：sgao##voltdb.com （请将“##”替换成“@”）