您是否曾经隔夜等过昨天的销售报告？ 或者，您可能想要更新的需求预测，该需求预测可以根据实时销售点和订单管理数据预测库存需求。 我们一直在等待我们的分析。 更糟糕的是，通常需要数周才能请求更改我们的报告。 为了增加侮辱性伤害，您需要为专门的分析数据库的不断增加的费用缴税。
但是，如果不再需要该怎么办？ 如果您可以合并分析以使其与操作工作负载在同一数据库上运行怎么办？ 您的第一个回答可能是：“您疯了。 我们将分析移出了数据库，因为它的速度还不够快。” 曾经是真实的，但现在不再如此。 现在，可以通过将分析整合到另一种称为混合事务分析平台（HTAP）SQL RDBMS上来降低数据库成本。 一些HTAP数据库可以是专门的，经过工程设计的系统，可能需要花费数百万美元。 但是在横向扩展体系结构上有一种新型的HTAP。 该体系结构将数据分布在多个服务器上，并在每个服务器上的不同引擎上执行计算，以实现混合工作负载的规模和性能。
HTAP是Gartner创造的一个术语，用于描述新兴的数据库技术和应用程序，这些技术和应用程序可以同时提供在线事务处理（OLTP）和分析处理（OLAP）来产生更丰富的应用程序体验和更多业务价值。 Forrester将此称为横向数据平台。 如果没有这种平台，企业将被迫通过复杂的管道将数据转换并从应用数据库中移出，这些管道利用运营数据存储，数据仓库和数据集市来最终实现分析和数据科学。 这非常耗时，并且会导致以下方面的延迟：
- 制作报告
- 更新已部署的机器学习模型的功能，从而对旧数据进行预测
- 机器学习模型的重新训练，导致模型的准确性降低。
在此博客中，我们展示了如何衡量HTAP工作负载的性能。 为此，我们结合了在同一组表上同时运行的TPC-C和TPC-H基准。 TPC-C模拟批发零售业务用户，他们接受销售订单，处理付款，进行库存水平检查，并在大量交易数据上以高并发记录交付。 TPC-H基准测试由22个复杂的分析查询组成，这些查询以较低的并发性扫描大量历史数据。
我们在此处使用了开放源代码基准测试项目来驱动最初发表在混合工作量CH-benCHmark，Richard Cole等人，DBTest'11，雅典，希腊的测试 。 基准测试依赖于OLTP平台中提供的代码： VLDB 2014上的DE Difallah，A。Pavlo，C。Curino和P. Cudre-Mauroux 用于基准测试关系数据库 。 C作为基准，然后覆盖经过修改以针对TPC-C模式工作的TPC-H查询。 我们已经提供了免费试用，可用于此处的集群。
TPC-C新订单交易
在我们测试的工作负载运行中衡量的事务不是单个SQL语句，而是实际上复杂的应用程序逻辑，这些逻辑由打包在ACID事务中的一系列select，insert和update语句组成，这些事务可以作为整体提交或回滚。 每个新订单交易平均包含十个不同的订单项，平均需要处理46条SQL语句。
我们的实验是在AWS上的Splice Machine开源RDBMS平台即服务上执行的。 （ 免责声明：两位作者都在Splice Machine工作，一位是CEO ）。 Splice Machine提供了“笔记本”，它们是数据工程师和数据科学家的集成开发环境。 这些笔记本包括JupyterLab和BeakerX，用于多语言编程，跨单元共享变量以及许多其他出色的编码和可视化API。 以下Jupyter笔记本单元格集显示了组成New Order事务SQL语句。 为了简化此处显示的代码，我们对示例交易的某些元素进行了硬编码：我们在订单中使用单个项目，并且将订单保留在同一仓库的本地。 基准不以这种方式受到限制。
新订单交易从客户和地区查找开始，以获取折扣，信用和税收信息以及保留订单ID，这些都是处理新订单所需的。 我们在这里使用一个python单元格来存储SQL的结果，并设置一些BeakerX变量以进行多语言访问：
接下来，我们更新该地区的递增的下一个订单ID，在ORDER和NEW_ORDER表中都创建一个新的订单条目，并检查要订购的物料的仓库库存水平：
接下来，应用程序逻辑为订单中的每个项目计算订单总计和库存补充需求，更新库存记录，并创建订单行记录。 在示例代码中，我们仅执行一次，但是在实际的基准测试中，订单中的每个订单项均会发生此情况，平均每个订单10次。
TPC-H查询
TPC-H基准测试旨在测试决策支持系统，以提供对业务运营的见解。 在这里，TPC-H查询＃2搜索欧洲的价格为15号黄铜零件的最低欧洲价格的供应商：
这就要求我们首先计算整个欧洲的当前最低价格，然后找到欧洲以该最低价格提供的尺寸为15的黄铜零件。 这需要跨大型数据集进行多个联接和聚合。 这种查询通过使用并行分布式处理进行水平缩放来实现更高级别的吞吐量。
拼接机RDBMS具有用于OLTP和OLAP工作负载的独立工作器。 为了获得以下结果，我们利用了一个由8个m5.2xlarge节点组成的AWS集群，该节点在4个OLTP工作程序和4个OLAP工作程序之间划分，并与100个并发TPC-C用户和8个并发TPC-H用户一起运行。 Splice Machine提供了一个免费试用版群集，该群集利用相同的硬件配置和随附的HTAP笔记本电脑，使您可以轻松地尝试其他并发配置。 我们运行了十分钟的HTAP工作负载，按事务类别按工作负载衡量总数，并记录了所有响应时间。
前两个图表是已完成交易的累积计数。 X轴以秒为单位测量经过的测试时间。 在TPC-C图表中，计数是按请求类型划分的，其中测量的每个事务都是一组许多SQL语句； 图例中的2I 3U 4S表示2次插入，3次更新，4次选择作为最小操作数。 在许多事务中，SQL语句计数随着订单中项目计数的增长而增长，平均订单大小为10个项目。 在“ TPC-H查询”图表中，我们计算已执行查询的总数。 这些是复杂的查询，涉及表扫描，大型联接和聚合，子查询以及其他昂贵的查询结构。
延迟图向我们显示了在整个工作负载执行过程中事务响应时间如何变化。 第99个百分位数的行显示，所有事务中有99％的执行时间不到一秒钟。 第50个百分位数的行显示所有查询中的50％始终在1/4秒内运行。
总之，在一个4x4拼接机数据库上，在100个TPC-C用户和8个TPC-H用户运行10分钟的情况下，我们看到191,789个TPC-C事务和14个TPC-H查询已完成，SLA为查询的99％由于测试初始化开销，除了3.3秒的单个初始峰值外，其余所有运行时间都在1.085秒以下。
接下来，我们想了解如果我们将资源增加一倍，它将如何扩展。 我们建立了一个8 OLTP x 8 OLAP Splice Machine数据库，并在100分钟内对100个TPC-C用户和8个TPC-H用户重新运行了相同的测试：
更多计算资源这导致两种工作负载的吞吐量显着增长：
- TPC-C交易= 279,480（+ 46％）
- TPC-H查询= 32 Qs（+ 128％）
- SLA也更好，其中99％的事务在0.79秒内运行。
TPC-H的增长似乎好于预期，TPC-C的增长不及预期，因此我们进行了另一项测试以试图更好地理解这一点。 我们的理论是100个TPC-C用户没有使Splice Machine OLTP工作人员饱和，因此我们将TPC-C的并发性提高到200，并再运行10分钟：
该测试的结果是：
- TPC-C交易= 330,728（与第一轮相比增长72％）
- TPC-H查询= 24（与第一次运行相比增加了71％）
- SLA-在1.3秒内完成99％的交易
确认我们仍然可以通过请求更多交易来提高8x8的吞吐量。
结论
我们能够运行并发的TPC-C和TPC-H工作负载，同时保持稳定的事务响应时间。 我们还通过使OLTP和OLAP工人增加一倍来测试增加的资源，并且看到这两种工作负载几乎都呈线性改善。 但是，TPC-H的下降导致最终测试的结果，导致我们调查了为什么会发生这种情况。
通过检查所有服务的资源消耗，我们意识到使用CPU请求（而不是CPU限制）的默认Kubernetes配置允许一个服务通过获取分配给其他服务的未使用CPU来消耗超过其分配数量的CPU。
根据您的需求，可变资源分配可能是好事，也可能是坏事。 给定可变的工作负载，我们可能希望动态地使用OLTP工作器的资源来进行OLAP工作，就像我们在第二次测试中看到的那样，或者随着增加OLTP方面的工作而回收分配给OLAP工作的CPU。 另一方面，我们可能想为OLAP工作程序尝试固定的CPU限制，以保证OLTP SLA。 有关可用配置，如何调整它们及其影响的更多信息，将是将来博客中探讨的一个富有成果的领域。
要执行自己的测试，可以在我的网站上找到基准测试。 数据库启动后，只需单击数据库“快速入门”页面上的“运行HTAP基准”链接。
