intersystemsdc/irisdemo-demo-htap

混合事务分析处理(HTAP)演示

镜像概述和主要用途

许多行业的用例需要具备每秒摄入数千至数百万条记录，同时允许实时查询的能力，例如***交易处理、欺诈检测、物联网应用（包括异常检测和实时设备综合效率分析）等。Gartner将此能力称为"HTAP"（混合事务分析处理），Forrester则称之为Translytics。InterSystems IRIS是一个功能强大、可扩展、高性能且资源高效的事务分析数据平台，兼具内存数据库的性能与传统数据库的一致性、可用性、可靠性和低成本优势。

本演示展示InterSystems IRIS如何在同一集群上以高吞吐摄入数据（每秒数千条记录），同时支持高性能的实时查询，且资源利用率低。该演示可在单个InterSystems IRIS实例或云环境中的InterSystems IRIS集群上运行，也可在SAP HANA、MySQL、SqlServer和Amazon Aurora上运行，以进行" apples-to-apples"的性能和资源利用率比较。

核心功能和特性

• 高吞吐数据摄入：支持每秒数千至数百万条记录的持续摄入能力
• 实时查询处理：在高吞吐数据摄入的同时，保持低延迟的查询响应
• 多数据库支持：可在InterSystems IRIS、SAP HANA、MySQL、SqlServer、Amazon Aurora等多种数据库上运行
• 性能比较工具：提供与主流数据库的性能对比数据，包括摄入速度、查询速度等关键指标
• 跨平台部署：支持在AWS、Kubernetes及本地PC（通过Docker）部署运行
• 可视化界面：提供Web UI用于启动测试、配置参数和查看结果

使用场景和适用范围

• ***服务：***交易处理、高频交易分析、实时风险评估
• 欺诈检测：实时交易监控、异常模式识别
• 物联网应用：设备数据实时采集、异常检测、实时设备效率分析(OEE)
• 性能基准测试：数据库选型评估、性能优化验证
• 技术演示：展示HTAP架构优势、数据库性能对比分析

详细使用方法和配置说明

1. 在AWS上运行速度测试

按照https://github.com/intersystems-community/irisdemo-demo-htap/blob/master/ICM/README.md%E7%9A%84%E8%AF%B4%E6%98%8E%EF%BC%8C%E5%9C%A8AWS%E4%B8%8A%E8%BF%90%E8%A1%8C%E6%AD%A4%E9%80%9F%E5%BA%A6%E6%B5%8B%E8%AF%95%EF%BC%8C%E6%AF%94%E8%BE%83InterSystems IRIS与SAP HANA、AWS Aurora等其他数据库的性能。

2. 在Kubernetes上运行速度测试

按照此链接的说明，在Kubernetes上运行此速度测试。

3. 在本地PC上运行

在本地PC上运行速度测试的前提条件：

• Docker和Docker Compose
• Git（如果要在PC或AWS上运行所有测试；仅运行InterSystems IRIS测试可能不需要Git）

目前可在本地PC上使用InterSystems IRIS、MySQL、SqlServer和SAP HANA运行此演示。

3.1 使用InterSystems IRIS Community运行

确保机器已安装Docker，可通过以下命令快速启动（适用于Mac或Linux PC）：

bash
wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose.yml
docker-compose up

如果使用Windows，将https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose.yml%E6%96%87%E4%BB%B6%E4%B8%8B%E8%BD%BD%E5%88%B0%E6%96%87%E4%BB%B6%E5%A4%B9%EF%BC%8C%E6%89%93%E5%BC%80%E5%91%BD%E4%BB%A4%E6%8F%90%E7%A4%BA%E7%AC%A6%E5%B9%B6%E5%88%87%E6%8D%A2%E5%88%B0%E8%AF%A5%E6%96%87%E4%BB%B6%E5%A4%B9%EF%BC%8C%E7%84%B6%E5%90%8E%E8%BE%93%E5%85%A5%EF%BC%9A

BAT
c:\MyFolder\docker-compose up

也可使用git克隆整个仓库获取源代码（需安装git）：

bash
git clone https://github.com/intersystems-community/irisdemo-demo-htap
cd irisdemo-demo-htap
docker-compose up

