跳到主要内容
版本：1.1

Glossary（术语表）

本文档解释 GreptimeDB 在可观测数据、存储、查询和运维中的常用术语。

注：该排名顺序按照英文词汇首字母正序排列。

A​

Anomaly Detection (异常检测)​

识别数据点、事件或观测值显著偏离常态的过程。在时序数据场景中，异常检测可辅助发现可能表征关键事件的非常规模式。

Append Only Table (Append Only 表)​

GreptimeDB 中针对写入密集型工作负载优化的表类型，数据仅插入而不更新或删除。这种设计显著提升写入和查询性能，特别适用于日志分析和时序数据场景。

C​

Cardinality (基数)​

衡量数据库元素唯一性的指标，如数据列中唯一值的数量。高基数场景（尤其在时序数据中）将显著提升存储复杂度与资源需求。

Cloud-Native Design (云原生架构)​

基于云计算框架构建弹性可扩展应用的架构方法论。GreptimeDB 的云原生设计支持从边缘计算节点到云端分布式集群的无缝扩展。

Columnar Storage (列式存储)​

按列而非行组织数据表的存储格式。该格式显著提升分析型查询效率，是 GreptimeDB 实现高性价比的重要技术基础。

D​

Decoupled Compute and Storage Architecture (存算分离架构)​

将计算资源与存储资源解耦管理的架构设计。该架构支持独立扩展与资源优化，实现工作负载管理的灵活性与高性能。

E​

Edge Database (边缘数据库)​

部署在网络边缘侧（临近数据源或终端用户）的数据库系统，通过降低数据传输延迟实现实时数据处理。

Edge Deployment (边缘部署)​

在临近数据源或终端用户的边缘节点部署服务的实践方案。GreptimeDB 支持边缘部署模式，可在资源受限环境下实现实时数据处理。

Event Management (事件管理)​

对指标、日志、追踪等事件数据进行采集、组织与分析的系统化实践，是保障实时系统稳定运行的核心环节。

D​

Datanode (数据节点)​

GreptimeDB 分布式架构中负责数据存储和处理的核心组件。Datanode 处理数据摄入、存储管理、本地数据查询执行，并维护包含实际表数据的 region。可在集群中部署多个 datanode 以提供水平可扩展性、容错能力和分布式数据处理能力。

F​

Field (字段)​

GreptimeDB 数据模型中包含实际测量数据或日志内容的列类型。Field 存储数值、文本内容或其他数据指标，代表时序数据中的核心信息，与 Tag 和 Time Index 列相补构成完整的数据模型。

Flow Engine (Flow 引擎)​

GreptimeDB 的持续聚合引擎，支持对持续写入的时序数据进行增量计算。Flow Engine 类似智能物化视图，当源表有新数据到达时自动更新结果表。聚合和 TQL workload 使用 batching mode；原始的 streaming mode 已经废弃，不推荐新 workload 使用。

Frontend (前端节点)​

GreptimeDB 分布式架构中的查询处理层，作为客户端连接的入口点。Frontend 节点处理 SQL 解析、查询规划、分布式查询协调和结果聚合。它们将查询路由到适当的 datanode，管理客户端会话，并为各种数据库接口（包括 MySQL、PostgreSQL 和 GreptimeDB 原生协议）提供协议兼容性。

G​

GreptimeCloud​

GreptimeDB 的全托管云服务，提供 serverless 自动扩展的数据库即服务（DBaaS）能力。GreptimeCloud 通过自动扩展、按量付费、企业级安全和无缝云边协同部署等特性消除运维开销，非常适合寻求无忧可观测性数据库解决方案的组织。

I​

IoT Cloud (物联网云平台)​

专为物联网应用设计的云计算平台，提供海量设备数据存储、处理与连接管理能力。

IoT Database (物联网数据库)​

针对物联网设备产生的高频数据进行优化的数据库，用于存储和查询时序测量、设备事件和日志。随着设备数量和数据量增长，它可以提供可扩展的存储和查询能力。

IoT Observability (物联网可观测性)​

使用指标、日志和事件监控物联网设备及其配套服务的状态与行为，帮助团队保障可靠性并诊断性能问题。

Interoperability (协议互操作性)​

