1. MatrixBench 开源了！再认识它一下

2. 为什么选择 MatrixBench？

3. 开源：MatrixBench 的边界无限扩展

4. 诚恳邀请你的加入

MatrixBench 开源了！再认识它一下

市场上，各种数据库 Benchmark 标准百花齐放，各大数据库厂商也醉心于展示自家产品一骑绝尘的高性能，彰显在某一应用场景冠绝群雄的姿态。

去年六月，我们随 YMatrix 4.5 （注2）发布了一款 全新升级的时序场景数据加载及查询压测工具 —— MatrixBench ，它支持灵活地配置设备数量、时间范围、指标数量、指标类型、采集频率、空值率、随机度等参数，还可以指定查询的并发度、定制查询语句等。

现在，它开源了！?

MatrixBench （点击“ 阅读原文”，访问 开源代码库 ！）
https://github.com/ymatrix-data/mxbench

为什么选择 MatrixBench？

MatrixBench 是为 YMatrix 量身定制的 —— 当然，既然开源了，在社区用户集体智慧的加持下，未来扩展支持其他数据库也不在话下，详见第三段“开源：MatrixBench 的边界无限扩展”。

MatrixBench 不仅支持独有的新特性，而且使用的时序场景 workloads 和测试 query 也是 YMatrix 在长期实践中总结出的精华。

例如，MatrixBench 支持生成 MARS2 （注3）表和配套 index。它也能把很多指标合并成一个 JSON 类型的列，生成表和数据，让指标数不受数据库列数限制。这是 YMatrix 团队在实践中面临大宽表场景的成功经验。

测试一个数据库系统还有另一个难题：有时，一个细微的配置差别可能引发蝴蝶效应，让测试结果有了巨大差异 —— 所谓差之毫厘，谬以千里。

我们该如何调试数据库系统，让各项配置和参数都达到适合目标场景的最佳状态，进而交出一份令人满意的测试答卷？这对测试者的要求颇高，需要深度掌握数据库系统、深刻理解不同应用场景以及丰富的经验。

这就好比一名足球教练，要在球场的博弈中胜出，不仅要了解手中的 26 枚棋子（刚刚结束的世界杯中，每队球员大名单共有 26 人），更要根据场上形势和对手情况灵活调整打法，执教经验也是必备选项。球员的身体条件、能力值、技术特点、性格各异，教练必须对他们的各项“参数”了如指掌才能发挥出他们的特长 —— 数据库测者也要对本数据库系统的各项参数如数家珍。除此之外，球场上针对不同对手采取的定制化，类比到数据库领域也同样重要。

MatrixBench 在面对不同应用场景（如：实时物联网/车联网/工业互联网场景）也要采取针对性的配置和策略。名帅通常已率队征战多载且战功显赫。而在数据库领域里，身经百战磨练出的丰富调试经验也不可或缺。

值得庆幸的是，在 YMatrix 的世界里，想领略它在时序场景下的极限表现，不必花费千万欧元的年薪雇佣一名金牌教练员—— a free MatrixBench is enough！你只要为它提供数据库的连接方式，告知它数据库集群规模、宿主机的配置规格，以及应用场景数据特征 —— 例如时间范围、指标数量与类型、空值率等，它就可以为你选择一个最佳的“兵法”。

这套“兵法”囊括的多维度内容，包括且不限于：

数据库的各项 GUC 值；
表结构；
表的分区键；
表的分布键；
表分区范围的设置；
索引；
索引中的参数；
MatrixGate （注4）（YMatrix 配套高性能数据加载工具）的启动参数。

为确保最佳的使用体验，让我们一起 深入 MatrixBench 的经典应用场景，感受其真实的魅力所在。

假如：你是一个新能源汽车厂商数据部的工程师，需要模拟一个车联网场景的数据加载和 query 查询。

共有 25000 辆车，每辆车每 2 秒会上传一条数据，记录发动机转速、温度等等共计 300 个指标的瞬时数据，类型都是 float8 。但是这些指标大约有一半是空值，至于具体是哪些指标则是随机行为。更复杂的是，这些数据有 5% 的可能性，会因为网络延迟、临时断电等各种原因，24 小时之后才会延迟上传。

