【运维 Pro】时序场景实践与原理 - 1. 分布与分区

【运维 Pro】: 是由 YMatrix 售前和售后团队负责的栏目。除了介绍日常的数据库运维和使用知识，我们更希望能够通过介绍这些知识背后的原理，让大家和我们一起感知数据库的美妙。

摘要

有别于其它场景，时序场景中的数据、查询都有着更为明显的特征；也因此，YMatrix 可以针对这些特征进行深度优化，最终带来出色的性能表现。

然而在时序场景中使用 YMatrix 时，会发现不同的使用方式有时会带来明显的性能差异；究其原因，只有针对时序场景精心设计，才能最大的发挥 YMatrix 在时序场景的性能优势。

我们会从 YMatrix 在时序场景中的最佳实践出发，深入逻辑和原理，一起讨论我们做什么、如何做、为什么。

作者：徐福贵｜YMatrix 售后工程师 & 王任远｜YMatrix MXUI 研发工程师

01 准备知识

作为本系列的第一篇文章，我们先简单介绍一些准备知识。

什么是时序数据

简单来说，时序数据就是： 设备标识 + 时间戳 + 指标 * N 。

以一个传感器记录的温度数据作为简单的例子：

1. 设备标识：1 或多个字段组成的设备唯一标识

2. 时间戳：指标采集时刻的时间戳

3. 指标：设备采集到的许多不同的指标值

关于时序场景和时序数据的更多介绍，可以阅读 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 = "D0001"AND ts >= "2023/07/01 13:50:00" AND ts < "2023/07/01 14:00:00";

设备标识 + 时间戳

针对这两个典型的时序场景查询，使用 设备标识 + 时间戳 作为分布键，是最佳方案，可以使查询时涉及的数据分布更均匀。

此时，数据分布的情况如下：

扫描命中的数据

下图描述了这两个查询在执行时，命中数据的分布情况。从图中我们看出，命中的数据是在 2 个计算节点上均匀分布的，此时查询性能最佳。

SQL 1

扫描命中的数据

SQL 2

扫描命中的数据

为什么不能只用时间戳？

如果只用时间戳，会导致所有设备在某个时间点采集的数据都落在一个节点上，那么查询时只有一个数据节点的资源能够被充分利用。

扫描命中的数据

为什么不能只用设备标识？

这样的话一个设备的数据都在同一个计算节点上，当查询该设备的历史数据时，又仅有一个节点的资源能够被充分利用。

为什么不能用指标列？

一个指标列通常在一定取值范围内波动，并会有大量重复、空值；当指标列作为分布键，就会有大量同值数据分布在同一个节点上，不仅不能做到查询时涉及的数据均匀分布，连存储时的均匀分布都做不到。

03 如何选择分区键

由于几乎所有时序场景的查询，都包含时间戳作为限定条件，所以将时间戳作为分区键，无论是在插入数据还是在执行查询时，都能保证直接找到对应的分区，因此，将时间戳作为分区键，是最为合理的。

04 如何设计分区策略

简单来说，分区策略就是设置多长时间为一个分区。

分区机制对查询的加速主要在于能够能够减少查询时扫描数据的数量：当查询条件命中表中的某个分区时，数据库仅会对命中分区中的数据进行扫描，因此，查询条件命中的分区越少，其中的存储的数据越少，最终所扫描的数据就越少，执行速度也就越高。

因此，在设计分区策略时，我们的目标是尽可能的让查询条件命中的分区更少。

以两个典型的查询为例，我们来估算不同分区策略带来的查询开销差异：

1. 指定的某个日期（如 7 月 3 日）的所有设备的平均温度。

2. 指定的某周（如 7 月 3 日 ~ 7 月 9 日）某个设备的温度最大值/最小值。

假定每天的数据量为 N 条，有两种策略：

1. 按日分区：每天一个分区，每个分区含 N 条数据

2. 按周分区：每周一个分区，每个分区含 7N 条数据

对于按日分区策略，查询时扫描的分区和对应的数据量为：

对于按周分区策略，查询时扫描的分区和对应的数据量为：

由此可见，对于给定的查询，相比按周分区，按天分区策略在查询时扫描的数据量要小的多，所以效率要更高；而如果查询 1 被更频繁执行的，业务查询的整体耗时差异会更大。

总之，分区策略需要根据具体查询来设计。比如，当小时粒度的查询更多，那么按小时进行分区就会是更为合理的策略。

冷热数据：实际生产环境中，距离当前时间较远数据（冷数据）更有可能被按照更长的周期进行查询（比如按月），而距离当前时间较近（热数据）则更有可能被按照较短间隔查询（比如按小时）。因此，冷数据适宜设置更长的分区间隔（按月），热数据设置更小的分区间隔（按小时）。在最新的 YMatrix 5.1 中提供了降级存储功能，能够实现数据的全自动冷热分级。

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

欲了解更多超融合时序数据库相关信息，请访问 “YMatrix 超融合数据库”