数据模型

模型

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

GreptimeDB 中的所有数据都被组织成表，每个表中的数据项由三种类型的列组成：Tag、Timestamp 和 Field。

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

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

time-series-table-model

这与大家熟悉的表模型非常相似。不同之处在于 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 的定义并不是强制性的，而是倾向于无 Schema 的方法，类似于 MongoDB。有关更多详细信息，请参见自动生成表结构。