概述
架构
GreptimeDB 由以下关键组件组成：
Frontend：通过多种协议提供读写服务，并将请求转发到Datanode。Datanode：负责数据的持久化存储，例如存储到本地磁盘、S3 和 Azure Blob Storage 等。Metasrv元数据存储和分布式调度：协调Frontend和Datanode之间的操作。
概念
为了更好地理解 GreptimeDB，需要介绍一些概念：
table是GreptimeDB中存储用户数据的地方，有表结构和有序的主键。table通过其分区键被分割成称为region。region是表中的一个连续段，在某些关系型数据库中被视为分区。region可以在多个datanode上复制，其中任何一个副本都可以支持读请求，但只有一个副本支持写请求。datanode存储并为frontend提供region。一个datanode可以服务多个region，一个region可以由多个datanode服务。metasrv服务器存储集群的元数据，例如表、datanode、每个表的region等。它还协调frontend和datanode。frontend有一个 catalog 实现，它从metasrv中获取元数据，告诉相应的组件哪个table的region由哪个datanode提供服务。frontend是一个无状态服务，用于接收客户端的请求。它作为 proxy 根据 catalog 中的信息将读取和写入请求转发到相应的datanode。- 一个
table的时间线(time-series)由其主键标识。因为GreptimeDB是一个时间序列数据库，所以每个table必须有一个时间戳列。table中的数据将按其主键和时间戳排序，但顺序的实际实现方式比较特殊，可能会在将来发生变化。
工作原理
在深入了解每个组件之前，让我们先从高层次上了解一下 GreptimeDB 的工作原理。
- 用户可以通过各种协议与数据库交互，例如使用
InfluxDB line Protocol插入数据，然后使用 SQL 或 PromQL 查询数据。frontend是用户或客户端连接和操作数据库的组件，因此在其后面隐藏了datanode和metasrv。 - 假设用户向
frontend实例发送了 HTTP 请求来插入数据。当frontend接收到请求时，它会使用相应的协议解析器解析请求正文，并从metasrv的 catalog 中找到要写入的表。 frontend依靠推拉结合的策略缓存来自metasrv的元数据，因此它知道应将请求发送到哪个datanode，或者更准确地说，应该发送到哪个region。如果请求的内容需要存储在不同的region中，则请求可能会被拆分并发送到多个region。- 当
datanode接收到请求时，它将数据写入region中，然后将响应发送回frontend。写入region也意味着将数据写入底层的存储引擎中，该引擎最终将数据放置在持久化存储中。 - 当
frontend从目标datanodes 接收到所有响应时，就会将结果返回给用户。
有关每个组件的更多详细信息，请参阅以下指南：