5G 革命：如何让「数据」实现最大性能？

壹

早在 2000 年代中期，H-Store 第一次在 M.I.T.被我们提出来，VoltDB 是 H-Store 的商业化产品，它表示结构相似的数据会被连续存放到一起。在本文的后续描述中，我们将使用 V-H 来缩写。

V-H 的设计（始于 2004 年）强调了在每秒可观的低延迟（以毫秒为单位）的情况下，以每秒大规模事务（TPS）的方式实现最大性能。 这样做的理由是，随着更快的辅助存储（例如 SSD 和 NVRAM）的出现，基于磁盘的 DBMS 的性能将会提高。

综上，必须设计基于 RAM 的 DBMS，这样相对于传统的 DBMS 系统而言，才具有明显的性能优势。

贰

V-H 采用了 3 个关键的技术聚焦点：

2.1 聚焦单分区事务性

多节点主内存 DBMS 必须跨各个节点对数据进行分区。多节点事务不可避免地涉及负载很大的分布式并发控制协议。正如在[Harding]所描述，分布式并发控制大大降低了操作执行速度。如果事务之间存在重大资源等待，吞吐量也会大大降低。为了避免这种开销，V-H 专注于优化所谓的单分区事务。

在这种情况下，应用程序设计人员应组织其数据，以便几乎所有事务都不会跨越多个节点上的数据。许多应用程序自然是“单个部分”，例如更新单个用户的余额，并检查其授权电话呼叫权限。换句话说，将用户帐户划分为多个节点将使上述交易仅跨越一个分区。另一方面，将资金从一个帐户转移到另一个帐户通常不能成为单一分区，因为通常无法将两个帐户都聚集在一个分区中。

总而言之，许多应用程序可以做成单个分区，而有些则不能。另外，几个非常大的应用程序都坚持认为所有事务都是单个分区的。因此，他们禁止将多分区事务作为应用程序体系结构的最佳实践，以使性能最大化。

V-H 选择针对“单分区”事务进行优化，使其可以达到很高的运行性能。

尽管 V-H 也可以执行“多分区”事务，但它们的性能并不高。我们应该在主要是单个分区的场景中使用 VoltDB。

2.2 聚焦在存储过程

大多数 OLTP 用例主要包含重复性事务，因此，有一些大批量交易类型。因为执行单个事务需要服务器与客户端中的多次通信，所以使用 ODBC / JDBC 执行这些操作不是最佳选择。

NoSQL 中单次访问接口的应用程序，其中值被一对一地检索到客户端处理，也会有类似的通信开销，这不仅会导致多次客户端-服务器通信开销，而且还会导致对网络带宽使用造成不必要的压力。相反，如果使用存储过程接口，在这种情况下，事务执行代码（Java 和 SQL 的混合）被移入 DBMS，可以仅用一条通信消息执行它。1980 年代中期 Sybase 引入存储过程时，相比到 ODBC / JDBC 接口数据访问，大约有 5 倍的性能优势。

因此，V-H 使存储过程接口以获得更高的运行性能。

2.3 聚焦在主动-主动数据复制

基本上所有 OLTP 应用程序都需要高可用性（HA）。这要求每个对象被复制多次，并且崩溃时要求系统故障转移到备份。在正常处理期间，V-H 必须确保处理所有副本都执行相关事务，或都不处理任何事务。只有这样，V-H 才会实现“故障转移”而不会导致数据损坏。

执行副本更新有两种可行的策略：

2.3.1 主动-主动复制

即：事务在所有副本上执行，并在所有节点上本地提交。

在这种情况下，所有副本都是“活动的”，并且每个具有副本的站点都将进行事务处理。

例如，AT＆T 将让东海岸和西海岸的客户与最近的集群进行对话，并在后台进行主动复制同步。

2.3.2 主动-被动复制

即将一个副本指定为主副本，并首先在其中执行每个事务。日志记录写入此节点，然后通过网络移至备份节点。

在每个备份中，日志都会前滚以使辅助数据库与主数据库同步。

叁

鉴于有两种可行的策略，应选择哪一种？

几年前，[Malvaiya]在 VoltDB 中实现了单副本崩溃恢复。他比较了两种策略：

1.在恢复时编写命令日志并重新运行命令

