数据模型

模型

GreptimeDB 使用时序表来进行数据的组织、压缩和过期管理。数据模型主要基于关系型数据库中的表模型,同时考虑到了时序数据的特点。

GreptimeDB 中的所有数据都被组织成表,每个表中的数据项由三种类型的列组成:TagTimestampField

  • 表名通常与指标的名称相同。
  • Tag 列中存储经常被查询的元数据,其中的值是指标的标签,通常用于描述这些指标的特定特征。Tag 列具有索引,所以使用 Tag 列的查询具备良好的性能。
  • Timestamp 是时间序列数据库的基础,它表示数据生成的日期和时间。Timestamp 具有索引,所以使用 Timestamp 的查询具有良好的性能。一个表只能有一个 Timestamp 列。
  • 其他列是 Field 列,其中的值是被收集的数据指标。这些指标通常是数值,但也可能是其他类型的数据,例如 String 或地理位置。Field 列没有被索引,对该字段查询会全表扫描,这可能会消耗大量资源并且性能较差。

假设我们有一个名为 system_metrics 的时间序列表用于监控独立设备的资源使用情况。该表的数据模型如下:

time-series-table-model

这与大家熟悉的表模型非常相似。不同之处在于 Timestamp 约束,它用于将 ts 列指定为此表的时间索引列。

  • 表名为 system_metrics
  • 对于 Tag 列,host 列表示收集的独立机器的主机名,idc 列显示机器所在的数据中心。这些是查询元数据,可以在查询时有效地过滤数据。
  • Timestampts 表示收集数据的时间。使用该列查询具有时间范围的数据时具备较高的性能。
  • Field 列中的 cpu_utilmemory_utildisk_utilload 列分别表示机器的 CPU 利用率、内存利用率、磁盘利用率和负载。 这些列包含实际的数据并且不被索引。应当避免在查询条件中使用 Field 列,这会消耗大量资源并且性能较差。

要了解如何指定 TagTimestampField 列,请参见表管理CREATE 语句

设计考虑

GreptimeDB 基于表进行设计,原因如下:

  • 表格模型易于学习,具有广泛的用户群体,我们只需引入时间索引的概念即可实现时间序列。
  • Schema 是描述数据特征的元数据,对于用户来说更方便管理和维护。通过引入 Schema 版本的概念,我们可以更好地管理数据兼容性。
  • Schema 通过其类型、长度等信息带来了巨大的优化存储和计算的好处,我们可以进行有针对性的优化。
  • 当我们有了表格 Schema 后,自然而然地引入了 SQL,并用它来处理各种索引表之间的关联分析和聚合查询,为用户抵消了学习和使用成本。
  • 使用多值模型使其中一行数据可以具有多个指标列,而不是 OpenTSDB 和 Prometheus 采用的单值模型。多值模型面向数据源建模,一个 metric 可以有用 field 表示的值。多值模型的好处是可以一次性把多个值写入到数据库中,而单值模型则要分成多条数据。

GreptimeDB 使用 SQL 管理表 Schema。有关更多信息,请参见表管理。但是,我们对 Schema 的定义并不是强制性的,而是倾向于无 Schema 的方法,类似于 MongoDB。有关更多详细信息,请参见自动生成表结构