Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: update why greptimedb #1436

Merged
merged 11 commits into from
Jan 8, 2025
Original file line number Diff line number Diff line change
Expand Up @@ -5,109 +5,84 @@ description: 介绍 GreptimeDB 的特点、设计原则和优势,包括统一

# 为什么选择 GreptimeDB

GreptimeDB 是一个云原生、分布式和开源的时序数据库,旨在处理、存储和分析大量的指标、日志和事件数据(计划中还包括 Trace)。
它在处理涉及时序和实时分析的混合处理工作负载方面非常高效,同时为开发者提供了极佳的体验。
GreptimeDB 是一款为云原生环境打造的开源分布式时序数据库。我们的核心开发团队在构建时序数据平台方面拥有丰富经验,GreptimeDB 在以下数个关键领域体现了他们的最佳实践:
killme2008 marked this conversation as resolved.
Show resolved Hide resolved

可以阅读博客文章《[This Time, for Real](https://greptime.com/blogs/2022-11-15-this-time-for-real)》和《[Unifying Logs and Metrics](https://greptime.com/blogs/2024-06-25-logs-and-metrics)》了解我们开发 GreptimeDB 的动机。
在这些文章中,我们深入探讨了 Greptime 高性能背后的原因以及一些突出的功能。
## 基于对象存储的成本优势

## 统一的指标、日志和事件
GreptimeDB 采用云对象存储(如 AWS S3、阿里云 OSS 和 Azure Blob Storage 等)作为存储层,与传统存储方案相比显著降低了成本。通过优化的列式存储和先进的压缩算法,实现了高达 50 倍的成本效率,而按需付费模式的 [GreptimeCloud](https://greptime.com/product/cloud) 确保您只需为实际使用的资源付费。

通过[时序表](./data-model.md)的模型设计、对 SQL 的原生支持以及存算分离架构带来的混合工作负载,
GreptimeDB 可以同时处理指标、日志和事件,
增强不同时间序列数据之间的关联分析,
并简化架构、部署成本和 API。
## 高性能

阅读 [SQL 示例](/user-guide/overview.md#sql-query-example) 了解详细信息
在性能优化方面,GreptimeDB 运用了多种技术,如 LSM Tree、数据分片和基于 Kafka 的 WAL 设计,以处理大规模时序数据的写入

## 可用性、可扩展性和弹性
GreptimeDB 采用纯 Rust 编写,确保卓越的性能、安全和可靠性。其强大快速的查询引擎基于向量化执行和分布式并行处理(得益于 [Apache DataFusion](https://datafusion.apache.org/)),并结合了[多种索引能力](/user-guide/manage-data/data-index),如倒排索引、跳数索引和全文索引等。GreptimeDB 将智能索引和大规模并行处理(MPP)相结合,以提升数据剪枝和过滤效率。详情请参阅[性能测试报告](https://greptime.cn/blogs/2024-09-09-report-summary)。

从第一天起,GreptimeDB 就按照云原生数据库的原则设计,这意味着它能够充分利用云的优势。其一些好处包括:
## 基于 Kubernetes 的弹性扩展

1. 高可用的按需计算资源,目标是实现 99.999% 的可用性和正常运行时间,即每年大约只有五分钟十五秒的停机时间。
2. 弹性和可扩展性,允许开发者根据使用情况轻松扩展或缩减、添加或移动资源。
3. 高可靠性和容错性以防止数据丢失。系统的目标是实现 99.9999% 的可用性率。
GreptimeDB 从底层就是为 Kubernetes 设计的,基于先进的存储计算分离的架构,实现真正的弹性扩展:

这些功能共同确保 GreptimeDB 始终提供最佳的性能。
下面是关于如何实现这些功能的额外技术解释。
- 存储和计算资源可独立扩展
- 通过 Kubernetes 实现无限水平扩展
- 不同工作负载(数据写入、查询、压缩、索引)之间的资源隔离
- 自动故障转移和高可用性

### 可弹性扩展的资源隔离
![存储计算分离,计算资源隔离](/storage-compute-disaggregation-compute-compute-separation.png)。

![存储/计算分离,计算/计算分离](/storage-compute-disaggregation-compute-compute-separation.png)
## 统一处理所有时序数据

存储和计算资源是分离的,允许每个资源独立扩展、消耗和定价。
这不仅大大提高了计算资源的利用率,还适配了“按需付费”的定价模式,避免了资源未充分利用的浪费。
GreptimeDB 通过以下方式统一处理指标、日志和事件数据:

除了存储和计算隔离,不同的计算资源也被隔离,避免了因数据写入、实时查询以及数据压缩或降采样等任务产生的资源竞争,
从而实现高效率的大规模实时分析。
- 统一的[数据模型](./data-model.md),将所有时序数据视为带有上下文的时间戳事件
- 原生支持 [SQL](/user-guide/query-data/sql.md) 和 [PromQL](/user-guide/query-data/promql.md) 查询
- 内置流处理能力([Flow](/user-guide/flow-computation/overview.md))用于实时聚合和分析
- 无缝关联分析不同类型的时序数据,详见[SQL 示例](/user-guide/overview.md#sql-query-example)

数据可以在多个应用程序之间共享而无需争用同一资源池,
这不仅大大提高了效率,
还可以根据需求提供无限的可扩展性。

### 灵活的架构支持多种部署策略
## 灵活架构:从边缘到云端

![GreptimeDB 的架构](/architecture-2.png)

通过灵活的架构设计原则,不同的模块和组件可以通过模块化和分层设计独立切换、组合或分离。
例如,我们可以将 Frontend、Datanode 和 Metasrc 模块合并为一个独立的二进制文件,也可以为每个表独立启用或禁用 WAL。

灵活的架构允许 GreptimeDB 满足从边缘到云的各种场景中的部署和使用需求,同时仍然使用同一套 API 和控制面板。
通过良好抽象的分层和封装隔离,GreptimeDB 的部署形式支持从嵌入式、独立、传统集群到云原生的各种环境。

## 优异的成本效益

GreptimeDB 利用流行的对象存储解决方案来存储大量的时序数据,例如 AWS S3 和 Azure Blob Storage,允许开发者只为使用的存储资源付费。

GreptimeDB 使用自适应压缩算法,根据数据的类型和基数来减少数据量,以满足时间和空间复杂性约束。
例如,对于字符串数据类型,当块的基数超过某个阈值时,GreptimeDB 使用字典压缩;
对于浮点数,GreptimeDB 采用 Chimp 算法,该算法通过分析实际的时间序列数据集来增强 Gorilla(Facebook 的内存 TSDB)的算法,
并提供比传统算法(如 zstd、Snappy 等)更高的压缩率和空间效率。
灵活的架构允许 GreptimeDB 满足从边缘到云的各种场景中的部署和使用需求,同时仍然使用同一套 API 和控制面板。了解更多请参见[边云一体化解决方案](https://greptime.cn/carcloud)。

## 高性能

在性能优化方面,GreptimeDB 利用 LSM 树、数据分片和基于 Quorum 的 WAL 设计等不同技术来处理大量的时序数据写入时的工作负载。

GreptimeDB 的查询引擎强大且快速,得益于矢量化执行和分布式并行处理,并结合了索引功能。
为了提升数据修剪和过滤效率,GreptimeDB 构建了智能索引和大规模并行处理(MPP)架构。
该架构使用独立的索引文件记录统计信息,类似于 Apache Parquet 的行组元数据,同时还使用了内置指标记录不同查询的工作负载。
通过结合基于成本的优化(CBO)和开发者定义的提示,GreptimeDB 能够启发式地构建智能索引,从而进一步提升查询性能。
通过良好抽象的分层和封装隔离,GreptimeDB 的部署形式支持从嵌入式、独立、传统集群到云原生的各种环境。

## 易于使用
## 易于迁移和使用

### 易于部署和维护

为了简化部署和维护过程,GreptimeDB 提供了 [K8s operator](https://github.com/GreptimeTeam/greptimedb-operator)、[命令行工具](https://github.com/GreptimeTeam/gtctl)、嵌入式[仪表盘](https://github.com/GreptimeTeam/dashboard)和其他有用的工具,
使得开发者可以轻松配置和管理数据库。
请访问我们官网的 [GreptimeCloud](https://greptime.com) 了解更多信息。
请访问我们官网的 [Greptime](https://greptime.cn) 了解更多信息。

### 易于集成

GreptimeDB 支持多种数据库连接协议,包括 MySQL、PostgreSQL、InfluxDB、OpenTSDB、Prometheus Remote Storage 和高性能 gRPC。
此外,还提供了多种编程语言的 SDK,如 Java、Go、Erlang 等。
我们还在不断与生态系统中的其他开源软件进行集成和连接,以增强开发者体验。
接下来将详细介绍三种流行的语言:PromQL、SQL 和 Python。
GreptimeDB 支持多种数据摄入协议:
killme2008 marked this conversation as resolved.
Show resolved Hide resolved
- **数据库协议**:MySQL、PostgreSQL
- **时序数据协议**:InfluxDB、OpenTSDB、Prometheus RemoteStorage
- **可观测数据协议**:OpenTelemetry、Loki、ElasticSearch
- **高性能 gRPC 协议及客户端 SDK**(Java、Go、Erlang 等)

PromQL 是一种流行的查询语言,
允许开发者选择和聚合由 Prometheus 提供的实时时序数据。
它比 SQL 更简单,适用于使用 Grafana 进行可视化和创建告警规则。
GreptimeDB 原生支持 PromQL,查询引擎会将其转换为查询计划,对其进行优化和执行。
在数据查询方面,GreptimeDB 提供:
- **SQL**:用于实时查询、复杂分析和数据库管理
- **PromQL**:原生支持实时指标查询和 Grafana 集成
- **Python**:(计划中)支持数据科学场景的数据库内 UDF 和 DataFrame 操作

SQL 是一种高效的工具,
用于分析跨越较长时间跨度或涉及多个表(如 join)的数据。
此外,它在数据库管理方面也非常方便。
这种统一的方法实现了与现有可观测性技术栈的无缝集成,用户可以方便地迁移,并同时保持高性能和灵活性。

Python 在数据科学家和 AI 专家中非常流行。
GreptimeDB 允许直接在数据库中运行 Python 脚本。
开发者可以编写 UDF 和 DataFrame API,通过嵌入 Python 解释器来加速数据处理。
![Greptime Ecosystem](/greptime-ecosystem.png)

### 简单的数据模型与自动创建表

结合指标(Tag/Field/Timestamp)模型和关系数据模型(Table),
GreptimeDB 提供了一种称为时序表的新数据模型(见下图),以表格形式呈现数据,由行和列组成,指标的 Tag 和 Value 映射到列,并强制时间索引约束表示时间戳。
GreptimeDB 提供了一种称为时序表的新数据模型(见下图),以表格形式呈现数据,由行和列组成,指标、日志和事件的 Tag 和 Value 映射到列,并强制时间索引约束表示时间戳。

![时序表](/time-series-table.png)

然而,我们对 schema 的定义不是强制性的,而是更倾向于 MongoDB 等数据库的无 schema 方法。
表将在数据写入时动态自动创建,并自动添加新出现的列(Tag 和 Field)。


要了解更多关于我们的方法和架构,请查看我们的博客文章:[《专为实时而生》](https://greptime.cn/blogs/2022-11-16-github)、[《GreptimeDB 统一存储架构》](https://greptime.cn/blogs/2024-12-24-observability)和[《事件管理革命:监控系统中统一日志和指标》](https://greptime.cn/blogs/2024-06-14-events)。
killme2008 marked this conversation as resolved.
Show resolved Hide resolved
Binary file added static/greptime-ecosystem.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Loading