数据分布是数据库的存储和计算关键设计之一，不同业务场景下不同的数据分布会有数量级的性能差异。现代分布式数据库系统数据分布在多节点上，对数据分布提出了更多挑战。
本文主要openGemini为例，介绍在现代分布式数据库上进行高性能数据分布设计范式，主要包括分区键、分片键、主键和排序键等的设计范式。
分区键
分区是SMP架构数据库系统开始使用的数据分布技术。
SMP: Symmetric Multi-Processor，即对称多处理器架构
现代数据库系统通常使用PARTITION BY来控制分区，比如按时间（datetime）分区
PARTITION BY datetime
根据设定的分区字段值，将数据分布到不同的分区中。分区是物理存储单元，存储了不同范围区间的数据。
分区键设计范式：分区键值域连续且呈均匀分布。在Log, trace, event, metric等可观测性业务场景中，时间字段是作为分区键的最佳选择。
> show shards
name: mst
+---------+-----+-------------+----------------------+----------------------+----------------------+-----+
|database | rp | shard_group | start_time | end_time | expiry_time | ... |
+---------+-----+-------------+----------------------+----------------------+----------------------+-----+
| db | auto| 1 | 2023-09-25T00:00:00Z | 2023-10-02T00:00:00Z | 2023-10-02T00:00:00Z | ... |
+---------+-----+-------------+----------------------+----------------------+----------------------+-----+
10 columns, 1 rows in set
Elapsed: 4.599747ms
openGemini默认使用时间字段作为分区键，使得：
分片键
数据库系统从"scale-up"演进到"scale-out"，从"SMP"演进到"MMP"，都是为了更好解决大规模数据“存”和“算”问题。“分治”是大规模数据经典的解决方案。
MPP: Massively Parallel Processing，即大规模并行处理架构
现代数据库系统通常使用DISTRIBUTE BY来控制分片，比如按网络监控的主机地址（host）进行分片
DISTRIBUTE BY host
根据设定的分片字段值，将数据分布到不同的分片中。分片是物理存储单元，存储了离散聚簇的数据。
分片键设计范式：分片键值域离散且呈非均匀分布。通常需要根据实际的查询业务来选择分片键。
例如，业务需要对host去重，
SELECT DISTINCT host FROM t
数据库中DISTINCT通常会重写为GROUP BY,
SELECT host FROM t GROUP BY host
host字段在分片中的基数 C
> select cardinality(host) as C from t.shard.0
name: t.shard.0
+-------------+
| C |
+-------------+
| 5000000 |
+-------------+
1 columns, 1 rows in set
> select cardinality(host) as C from t.shard.1
name: t.shard.1
+-------------+
| C |
+-------------+
| 5000000 |
+-------------+
1 columns, 1 rows in set
Elapsed: 1.11137ms
当表的分片数量为N时，在reduce阶段，需要计算的数据量是：
O(C∗N)
选择host作为分片键，将reduce阶段需要计算的数据量从C * N（C: host的基数，N: shard的数量）优化到C，大幅减少待reduce的数据量。
> select cardinality(host) as C from t_sharding_host.shard.0
name: t_sharding_host.shard.0
+-----------+
| C |
+-----------+
| 2500000 |
+-----------+
1 columns, 1 rows in set
> select cardinality(host) as C from t_sharding_host.shard.1
name: t_sharding_host.shard.1
+-----------+
| C |
+-----------+
| 2500000 |
+-----------+
1 columns, 1 rows in set
Elapsed: 1.11137ms
openGemini默认使用Tags作为分区键，使得：
主键和排序键
主键用于指导数据库构建索引以加速查询，数据库中通常使用PRIMARY KEYS来设置主键。
PRIMARY KEYS host
排序键将数据按指定顺序排序，数据库中通常使用ORDERED KEYS来设置排序键。
ORDERED KEYS host
主键和排序键设计范式：排序键值域基数小，主键为排序键前缀。为什么需要这样设计呢？
由于索引并不是直接指向PRIMARY KEYS对应行的值，而是对应到该行对应到的row_id，row_id能快速定位到数据所在位置，所以row_id才是真正的唯一主键。
> select __row_id__,host from t name: t+-----------+--------+| __row_id__ | host |+-----------+--------+| 1 | h1 |+-----------+--------+| 2 | h2 |+-----------+--------+| 3 | h3 |+-----------+--------+| 4 | h4 |+-----------+--------+| 5 | h5 |+-----------+--------+2 columns, 5 rows in set
Elapsed: 1.11137ms
row_id序列和PRIMARY KEYS序列顺序一致，数据有序分布实质上就是构建了一个高度为1的B-Tree，使得：
openGemini默认使用Tags作为主键和排序键，支持在Tags上高效的搜索和聚合。
总结
![]()
Purpose-Build分布式数据库系统与Classic分布式数据库系统在数据分布设计范式上是相同的。openGemini作为时序场景专用数据库，无需进行复杂数据分布设计，降低了使用门槛。数据分布范式能帮助我们正确设计Tags，以
openGemini官网：http://www.openGemini.org
openGemini开源地址：https://github.com/openGemini
openGemini公众号：
![]()
欢迎关注～ 诚邀你加入 openGemini 社区，共建、共治、共享未来！