2.写入数据日志，并在恢复时将日志前滚。

他发现命令日志在执行期间的开销可以忽略不计，因此比数据记录方法快得多。[Yu]将此代码扩展到了复制，并实现了主动-主动和主动-被动复制。他发现主动-主动是性能优胜者，几乎是两倍。

所以 VoltDB 专注于主动-主动复制，这需要 V-H 偶然使用的确定性的并发控制策略。相反，大多数 V-H 竞争对手使用不确定的并发控制策略（例如，动态锁定，乐观并发控制，多版本并发控制）。因此，主动-主动不是这些系统的选择，它们也没有两倍速度优势。

总体而言，这三个决策使 V-H 可以比其他主要内存 DBMS 在事务处理上甚至可以快到一个数量级。在基准（[Somagani]，[Acme]）测试中，V-H 在合理大小的群集上每秒运行 1M 事务。到目前为止，这比我们所知道的任何客户工作负载都要快。因此，V-H 竞争者可以按订单运行这些工作负载，但是需要投入更多的硬件成本。

肆

不过伴随 5G 应用的兴起，这种竞争格局将发生巨大变化。

5G 有望提供更高的带宽，更高的密度（每平方千米最多一百万个设备）和毫秒级延迟。设备的这种密度迫使新的无线接入网（RAN）小区技术避免饱和现有网络。反过来，这将成倍增加数据库 TPS 的数量，以便：

更新网络中每个设备的状态更改信息

对每个新设备通信都执行实时身份验证和授权策略此外，网络切片是 5G 要求，一部分网络专用于每个用例，例如：工业物联网，视频，VR 等。每种情况都需要即时决策，以实现负载平衡和服务质量保证，以增加用户数量（人员+物联网设备）。

为了演示更高 TPS 的需求，让我们考虑一个典型的无线运营商示例：一个中等大小的运营商可能支持 1000 万部电话；较大的可能有 1.5 亿。典型的无线运营商具有大量事务交易型的应用程序。这里有一些例子：

计费和收费：当前的网络以 6 秒为增量计费，即每分钟 10 次。如果普通电话的占空比为 10％，则小型网络每分钟有 600 万个计费事件，或每秒 100,000 个。对于较大的网络，该数目要高得多。随着时间的流逝，物联网设备的数量预计至少会翻两番。这样，计费将是一个非常高的 TPS 应用程序，并且在毫秒级的延迟下不会降低一致性要求。

新服务：物联网设备预计将继续在 5G 世界中启用新服务。这些将包括医疗警报应用程序，当人跌倒或摔倒时可连接到紧急人员救援。由于足球场中的订户非常集中，因此动态地旋转地理围栏子网以应对连接高峰。智能计量将实现个性化的客户体验和沟通，并促进对电网消耗，能源需求的分析，并符合新的法规要求。在风能和太阳能农场，5G 还可以对 IOT 传感器进行连续监控和预测性维护。

伍

总而言之，由于 5G 的特性，让很多应用的事务性操作需求飞速增长。

另外，大多数无线应用程序（例如计费）是单分区事务，可以充分发挥 VoltDB 的架构设计优势。对于这类应用程序，即便是中等大小的无线运营商，也必须每秒支持数百万个事务。大多数内存 DBMS 并不能支持这种数量的事务。

VoltDB 是一个例外，我们一些准测试也显示了架构理念上的领先性。如果您是 KTPS 应用程序（每秒数千个事务），那么有很多解决方案。但如果您期待 MTPS（每秒数百万个事务），请尝试一下 VoltDB。

作者：Michael Stonebraker

参考引用[Harding] http://www.vldb.org/pvldb/vol10/p553-harding.pdf[Malvaiya] http://hstore.cs.brown.edu/papers/voltdb-recovery.pdf[Yu] http://www.cs.cmu.edu/~pavlo/blog/2013/12/fall-2013-research.html[Somagani] https://www.voltdb.com/blog/2018/11/06/benchmarking-voltdb-on-the-cloud/[Acme] https://www.voltdb.com/blog/2015/11/17/comparing-cloud-performance-ycsb/

如果您对 VoltDB 的工业物联网大数据低延迟方案、全生命周期的实时数据平台管理等感兴趣，欢迎私信，进入到我们的官方交流群。