数据加载的同时，还需要执行“单车明细”的 query，以及查询目标表记录总数的定制 query，每个 query 都要有 64 个客户端在进行并发查询。每轮跑 30s，数据加载完成之前轮次不间断，连续压测。数据时间戳范围需要跨越 24 小时，测试结束后，希望得到一份加载性能汇总报告和最后一轮 query 的统计数据。

千万不要被这些复杂的情况吓到，因为你仅仅只需提供这么一份配置文件，即可自动形成“兵法”：


  db-database = "testdb1"

  db-master-port = 5432





[global]

  
# 开启进度查看功能，默认即为true

  watch = true





  
# 生成的DDL， GUCs设置建议， Query等文件的存放目录

  workspace = "/tmp/mxbench"





  table-name = "table1"





  
# 设备数

  tag-num = 25000

  
# 指标数据类型，支持 int4, int8, float4, float8 四种类型

  metrics-type = "float8"

  
# 指标数目，如果指标数大于998，就把前997个作为简单列，

  
# 其他的作为json存放在名为ext的列中

  total-metrics-count = 300





  
# 生成数据的起始时间戳, ts-end必须晚于ts-start，否则报错

  ts-
start = 
"2023-01-10 09:00:00"

  ts-
end = 
"2022-01-11 09:00:00"





  
# 每几秒采集一次指标

  ts-step-
in-
second = 
"2"





  
# 数据加载和查询是否同时进行

  simultaneous-loading-
and-
query = 
true





[generator]

  generator = 
"telematics"





  [generator.telematics]

    
# 每个设备每个时间点的指标，分几条数据上传，最终在DB被upsert成1个tuple

    generator-batch-
size = 
1

    
# 延迟上传的数据生成比例（0～100），时间戳往前推24小时

    generator-disorder-ratio = 
5

    
# 生成数据的空值率（0～100）

    generator-
empty-
value-ratio = 
50

    
# 生成数据的随机度， 有OFF/S/M/L几档，默认关闭"OFF"， 一般场景可选择M档

    generator-randomness = 
"M"





[writer]

  
# 使用mxgate的stdin方式加载数据

  writer = 
"stdin"





[
benchmark]

  
benchmark = 
"telematics"





  [benchmark.telematics]

    
# 数组，查询并发度

    
benchmark-
parallel = [
64]

    
# 跑一个查询：单车明细查询

    
benchmark-run-
query-
names = [
"SINGLE_TAG_DETAIL_QUERY" ]

    
# 用户定制query

    
benchmark-custom-queries = [
"select count(*) from talbe1"]

    
# 每轮每条query的跑的次数或时间，让时间生效需要将次数设置为0，如下：

    
benchmark-run-times = 
0

    
benchmark-runtime-
in-
second = 
"30"

兵法在手，MatrixBench 便开始组织实战，检验这套阵容的实效。它会实际地进行数据加载、query 查询，（“只加载，不查询”，“只查询，不加载”，“加载和查询同时跑”均能配置哦！），把各项关键的测试数据展现在你的面前。

数据加载：可以实时观测加载速率、压缩比等关键指标。

period start, period end, period：该统计窗口的起止时间和时间段；
count written：已经写入的数据行数和预计数据行数，以及二者的百分比。xx in this period：该统计窗口内写入的行数；
size written：已经写入的数据字节数和预计数据字节数，以及二者的百分比。xx in this period：该统计窗口内写入的字节数；
size written to mxgate：把数据转化成文本后写入 mxgate 的字节数。xx in this period：该统计窗口内写入 mxgate 的字节数。


● Stdin Writer Report

  ● period 
start: 
2023
-01
-10 
10:
08:
11, 
end: 
2023
-01
-10 
10:
08:
16, 
period: 
5.00s





  ● 
count written 
in total: 
637025 
rows/ 
1500000 
rows 
42.12%, 
637025 
rows 
in this 
period





  ● 
size written 
in total: 
160878718 
bytes/ 
360000003 
bytes 
44.23%, 
160878718 
bytes 
in this 
period





  ● 
size written 
to mxgate 
in total: 
350075440 
bytes, 
350075440 
bytes 
in this 
period