异构系统间无缝协作的能力。GreptimeDB 原生支持 SQL、InfluxDB、OpenTelemetry、Prometheus、Elasticsearch、Loki 等协议与 API，实现开箱即用的系统集成。

L​

Log Aggregation (日志聚合)​

对一组日志执行计算以生成单个摘要统计数据，以供分析和故障排除，例如 SUM，COUNT 等。

Log Management (日志管理)​

对日志进行采集、存储、查询和可视化的过程，用于性能分析和安全调查。

M​

Memory Leak (内存泄漏)​

程序未能正确释放闲置内存导致的软件缺陷，长期运行可能引发系统性能下降或崩溃。

Metric Engine (指标引擎)​

GreptimeDB 用于大量逻辑指标表的存储引擎。它将逻辑表映射到共享的物理宽表，以复用列和元数据，从而降低存储开销，并改善列式压缩和查询效率。Metric Engine 使用 Mito Engine 进行物理存储。

Mito Engine (Mito 引擎)​

GreptimeDB 的默认存储引擎，基于日志结构合并树（LSM-Tree）架构，针对时序工作负载进行优化。Mito 具备预写日志（WAL）、内存表和时间窗口压缩策略（TWCS），能够处理高吞吐量写入同时保持出色的查询性能。原生集成对象存储解决方案（S3、GCS、Azure Blob）并实现分层缓存以优化存储成本和访问速度。

L​

LSM-Tree (日志结构合并树)​

GreptimeDB 存储引擎采用的数据结构，通过先将数据写入日志再定期合并为有序结构来优化写入性能。该设计特别适合高写入吞吐量的时序工作负载。

M​

Metasrv (元数据服务)​

GreptimeDB 分布式架构中的元数据管理服务，维护集群状态、表结构和 region 分布信息。Metasrv 协调集群操作，管理表的创建和修改，处理 region 分配和迁移，确保集群范围内的元数据一致性。它作为集群管理的中央控制平面，是所有元数据操作的权威数据源。

O​

Observability (可观测性)​

通过系统外部输出推断内部状态的能力。GreptimeDB 作为可观测性基础设施，可通过指标、日志与事件数据实现系统性能监控与深度洞察。

OpenTelemetry​

面向云原生应用的开源可观测性框架，提供遥测数据（追踪、指标、日志）的采集、处理与导出工具链。GreptimeDB 深度集成 OpenTelemetry 以强化数据可观测性。

P​

Pipeline (数据管道)​

GreptimeDB 在数据写入存储前执行解析和转换的配置。Processor 解析或修改字段，transform 将字段映射为表中的列和类型，dispatcher 可以根据输入记录中的值选择 Pipeline。Pipeline 支持时间戳解析、正则匹配、字段提取和类型转换，使可观测数据能够以便于高效查询的结构写入存储。

PromQL (Prometheus 查询语言)​

Prometheus 用于查询时序数据的语言。GreptimeDB 提供接近 100% 的 PromQL 兼容性，并支持使用已有的 Prometheus 仪表盘和告警规则。具体限制和范围参见兼容性列表。

R​

Read Replica (读副本)​

GreptimeDB Enterprise 为表增加只读 Follower Region 的功能，用于扩展读取负载并降低 Leader Region 的查询压力。Leader Region 和 Follower Region 共享对象存储中的 SST 文件；Leader 同步 SST metadata，Follower 在读取最新数据时从 Leader 获取尚未 flush 的数据。通过 Datanode group 可以把 Leader 和 Follower 部署到不同节点，隔离读写 workload、缩短查询响应时间、支持地理分布式访问并提高读取可用性。参见读副本。

Region (区域)​

GreptimeDB 架构中数据分布的基本单元。Region 包含表数据的子集，可分布在集群的不同节点上。每个 Region 管理自己的存储、索引和查询处理，实现水平扩展和容错能力。

Repartition (重分区)​

通过合并已有分区并按新规则拆分分区来调整建表后的分区边界的过程。重分区用于更好地匹配当前数据分布、缓解热点，并减少冷小分区。

Rust​

以前沿内存安全特性著称的系统级编程语言。GreptimeDB 采用 Rust 语言构建，为其高性能与高可靠性提供底层保障。

