写点什么

开源!MatrixBench:实时物联网场景的数据压测“兵法秘籍”

  • 2023-02-03
    北京
  • 本文字数:7134 字

    阅读完需:约 23 分钟

开源!MatrixBench:实时物联网场景的数据压测“兵法秘籍”

目录


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

2. 为什么选择 MatrixBench?

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

4. 诚恳邀请你的加入


01 MatrixBench 开源了!再认识它一下


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


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



现在,它开源了!👇


MatrixBench(点击“左方链接”,访问开源代码库!)


02 为什么选择 MatrixBench?


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


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


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


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


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


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


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


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


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

  • 数据库的各项 GUC 值;

  • 表结构;

  • 表的分区键;

  • 表的分布键;

  • 表分区范围的设置;

  • 索引;

  • 索引中的参数;

  • MatrixGate(YMatrix 配套高性能数据加载工具)的启动参数。


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


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


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


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


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


[database]  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 查询,(“只加载,不查询”,“只查询,不加载”,“加载和查询同时跑”均能配置哦!),把各项关键的测试数据展现在你的面前。


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

  1. period start, period end, period:该统计窗口的起止时间和时间段;

  2. count written:已经写入的数据行数和预计数据行数,以及二者的百分比。xx in this period:该统计窗口内写入的行数;

  3. size written:已经写入的数据字节数和预计数据字节数,以及二者的百分比。xx in this period:该统计窗口内写入的字节数;

  4. 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 等各项指标。


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

  2. 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 部分

  1. start time:数据加载起始时间;

  2. end time:数据加载终止时间;

  3. size written to mxgate (bytes):向 mxgate 写入数据的字节数;

  4. lines inserted:插入数据的条数,由于 upsert 可能存在,这一数字可能会高于数据库中实际的数据条数。

  5. compress ratio:压缩比,即向 mxgate 写入数据的大小和实际数据库中该表的大小的比值。

  • Benchmark 部分

  1. 每行代表某并发度下各 query 的执行结果。

  2. 每列代表每个 query 在各个并发度下的执行结果。

  3. 如果 query 集执行了多轮(混合负载的情况下,数据加载未结束,query 便会一直执行),则仅展示最后一轮的结果。

  4. 如果因为 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%                      │└─────────────────────┴─────────────────────────────────────┴─────────────────────────────────────┴─────────────────────────────────────┘
复制代码


03 开源: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}
复制代码

04 诚挚邀请你的加入


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


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


原文链接

本文为 YMatrix 原创内容,未经允许不得转载。

欲了解更多超融合时序数据库相关信息,请访问 “YMatrix 超融合数据库” 官方网站

发布于: 2 小时前阅读数: 4
用户头像

MatrixDB 超融合时序数据库 2021-10-28 加入

全球超融合时序数据库开创者,专为物联网、车联网、工业互联网和智慧城市提供一站式数据平台。

评论

发布
暂无评论
开源!MatrixBench:实时物联网场景的数据压测“兵法秘籍”_开源_YMatrix 超融合数据库_InfoQ写作社区