InfluxDB 3.0 系统架构概述

InfluxData 最近公布了其最新时序数据库 InfluxDB 3.0 的系统架构。该架构包含四个主要组件，分别负责数据摄入、查询、压缩和垃圾回收，并支持两种主要的存储类型。此外，InfluxDB 3.0 还支持在本地和主要云服务提供商上原生运行。

架构核心设计

InfluxDB 3.0 架构的核心是工程师们对主要组件的解耦设计。这些组件之间不直接通信，而是通过 Catalog 和 Object Storage 进行通信。例如，数据摄入器（ingesters）和查询器（queriers）并不知道压缩器（compactors）和垃圾回收器（garbage collectors）的存在。这种设计使得各个组件可以独立扩展和部署。

数据摄入组件（蓝色）

数据摄入组件负责将数据输入数据库。用户将数据写入 Ingest Router，然后数据会被分片到多个 Ingesters 中，允许根据数据工作负载扩展 Ingesters 的数量。

每个 Ingester 会识别表、验证数据模式、按“时间”列分区数据、去重，并将其持久化为 Parquet 文件。Ingester 还会更新 Catalog，通知其他组件有新数据到达。InfluxDB 优化了写入路径，使写入延迟保持在毫秒级。

数据查询组件（绿色）

数据查询组件处理用户以 SQL 或 InfluxQL 发送的查询。用户将查询发送到 Query Router，然后 Query Router 将其转发给一个 Querier。

Querier 读取所需数据，构建查询计划，执行查询并返回结果。Queriers 可以根据查询工作负载进行扩展。它们执行的任务包括缓存元数据、读取和缓存数据、与 Ingesters 通信以获取尚未持久化的数据，以及构建和执行最佳查询计划。

数据压缩组件（红色）

数据压缩组件解决了 Object Storage 中存储大量小文件可能影响查询性能的问题。Compactors 在后台任务中读取新摄入的文件，并将其压缩为更少、更大且不重叠的文件。这一过程通过显著减少查询时的 I/O 操作来提升查询性能。

Compactors 的数量可以根据压缩工作负载进行扩展，考虑因素包括有新数据文件的表数量、文件大小以及新文件与现有文件的重叠数量。

垃圾回收组件（粉色）

垃圾回收组件负责管理数据保留和空间回收。它通过后台任务调度软删除和硬删除操作。

Catalog 和 Object Storage

Catalog 包含了数据库、表、列和文件等元数据，InfluxDB 使用与 Postgres 兼容的数据库来管理 Catalog。Object Storage 则仅包含 Parquet 文件，可以存储在本地磁盘或云平台（如 Amazon S3、Azure Blob Storage 或 Google Cloud Storage）上。

总结

InfluxDB 3.0 的系统架构通过解耦设计实现了高度可扩展性和灵活性。其主要组件包括数据摄入、查询、压缩和垃圾回收，分别负责不同的任务。Catalog 和 Object Storage 作为核心组件，支持在多种环境下运行，并优化了数据写入和查询性能。