● Telematics 
Benchmark Report

  ● stats 
for 
query SINGLE_TAG_LATEST_QUERY 
with 
parallel 
8: progress: 
100%





  ● stats 
for 
query MULTI_TAG_LATEST_QUERY 
with 
parallel 
8: progress: 
43%

数据查询：可以展现每个 query 在每个测试周期的平均执行时间 (P50)、P90、 P75、 P25 以及 TPS 等各项指标。

Pxx 代表 xx 百分位数的延迟。例如 P75 是 14.35ms，说明执行 query 的次数中，有 25% 延迟高于它，75% 低于它 . P50 即中位数。
TPS：每秒执行 query 的次数.

┌─────────────────┬───────────────┐│ Overall Duration│       29.942s ││ Average Latency │       13.72ms ││ P75 Latency     │       14.35ms ││ P50 Latency     │       13.65ms ││ P25 Latency     │       12.92ms ││ TPS             │           582 │└─────────────────┴───────────────┘

测试结束后，你将收到一份汇总报告。战果如何，一目了然。

Writer 部分

start time：数据加载起始时间；
end time：数据加载终止时间；
size written to mxgate (bytes)：向 mxgate 写入数据的字节数；
lines inserted：插入数据的条数，由于 upsert 可能存在，这一数字可能会高于数据库中实际的数据条数。
compress ratio：压缩比，即向 mxgate 写入数据的大小和实际数据库中该表的大小的比值。

Benchmark 部分

每行代表某并发度下各 query 的执行结果。
每列代表每个 query 在各个并发度下的执行结果。
如果 query 集执行了多轮（混合负载的情况下，数据加载未结束，query 便会一直执行），则仅展示最后一轮的结果。
如果因为 query 执行错误或者用户中断执行，进度条会显示当前进度，统计信息是根据已经执行 query 的做出统计。

┌───────────────────────────────────────────────────────┐│            Summary Report for Stdin Writer            │├─────────────────────────────────┬─────────────────────┤│ start time:                     │ 2023-01-10 13:29:01 │├─────────────────────────────────┼─────────────────────┤│ stop time:                      │ 2023-01-10 13:29:58 │├─────────────────────────────────┼─────────────────────┤│ size written to mxgate (bytes): │ 848333400           │├─────────────────────────────────┼─────────────────────┤│ lines inserted:                 │ 1500000             │├─────────────────────────────────┼─────────────────────┤│ compress ratio:                 │ 1.56 : 1            │└─────────────────────────────────┴─────────────────────┘┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐│                                                Summary Report for Telematics Benchmark                                                │├─────────────────────┬─────────────────────────────────────┬─────────────────────────────────────┬─────────────────────────────────────┤│ Parallel\Query Name │ SINGLE_TAG_LATEST_QUERY             │ MULTI_TAG_LATEST_QUERY              │ SINGLE_TAG_DETAIL_QUERY             │├─────────────────────┼─────────────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────┤│ 8                   │ ┌─────────────────┬───────────────┐ │ ┌─────────────────┬───────────────┐ │ ┌─────────────────┬───────────────┐ ││                     │ │ Overall Duration│        30.00s │ │ │ Overall Duration│       36.401s │ │ │ Overall Duration│        29.94s │ ││                     │ │ Average Latency │       23.81ms │ │ │ Average Latency │         7.27s │ │ │ Average Latency │       13.72ms │ ││                     │ │ P75 Latency     │       24.91ms │ │ │ P75 Latency     │         8.13s │ │ │ P75 Latency     │       14.31ms │ ││                     │ │ P50 Latency     │       23.41ms │ │ │ P50 Latency     │         7.16s │ │ │ P50 Latency     │       13.65ms │ ││                     │ │ P25 Latency     │       20.89ms │ │ │ P25 Latency     │         6.64s │ │ │ P25 Latency     │       12.92ms │ ││                     │ │ TPS             │           335 │ │ │ TPS             │             1 │ │ │ TPS             │           582 │ ││                     │ └─────────────────┴───────────────┘ │ └─────────────────┴───────────────┘ │ └─────────────────┴───────────────┘ ││                     │ progress: 100%                      │ progress: 100%                      │ progress: 100%                      │└─────────────────────┴─────────────────────────────────────┴─────────────────────────────────────┴─────────────────────────────────────

