数据模型
模型
GreptimeDB 使用时序表来进行数据的组织、压缩和过期管理。数据模型主要基于关系型数据库中的表模型,同时考虑到了时序数据的特点。
GreptimeDB 中的所有数据都被组织成表,每个表中的数据项由三种类型的列组成:Tag
、Timestamp
和 Field
。
- 表名通常与指标的名称相同。
Tag
列中存储经常被查询的元数据,其中的值是指标的标签,通常用于描述这些指标的特定特征。Tag
列具有索引,所以使用Tag
列的查询具备良好的性能。Timestamp
是时间序列数据库的基础,它表示数据生成的日期和时间。Timestamp 具有索引,所以使用Timestamp
的查询具有良好的性能。一个表只能有一个Timestamp
列。- 其他列是
Field
列,其中的值是被收集的数据指标。这些指标通常是数值,但也可能是其他 类型的数据,例如 String 或地理位置。Field
列没有被索引,但是可以被高效地查询和计算,例如求最大最小值、均值和百分比分布等。对该字段做过滤查询会全表扫描,这可能会消耗大量资源并且性能较差。
假设我们有一个名为 system_metrics
的时间序列表用于监控独立设备的资源使用情况。该表的数据模型如下:
这与大家熟悉的表模型非常相似。不同之处在于 Timestamp
约束,它用于将 ts
列指定为此表的时间索引列。
- 表名为
system_metrics
。 - 对于
Tag
列,host
列表示收集的独立机器的主机名,idc
列显示机器所在的数据中心。这些是查询元数据,可以在查询时有效地过滤数据。 Timestamp
列ts
表示收集数据的时间。使用该列查询具有时间范围的数据时具备较高的性能。Field
列中的cpu_util
、memory_util
、disk_util
和load
列分别表示机器的 CPU 利用率、内存利用率、磁盘利用率和负载。 这些列包含实际的数据并且不被索引。应当避免在查询条件中使用Field
列,这会消耗大量资源并且性能较差。
要了解如何指定 Tag
、Timestamp
和 Field
列,请参见表管理和 CREATE 语句。
设计考虑
GreptimeDB 基于表进行设计,原因如下:
- 表格模型易于学习,具有广泛的用户群体,我们只需引入时间索引的概念即可实现时间序列。
- Schema 是描述数据特征的元数据,对于用户来说更方便管理和维护。通过引入 Schema 版本的概念,我们可以更好地管理数据兼容性。
- Schema 通过其类型、长度等信息带来了巨大的优化存储和计算的好处,我们可以进行有针对性的优化。
- 当我们有了表格 Schema 后,自然而然地引入了 SQL,并用它来处理各种索引表之间的关联分析和聚合查询,为用户抵消了学习和使用成本。
- 使用多值模型使其中一行数据可以具有多个指标列,而不是 OpenTSDB 和 Prometheus 采用的单值模型。多值模型面向数据源建模,一个 metric 可以有用 field 表示的值。多值模型的好处是可以一次性把多个值写入到数据库中,而单值模型则要分成多条数据。
GreptimeDB 使用 SQL 管理表 Schema。有关更多信息,请参见表管理。但是,我们对 Schema 的定义并不是强制性的,而是倾向于Schemaless的方式,类似于 MongoDB。有关更多详细信息,请参见自动生成表结构。