以上方法都会触发演示所需镜像的下载并启动所有容器。启动过程中会显示大量容器消息，属于正常现象。启动完成后，终端会保持运行状态（不要按CTRL+C，否则会停止所有容器）。

所有容器启动后，在浏览器中打开http://localhost:***%E8%AE%BF%E9%97%AE%E6%BC%94%E7%A4%BAUI%E3%80%82%E7%82%B9%E5%87%BB**Run Test按钮运行HTAP演示，测试最长运行时间为300秒，也可手动停止。如需更改最大运行时间，点击UI右上角的Settings**按钮进行设置。

点击Run Test后，状态会变为Starting...。对于InterSystems IRIS或SQL Server，此状态可能持续较长时间，因为测试前会预扩展数据库至 full capacity（生产环境的常规操作）。InterSystems IRIS作为混合数据库（兼具内存性能和传统数据库优势），需要适当扩展磁盘数据库，请耐心等待。某些数据库（如Aurora和MySQL）无法从一开始进行预扩展，因此我们会先运行一次速度测试进行"预热"，然后再次运行（会截断表）。

警告：InterSystems IRIS数据库扩展可能需要一些时间。在本地PC上运行时，由于InterSystems IRIS Community对数据库大小有限制，我们会将数据库预扩展至最大9Gb。

测试完成后，会出现绿色按钮，允许将测试结果统计数据下载为CSV文件。

测试完成后，返回终端按CTRL+C停止容器，也可执行以下命令确保容器完全停止并移除：

bash
docker-compose stop
docker-compose rm

这一点很重要，尤其是在不同数据库（如InterSystems IRIS和MySQL）之间切换测试时。

3.2 在本地PC上使用MySQL或MariaDB

要针对MySQL运行演示：

bash
wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose-mysql.yml
docker-compose -f ./docker-compose-mysql.yml up

此处下载了带有mysql后缀的不同docker-compose文件，必须使用**-f**选项指定该文件。保持终端窗口打开，在浏览器中访问http://localhost:***%E3%80%82

测试完成后，返回终端按CTRL+C停止容器，也可执行以下命令：

bash
docker-compose -f ./docker-compose-mysql.yml stop
docker-compose -f ./docker-compose-mysql.yml rm

测试中发现，InterSystems IRIS的数据摄入速度比MySQL和Amazon Aurora快25倍。

也提供用于MariaDB的docker-compose-mariadb.yml文件。

3.3 在本地PC上使用SQL Server 2019-GA-ubuntu-16.04

要针对SQL Server运行演示：

bash
wget https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/docker-compose-sqlserver.yml
docker-compose -f ./docker-compose-sqlserver.yml up

保持终端窗口打开，在浏览器中访问http://localhost:***%E3%80%82

本地PC测试中发现，InterSystems IRIS的数据摄入速度比SQL Server快2.5倍，查询速度快400倍！我们将在AWS RDS SQL Server上进行测试并报告结果。

3.4 在本地PC上使用SAP HANA

在本地PC上使用SAP HANA运行速度测试需要：

• 安装有Ubuntu 18的VM，包含docker和docker-compose（因为SAP HANA需要对Linux内核参数进行一些更改，而这些更改无法在Docker for Mac或Docker for Windows上完成；SAP HANA还需要4.0或更高版本的Linux内核）
• 为VM分配至少9 GB RAM，否则无法启动（会出现非 helpful 的错误消息）

要针对SAP HANA运行演示：

bash
git clone https://github.com/intersystems-community/irisdemo-demo-htap
cd ./irisdemo-demo-htap
./run.sh hana

等待镜像下载和容器启动。当docker-compose停止向屏幕输出内容时，说明所有服务已启动，但需耐心等待——SAP HANA启动约需6分钟！屏幕可能会冻结一分钟左右，然后SAP HANA会继续输出文本，此过程约持续6分钟。当看到"Startup finished!"文本时，即可开始使用。如果启动失败并显示错误，可能是因为内存不足，需要增加VM内存。

与InterSystems IRIS和MySQL只需运行docker-compose up不同，SAP HANA需要对Linux内核进行一些配置，run.sh脚本会自动完成这些配置。

VM上的速度测试显示，InterSystems IRIS的数据摄入速度比SAP HANA快1.3倍，查询速度快20倍，且内存使用量仅为SAP HANA的一小部分。

