河南省建设厅官方网站,连云港网站建设连云港,免费手机建站平台,wordpress域名重复【运维 Pro】: 是由 YMatrix 售前和售后团队负责的栏目。除了介绍日常的数据库运维和使用知识#xff0c;我们更希望能够通过介绍这些知识背后的原理#xff0c;让大家和我们一起感知数据库的美妙。
摘要
有别于其它场景#xff0c;时序场景中的数据、查询都有着更为明显的…【运维 Pro】: 是由 YMatrix 售前和售后团队负责的栏目。除了介绍日常的数据库运维和使用知识我们更希望能够通过介绍这些知识背后的原理让大家和我们一起感知数据库的美妙。
摘要
有别于其它场景时序场景中的数据、查询都有着更为明显的特征也因此YMatrix 可以针对这些特征进行深度优化最终带来出色的性能表现。
然而在时序场景中使用 YMatrix 时会发现不同的使用方式有时会带来明显的性能差异究其原因只有针对时序场景精心设计才能最大的发挥 YMatrix 在时序场景的性能优势。
我们会从 YMatrix 在时序场景中的最佳实践出发深入逻辑和原理一起讨论我们做什么、如何做、为什么。 作者徐福贵YMatrix 售后工程师 王任远YMatrix MXUI 研发工程师
01 准备知识
作为本系列的第一篇文章我们先简单介绍一些准备知识。
什么是时序数据
简单来说时序数据就是 设备标识 时间戳 指标 * N 。
以一个传感器记录的温度数据作为简单的例子 设备标识1 或多个字段组成的设备唯一标识 时间戳指标采集时刻的时间戳 指标设备采集到的许多不同的指标值
关于时序场景和时序数据的更多介绍可以阅读 YMatrix 官方文档。参考时序数据模型
使用 MARS3 存储引擎创建分区表
通常的在时序场景会使用分区表进行存储。相比较其他数据库YMatrix 针对时序场景进行了全方位优化拥有诸多优势。这里我们以最新的 MARS3 存储引擎为例其他存储类型也可参考初步介绍如何针对使用场景创建表以及其背后的基础逻辑。 MARS3 是在 YMatrix 5.1 中发布的最新存储引擎相比 MARS2, 提供了数据更新与删除功能并支持增删列及 MVCC 机制在 AP 和 TP 场景下都有明显的性能提升。 对应上面的例子我们可以这样创建表
CREATE TABLE ts_demo( ts timestamp WITH time zone, device_id varchar(20) , temperature float)USING mars3DISTRIBUTED BY (ts, device_id) -- 分布键ts device_idORDER BY (ts,device_id) -- MARS3 特有排序列PARTITION BY RANGE(ts) -- 分区键: ts( -- 分区策略每天一个分区 START (2023-07-01) INCLUSIVE END (2023-07-10) EXCLUSIVE EVERY (interval 1 day), DEFAULT PARTITION default_p) ;
复制代码
针对时序场景在创建表时除了数据对应的字段类型我们还需要重点关注和理解两个基础的问题
02 如何选择分布键
在 YMatrix 中一张表的数据会根据分布键和分布算法分散在不同节点上。
当执行查询时如果涉及的数据均匀的分布在所有计算节点上那么负载就会平均分配到每个节点上自然能在并行执行时更充分的利用硬件资源达到最佳性能表现。
反之如果查询涉及的数据分布不均那么执行查询时就会出现数据量大的节点负载大数据量小的节点负载小的问题负载分布不均就意味着一些节点的资源未能充分利用最终性能表现就可能不达预期。
因此我们选择表的分区键基本原则是让查询时涉及的数据尽可能均匀分布至各个节点上数据分布越均匀查询性能就越好。
要达到这一目的首先需要理解时序场景查询的特点。
通常来讲时序场景查询的条件均包含 时间戳和设备标识 的限定条件比如
1. 某一时刻所有设备的某个指标的均值 。
--- SQL 1求某一个时刻(2023/07/01 13:50:00) 所有设备的温度的平均值SELECT AVG(temperature) FROM test_demo WHERE ts 2023/07/01 13:50:00
复制代码
2. 指定时间段内所有设备的某个指标的最大最小值。
--- SQL 2求指定设备(D0001) 的在指定时间区间( [2023/07/01 13:00 ~ 14:00) )的温度的平均值SELECT AVG(temperature) FROM test_demoWHERE device_id D0001AND ts 2023/07/01 13:50:00 AND ts 2023/07/01 14:00:00;
复制代码
设备标识 时间戳
针对这两个典型的时序场景查询使用 设备标识 时间戳 作为分布键是最佳方案可以使查询时涉及的数据分布更均匀。
此时数据分布的情况如下 扫描命中的数据
下图描述了这两个查询在执行时命中数据的分布情况。从图中我们看出命中的数据是在 2 个计算节点上均匀分布的此时查询性能最佳。
SQL 1 扫描命中的数据
SQL 2 扫描命中的数据
为什么不能只用时间戳
如果只用时间戳会导致所有设备在某个时间点采集的数据都落在一个节点上那么查询时只有一个数据节点的资源能够被充分利用。 扫描命中的数据
为什么不能只用设备标识
这样的话一个设备的数据都在同一个计算节点上当查询该设备的历史数据时又仅有一个节点的资源能够被充分利用。 为什么不能用指标列
一个指标列通常在一定取值范围内波动并会有大量重复、空值当指标列作为分布键就会有大量同值数据分布在同一个节点上不仅不能做到查询时涉及的数据均匀分布连存储时的均匀分布都做不到。
03 如何选择分区键
由于几乎所有时序场景的查询都包含时间戳作为限定条件所以将时间戳作为分区键无论是在插入数据还是在执行查询时都能保证直接找到对应的分区因此将时间戳作为分区键是最为合理的。
04 如何设计分区策略
简单来说分区策略就是设置多长时间为一个分区。
分区机制对查询的加速主要在于能够能够减少查询时扫描数据的数量当查询条件命中表中的某个分区时数据库仅会对命中分区中的数据进行扫描因此查询条件命中的分区越少其中的存储的数据越少最终所扫描的数据就越少执行速度也就越高。
因此在设计分区策略时我们的目标是尽可能的让查询条件命中的分区更少。
以两个典型的查询为例我们来估算不同分区策略带来的查询开销差异 指定的某个日期如 7 月 3 日的所有设备的平均温度。 指定的某周如 7 月 3 日 ~ 7 月 9 日某个设备的温度最大值/最小值。
假定每天的数据量为 N 条有两种策略 按日分区每天一个分区每个分区含 N 条数据 按周分区每周一个分区每个分区含 7N 条数据
对于按日分区策略查询时扫描的分区和对应的数据量为 对于按周分区策略查询时扫描的分区和对应的数据量为 由此可见对于给定的查询相比按周分区按天分区策略在查询时扫描的数据量要小的多所以效率要更高而如果查询 1 被更频繁执行的业务查询的整体耗时差异会更大。
总之分区策略需要根据具体查询来设计。比如当小时粒度的查询更多那么按小时进行分区就会是更为合理的策略。 冷热数据实际生产环境中距离当前时间较远数据冷数据更有可能被按照更长的周期进行查询比如按月而距离当前时间较近热数据则更有可能被按照较短间隔查询比如按小时。因此冷数据适宜设置更长的分区间隔按月热数据设置更小的分区间隔按小时。在最新的 YMatrix 5.1 中提供了降级存储功能能够实现数据的全自动冷热分级。 本文为 YMatrix 原创内容未经允许不得转载。
欲了解更多超融合时序数据库相关信息请访问 “YMatrix 超融合数据库”