开源：MatrixBench 的边界无限扩展

开源对于 MatrixBench 来说，是对于自身边界的无限扩展。开源之后，MatrixBench 是如何根据配置文件炮制出一套“兵法秘籍”，便一览无遗了。

这就好像你拥有查看森保一（日本足球队主帅）笔记本的权限，看看“名将”是如何运筹帷幄，从而率领蓝色武士连续扳倒两个前世界冠军。你也会突然明白，德尚在决赛上半场 40 分钟，面临两球落后的局势，一口气换下两名主力前锋的奥秘 —— 不同的场景当然要采取不同的配置和策略。不仅如此，你还对每个执法主裁的吹罚尺度了如指掌。在足球场上，他们像是 Benchmark 具体需要跑的 query —— 你的成绩它说了算。

开源的灵魂是自由，你可以随时随地修改 MatrixBench 的源代码为自己数据库和应用场景做“私人定制”。如同一名 FIFA 2023 玩家，总是饶有兴致打造一支独一无二的、自己心目中的完美球队。你精心定制开发了一款数据加载工具，也能轻松让它加入 MatrixBench 的“队伍”，一起打赢这场数据库压测的“比赛”。足球游戏中，裁判的各项参数也能调一调 —— 这个争议点球判不判，那个疑似越位吹不吹？往往细微的差别就能让比赛有截然不同的走向 —— 测试 query 也是这样，一点点写法的变动也会造成走不同的 query plan，最终的执行效率也会千差万别。

在数据库测试领域，个性化需求层出不穷：

想扩展数据特点的描述参数达到更深一层的定制化？
想让另外的程序掌控数据生成的逻辑？
想让 MatrixGate 以外的工具承担数据加载的重任？
新场景需要跑更丰富的 query 类型？
想支持别的数据库？

MatrixBench 有三个主要组件：Generator, Writer 和 Benchmark，分别负责数据生成、数据写入和 query 查询，均已被插件化。根据自己的需要，编写定制化插件，就可以通过 MatrixBench 的组件接口协议与主流程无缝衔接，即插即拔，安全可靠。

例如，目前已有三种 Generator：

Telematics
File
Nil

Telematics 会实时生成流式数据，发送给下游组件 Writer；File 从用户提供的 csv 文件读取数据，设成 Nil 相当于不略过数据加载这一步。假如现在你已经有了自己的数据生成器，你就可以编写一个名为 Exteral 的 Generator，把外部生成器数据接过来。仅需实现下面的接口：

// internal/engine/generator.gotype IGenerator interface {        NilCheck        ConfigurablePlugin        GetPrediction(*metadata.Table) (GeneratorPrediction, error)        ModifyMetadataConfig(*metadata.Config)        Run(GlobalConfig, *metadata.Metadata, WriteFunc) error        Close() error}

诚挚邀请你的加入

在现在的时间维度下，MatrixBench 是一名全能战士；但面向未来，它只是一位蹒跚学步的幼儿。因此，我们诚恳邀请你加入 mxbench 开源社区，帮我们一起丰满 MatrixBench 的羽翼。从修改一处拼写错误，到“生擒 bug”一只，甚至是重构代码，你的贡献将使它更加高内聚、低耦合、易扩展。

我们欢迎一切 PR 和 issue （注4）！YMatrix 开发团队给了 MatrixBench 生命，但只有靠社区的力量，它才能茁壮成长，持续进步，为数据库的优化和迭代精诚服务！

注释 / 参考链接

1

MatrixBench开源代码库：

https://github.com/ymatrix-data/mxbench

2

YMatrix 5.0 最新文档：

https://ymatrix.cn/doc/5.0/version_list

3

MARS2：

https://ymatrix.cn/doc/5.0/reference/storage/intro

4

MatrixGate 高性能数据加载工具：

https://ymatrix.cn/doc/5.0/datainput/matrixgate

一条有爱的分割线

每一次指尖的滑动

都是与 YMatrix 最亲密的交互

感谢阅读，期待与志同道合的你一路同行。

开源！MatrixBench：实时物联网场景的数据压测“兵法”