4. 资源

关于此演示的视频正在制作中！同时，这里有一篇有趣的文章，讨论InterSystems IRIS的架构及其高性能的原因。

5. 此基准测试与sysbench、YCSB或TPC-H等标准基准测试的比较

开源工具https://github.com/akopytov/sysbench%E5%BD%93%E7%84%B6%E5%8F%AF%E4%BB%A5%E6%89%A9%E5%B1%95%EF%BC%8C%E4%BD%86%E7%9B%AE%E5%89%8D%E5%8F%AA%E8%83%BD%E7%94%A8%E4%BA%8E%E6%B5%8B%E8%AF%95MySQL%E3%80%81PostgreSQL%E5%8F%8A%E5%85%B6%E4%BB%96%E5%9F%BA%E4%BA%8EMySQL%EF%BC%88%E5%A6%82AWS Aurora）或实现MySQL wire协议的数据库。我们当然可以修改它来测试其他数据库，但我们希望使用JDBC（而非sysbench使用的基于C的驱动），并希望工具对后端数据库的指标收集依赖性更低。

我们的测试更简单，仅使用一个表。sysbench允许并行运行INSERT和SELECT，在同一表的多个副本上，这对我们的用例不公平。我们希望测试数据库引擎在单个表上使用相同可用IOPS时的效率，以及它如何处理锁竞争和内存缓存。我们当然可以在InterSystems IRIS上使用分片，这在某种意义上类似于允许在多个数据副本上并行进行INSERT和SELECT，但这将在不同节点上运行，具有更多可用IOPS，这对sysbench不公平。最后，实际应用通常不会保留同一表的多个副本，即使有，大多数事务和搜索也发生在"主副本"上，其他副本仅保存历史数据。因此，我们认为sysbench更侧重于测试基础设施设置，而非数据库本身。

开源的***云服务基准测试(YCSB)项目旨在开发一个框架和一组通用工作负载，用于评估不同"键值"和"云"服务存储的性能。

尽管YCSB上有一些可描述为HTAP的工作负载，但YCSB不一定依赖SQL来实现。而本基准测试依赖SQL。

TPC-H专注于决策支持系统(DSS)，这不是我们探索的用例。

在*服务应用中（例如），数据快速进入单个表，数据库如何处理锁竞争、内存不足压力（图中蓝色部分）和内存压力**（图中黄色部分）至关重要。锁竞争问题也很关键。允许在多个表上运行测试（如sysbench）会缓解锁竞争问题并掩盖它。我们不希望这样，因此我们在单个节点和单个表上运行测试，以便真正衡量数据库效率和内存缓存智能。

下图展示了内存不足压力和内存压力的含义：

!https://raw.githubusercontent.com/intersystems-community/irisdemo-demo-htap/master/database-architecture.png?raw=true

左侧显示数据快速进入，可能通过多个JDBC/ODBC连接。为提供持久性（参见ACID），数据库会立即将新事务写入磁盘上的顺序日志文件（也称为日志）。简单来说，这是成功提交和数据被视为"持久"的唯一要求。传统数据库和内存数据库都会这样做（纯内存数据库除外，不在本测试范围内）。

数据库还会将这些数据尽可能长时间地保存在内存中作为内存缓存，以便对这些数据的查询可以非常快速地得到回答，而无需从磁盘读取数据。内存中保存的是数据库的当前状态。例如，数据库行可能发生了多次更新，数据库日志包含所有这些更新。数据库的当前状态是所有这些更新的累积结果。当前状态是最终事实。两种类型的数据库（传统和内存）都会尽力将数据库的当前状态完全保存在内存中，以便查询可以非常快速地进行。

传统数据库会尽力将当前状态写入结构化的数据库文件。这是一个缓慢的过程，因为数据库必须更新数据库文件中的特定块以反映当前状态的变化（随机写入）。传统数据库会尽快异步执行此操作。这样做的好处是，如果需要重启数据库，可以直接从数据库文件读取数据库的当前状态（并仅使用日志文件中的少数记录完成），而不必完全从数据库日志文件逐条重建事务。