S​

Scalability (弹性扩展)​

通过垂直扩展（提升单节点性能）或水平扩展（增加集群节点）应对数据量与查询负载增长的能力。GreptimeDB 的弹性扩展特性确保系统在业务增长时持续保持高性能。

SQL​

关系型数据库的标准查询语言。GreptimeDB 支持使用 SQL 对指标、日志及事件数据进行高效查询。

Stream Processing (流式处理)​

对到达的数据流进行连续实时处理的技术。GreptimeDB 的 Flow Engine 通过 batching mode 提供持续聚合能力；其原始的 streaming mode 已经废弃，不推荐新 workload 使用。

T​

Tag (标签)​

用于标识时间序列的列语义。Tag 值相同的数据行属于同一条时间序列。Tag 通常保存主机名、服务名或设备 ID 等维度，并声明为 PRIMARY KEY 列。

Time Index (时间索引)​

GreptimeDB 表中的特殊时间戳列，作为时序数据的主要时间维度。每个 GreptimeDB 表都需要一个 Time Index 列来按时间顺序组织数据，实现基于时间的查询，支持高效的时序操作，如降采样和时间窗口聚合。

Time Series Database (时序数据库)​

专为时间戳索引数据设计的数据库类型。GreptimeDB 的可观测数据模型支持 metrics、logs、traces 和事件数据，时序 workload 是其中一类。

Table Sharding (表分片)​

将一张大表拆分为多个更小分区的技术。在 GreptimeDB 中，表分片有助于将负载分散到多个 region 上，并提升热点表或大表的吞吐能力。

T​

Trigger (触发器)​

GreptimeDB 企业版中的监控和告警功能，支持对时序数据条件进行自动化评估。Trigger 在指定间隔内持续监控表中的数据，执行基于 SQL 的规则来检查预定义的阈值或条件，并在满足条件时通过 webhook 发送通知。该功能与 Alertmanager 等告警系统集成，支持自定义标签和注释，特别适用于实时系统监控、性能告警和自动化事件响应。

U​

Unified Analysis (统一分析)​

在单一平台集成多源异构数据分析的能力。GreptimeDB 通过兼容 SQL 与 PromQL 实现跨数据类型（指标/日志/事件）的统一查询分析。

Unified Observability (统一可观测性)​

将 metrics、logs 和 traces 整合到单一系统中的数据库架构方法，消除数据孤岛并降低运维复杂性。GreptimeDB 通过将所有遥测数据类型视为带有时间戳的宽事件来实现统一可观测性，实现跨信号关联、简化数据管道和成本高效的可观测性基础设施。

W​

WAL (预写日志)​

GreptimeDB 用于确保数据持久性和一致性的日志机制。WAL 在数据变更应用到主存储之前记录所有变更，在系统故障时实现数据恢复。GreptimeDB 支持灵活的 WAL 选项，包括本地磁盘存储或 Kafka 等分布式服务。

Wide Events (宽事件)​

可观测性 2.0 中的基础概念，将 metrics、logs 和 traces 融合为单一综合事件的上下文丰富、高维度遥测数据。宽事件捕获每次服务交互的广泛上下文信息，包括高基数字段（用户 ID、会话 ID）、业务逻辑数据、基础设施详情和请求元数据。GreptimeDB 原生支持将宽事件作为带时间戳的可观测性数据，支持复杂的多维度查询并解决系统行为分析中的 "unknown unknowns" 问题。

V​

Vector Processing (向量化处理)​

GreptimeDB 查询引擎采用的高性能数据处理技术，通过批量操作数据向量（数组）来提升查询性能。支持 SIMD 指令加速，显著提升大规模时序数据的分析速度。

Vehicle Data Collection (车载数据采集)​

采集车辆传感器读数、GPS 定位和诊断信息等数据的过程。

Vehicle-Cloud Integrated TSDB (车云协同时序数据库)​

由车端或边缘系统采集数据、云端服务汇总存储并查询数据的时序数据库部署方式，可为车联网应用提供高效存储和实时分析能力。

注：本术语表将持续更新，以反映 GreptimeDB 生态的最新功能演进与技术概念扩展。