GreptimeDB 于 2022 年 4 月启动，2022 年 11 月 15 日正式开源。在当下，我们的很多想法还未实现或者不够完善。
当我们朝着 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 深度优化存储和查询引擎
时序数据往往都是高基数据，而快速准确甚至智能化的查询分析能力传统数据库往往无法承载，多组件系统带来的延迟难以进一步降低。GreptimeDB 目标是融合时序和分析负载，提供 Python 协处理能力，在支撑海量数据高频读写的同时还能支撑复杂的分析计算，提升数据分析的实时性。
计划（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 周热门第一名！）。
-
如果您对自己的想法还有些许犹疑，也欢迎加入我们 Slack 社群（greptimedbcommunity），先跟大家讨论一波
-
看过已经在计划中的内容，您或许还有别的创意，而 GreptimeDB 也还在快速成长中，有很多提升空间，非常期待您能加入甚至成为新创意的主人。
怎么样，如果想要试试，就加入我们的社区和社群，大声说出您的见解吧！说不定，在这里可以找到挚友呢～～
