壹
早在 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/vol…
[Malvaiya] http://hstore.cs.brown.edu/pa…
[Yu] http://www.cs.cmu.edu/~pavlo/…
[Somagani] https://www.voltdb.com/blog/2…
[Acme] https://www.voltdb.com/blog/2…*
如果您对 VoltDB 的工业物联网大数据低提早计划、全生命周期的实时数据平台治理等感兴趣，欢送私信，进入到咱们的官网交换群。