跳到主要内容
版本：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 (物联网数据库)​

针对物联网传感器高频时序数据优化的数据库系统。GreptimeDB 可高效处理物联网设备产生的大规模时序数据，提供弹性扩展能力。

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 中用于实时处理传入数据的强大解析和转换机制。Pipeline 由可配置的处理器组成，用于预处理原始数据；分发器用于将数据路由到不同管道；以及转换规则用于数据类型转换和表结构定义。支持多种输入格式和数据源（包括日志、Prometheus 指标和其他可观测性数据），提供广泛的处理能力，包括时间戳解析、正则匹配、字段提取和数据类型转换，实现可观测性数据的结构化存储和高效查询。

PromQL (Prometheus 查询语言)​

专为 Prometheus 设计的时序数据查询语言。GreptimeDB 支持 PromQL 且兼容性接近 100%，支持用户执行复杂的时序数据分析操作并使用现有的 Prometheus 仪表盘和告警规则。

R​

Read Replica (读副本)​

GreptimeDB 企业版中的功能，通过创建额外的只读数据实例来提升查询性能和可扩展性。读副本将读取工作负载分布到多个实例上，减少主数据库的负载同时提供更快的查询响应。该功能支持数据访问点的地理分布，提升读取操作的高可用性，并在企业环境中实现读密集型工作负载的高效扩展。

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 (标签)​

GreptimeDB 数据模型中用于唯一标识时序数据的列类型。具有相同 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 生态的最新功能演进与技术概念扩展。