当我们朝着 GreptimeDB 2023 努力的时候，很自然地会问接下来 GreptimeDB 会发生什么。这个 Roadmap 有以下几个目标：

• 让人们了解接下来半年 GreptimeDB 将发生什么

• 对于有意愿为 GreptimeDB 做出贡献的朋友，帮助他们参与进来

01 生产级的分布式方案

从 GreptimeDB 启动的第一天起，我们就决定开源完整的分布式方案，使其具备高可用和高可靠能力。因为用户真正需要的是一个完整的分布式集群方案，而不是一个蹩脚的单机引擎。

计划（Release v0.1）

Features

• Quorum-based WAL (作为独立子项目进行)
• 分布式 WAL 利用数据的多副本机制来实现数据高可靠

• Analyze Query
• 查询以及查询计划的优化，执行过程可观测

• 设计 metrics, log 等可观测系统表
• 高可用（自监控）

• MySQL/PostgreSQL TLS 支持（欢迎社区参与）
• 在云环境提供服务，TLS 是有必要的

• 分布式 DDL 容错处理框架

• 集成测试套件

Refactor

• gRPC 数据传输协议重构
• 尝试基于 Arrow Flight 重构，作为 Arrow 生态的 RPC 标准（没错，GreptimeDB 使用了 Arrow），好处是减少了中间层的数据转换带来的开销，数据格式也相对紧凑，会有一些性能上的收益

02 深度优化存储和查询引擎

计划（Release v0.1）

Features

• 实现 User Defined Window 函数

• L0 到 L1 的 Compaction & TTL
• 通过 compaction 合并小文件，清理老版本的数据，提高查询效率
• 支持数据按时间淘汰
• 数据压缩

• Multi Region in Engine，表的多分区实现

• 支持对象存储，比如 S3

• 支持多级 Downsampling

Refactor

• Datafusion & Arrow 重构
• 当前使用 Arrow2  的 Datafusion 分支落后主干太多
• Datafusion 社区主流仍然是使用官方的 Arrow

• 按照时间线 (time series) 来组织数据
• 方便查询时按照时间线处理数据，更好地支持 Prometheus 等协议

Performance

• 优化 Memtable

• 分布式查询优化：pushdown UDAFs & UDFs
• 算子下推

• SST 的 filter / 索引
• 加速查询
• 优化 Python 协处理器
• 健壮性和性能

03 开放协议兼容

拥抱社区，兼容 MySQL、PostgreSQL、OpenTSDB、InfluxDB、Prometheus 等流行协议使得 GreptimeDB 更容易与现有生态数据栈集成，降低用户迁移成本。

计划（Release v0.1）

Features

• 支持 PromQL （欢迎社区参与）
• PromQL 作为云原生监控查询语言事实上的标准，有必要支持
• 支持 PreparedStatement（欢迎社区参与）
• 让大部分现存的那些相关客户端能够用起来
• Session 层（欢迎社区参与）
• 部分协议对 Session 依赖
• 多语言 SDK（欢迎社区参与）
• 计划先支持 Rust SDK & Golang SDK

  
  

如何参与

• 如果您对以上内容感兴趣，赶快加入我们在GitHub 社区的 GreptimeDB 项目（此项目上周末又登上了GitHub 周热门第一名！）。
  项目链接🔗：https://github.com/GreptimeTeam/greptimedb
• 如果您对自己的想法还有些许犹疑，也欢迎加入我们 Slack 社群（greptimedbcommunity），先跟大家讨论一波
• 看过已经在计划中的内容，您或许还有别的创意，而 GreptimeDB 也还在快速成长中，有很多提升空间，非常期待您能加入甚至成为新创意的主人。

👇🏻点击下方阅读原文，前往 GitHub 了解体验 GreptimeDB ~