另一方面，内存数据库仅在无法再将完整数据库状态保存在内存中时才会写入数据库文件。它们还会在内存中应用数据压缩，以充分利用可用内存。一些内存数据库甚至没有要写入的数据库文件，重启数据库时完全依赖日志文件。这些内存数据库如果内存不足会崩溃。但大多数企业级内存数据库（如SAP HANA）会像InterSystems IRIS一样写入数据库文件，但仅在内存不足且数据压缩不再有帮助时才这样做。

因此，如您所知，如果我们不断向数据库插入记录（数据摄入），会产生内存不足压力，需要释放更多内存空间以容纳新记录，这将迫使这些数据库写入磁盘。另一方面，我们也在并行查询特定记录集，这将迫使数据库尽力将这些经常请求的记录保存在内存中。这就是我们所说的内存压力。

我们希望衡量数据库在摄入记录的同时允许响应式查询的速度：

• 表仅有一个表，包含19列和3种非常不同的数据类型
• 表上声明了主键
• 我们的查询通过主键（账户ID）获取记录，随机查询8个固定键：W1A1、W1A10、W1A100、W1A1000、W1A***、W1A***、W1A和W1A。原因如下：
  • 我们知道在生产系统中不可能将所有数据保存在内存中。即使内存数据库也有复杂的架构，当内存不足时会将数据移出内存。为使测试简单且可比较，我们通过主键获取这组固定记录，以避免比较数据库可能具有的不同类型的索引。
  • 通过账户号（PK）获取客户账户数据记录是我们许多客户的实际工作负载。当数据以高速摄入时，数据库需要对查询做出响应。
  • 由于账户ID是主键，数据库会使用其首选（且据信是最佳）索引对其进行索引。这使我们在比较数据库时保持公平，同时保持简单。
  • 由于我们反复请求相同的账户号，数据库将有机会将这些数据缓存在内存中。我们认为这对内存数据库来说是一项简单的任务。

InterSystems IRIS是混合数据库。与传统数据库一样，它也会尽力将数据保存在内存中。但由于摄入工作导致每秒数千条记录快速进入，内存会被快速清除。此测试让您看到与其他传统数据库和内存数据库相比，InterSystems IRIS的缓存智能：

• 传统数据库在摄入和查询方面表现不佳
• 内存数据库会：
  • 在测试的前几分钟表现出良好的摄入性能，随着内存填满，压缩变得更加困难，写入磁盘不可避免
  • 查询性能不佳，因为系统将忙于摄入、压缩数据、移出内存等操作

6. 表结构

以下是我们发送给所有支持的数据库的CREATE TABLE语句：

SQL
CREATE TABLE SpeedTest.Account
(
    account_id VARCHAR(36) PRIMARY KEY,
    brokerageaccountnum VARCHAR(16),
    org VARCHAR(50),
    status VARCHAR(10),
    tradingflag VARCHAR(10),
    entityaccountnum VARCHAR(16),
    clientaccountnum VARCHAR(16),
    active_date DATETIME,
    topaccountnum VARCHAR(10),
    repteamno VARCHAR(8),
    repteamname VARCHAR(50),
    office_name VARCHAR(50),
    region VARCHAR(50),
    basecurr VARCHAR(50),
    createdby VARCHAR(50),
    createdts DATETIME,
    group_id VARCHAR(50),
    load_version_no BIGINT  
)

摄入工作器将发送尽可能多的INSERT，并测量每秒插入的记录数以及每秒兆字节数。

查询工作器将通过account_id从该表中SELECT，并尝试选择尽可能多的记录，将其测量为每秒选择的记录数以及每秒选择的兆字节数，以测试端到端性能并提供工作量证明。

端到端性能与某些JDBC驱动程序的优化有关。如果仅执行查询，JDBC驱动程序可能不会从服务器获取记录，直到实际请求列的值。

为证明我们确实在读取所SELECT的列，我们对返回的所有字段的字节数求和作为工作量证明。

7. 如何实现摄入和查询的最大吞吐量

为实现最大吞吐量，每个摄入工作器将启动多个线程，每个线程将：

• 为上述表的每列准备1000个随机值。这样做是因为每列可以有不同的数据类型和大小，我们希望生成相应变化的记录
• 对于要插入的每个新记录，摄入工作器将为每列从1000个值中随机选择一个值，一旦记录准备好，就将其添加到批处理中
• 使用批处理插入，默认批处理大小为每批1000条记录

默认的摄入工作器线程