开源 Rust 时序数据库 GreptimeDB 发布 v0.1,原生支持 Python, PromQL 和对象存储
GreptimeDB 是 Rust 实现的开源时序数据库,尤其关注可扩展性、分析能力和效率,专为云时代的基础设施而设计。
功能
- 提供可扩展到高可用分布式集群的独立二进制文件
- 优化处理时序数据的柱状布局
- 提供灵活的索引选项
- 利用弹性计算资源的分布式并行查询
- 提供用于高级分析场景的原生 SQL 和 Python 脚本
- 使用广泛采用的数据库协议和 API
- 适用于大量工作负载的可扩展表引擎架构
架构
GreptimeDB 核心组件:
Frontend
前端用于在各种协议中提供读写服务,将请求转发到Datanode
Datanode
负责将数据存储到本地磁盘、S3 等持久化存储中Meta
server 后端负责协调Frontend
和Datanode
之间的操作
近日,GreptimeDB 发布了 0.1 版本,并在公告写道,自去年 11 月开源以来,已经近 4 个月,团队将之前设定的里程碑拆分成了 v0.1, v0.2 和 v0.3 三个小阶段,最终希望可以在 v0.3 交付一个单机可靠,分布式可用的产品。
以下内容摘录自 https://mp.weixin.qq.com/s/U0LdbvilVFpLBUK-zbRgrw。
GreptimeDB v0.1
Features
- Compaction
是的,作为一个 LSM Tree 架构怎能没有 Compaction,GreptimeDB 终于支持 Compaction 了。通过 Compaction 也支持了数据的基于 TTL 的淘汰。
- 支持对象存储
通过 OpenDAL, GreptimeDB 较容易地实现了对 S3 和 OSS 对象存储的支持。
- 支持使用 Python
引入 Python 脚本功能与 DataFrame API 以及第三方 Python 库的支持,可作为协处理器和用户自定义函数 (UDF) 使用。
- 原生支持 PromQL
PromQL 在云原生可观测领域已是公认使用最广泛的查询语言了。因此,尽管挑战很大,我们决定在 GreptimeDB 中原生支持 PromQL。目前我们已经初步实现了 PromQL 原生支持,尽管还不能通过官方兼容性测试中的所有 cases,但随着 GreptimeDB 0.1 版本发布,其已经初步可用。对于这个兼容性测试,我们计划在 GreptimeDB v0.2 版本中通过一半以上的 test cases,在 v0.3 版本中通过 70% 以上。
Protocol
- 新版高性能通信协议
基于 Arrow Flight RPC 构建,相比原来的 gRPC 私有协议,现在更加简洁高效,也很方便多种语言利用 Arrow Flight 的 SDK 直接与 GreptimeDB 通信。对 Stream 的支持也更方便。
文档见:https://docs.greptime.com/developer-guide/how-to/how-to-write-sdk
- MySQL & PostgreSQL 支持 TLS
为了数据的传输安全,MySQL 和 PostgreSQL 支持 TLS 是十分有必要的。另外与 HTTP 或 gRPC 不同,数据库协议有自己的 TLS 握手过程,因此我们在数据库这一层来支持了 TLS。
Clients
- 基于Arrow Flight RPC通信的Java SDK[1]
- 基于 Arrow Flight RPCGo SDK[2]正在开发
Refactor
- Datafusion &Arrow重构
GreptimeDB 最初重度使用了 Arrow2,但是 DataFusion 的 Arrow2 分支已不再维护,所以我们决定切换到 Arrow,这样我们就可以跟上最新的 DataFusion 版本了,这是一个具有巨大挑战的任务,很高兴我们顺利完成了。
除了以上列出的内容外,我们还有大大小小的 PRs 491 个,包括了各种功能准备,重构,bug 修复和文档完善等。另外,我们也将自己的一些经验回馈到开源社区,包括向 DataFusion[3],sqlness[4], Parquet2[5], Datafusion-Substrait[6], RustPython[7],OpenDAL[8] 等外部项目提交了贡献代码。
未来的计划
GreptimeDB
我们会按计划在 5 月份 release v0.3,目标是可达到单机可靠,分布式可用的程度。其中 “可靠” 主要体现在性能和稳定性上,但既然是单机,无论性能还是稳定性都是有一定上限,所以我们也会逐步完善分布式的版本。对于单机已经能满足要求的用户来讲,GreptimeDB v0.3 将会给到建议可用的单机版本。
而如果对可靠性和扩展性要求比较高的用户,我们也将在今年下半年完善分布式功能,计划年末提供分布式 GA ( General Availability ) 版本。
功能方面,我们还是会专注在数据的采集、存储和分析的生命周期,落地在用户实际场景问题,重点会在查询性能、存储降本和分布式方面,包括:
- PromQL 查询性能优化
- Python scripts 支持 MapReduce 框架,更高效地处理分布式计算
- 查询引擎的优化,向量化查询、智能索引和 Cost-Based Optimizer 等
- 存储和计算分离,存与算均可做到自动化伸缩
- 采用自适应压缩算法,一份数据支撑时序模型与分析模型的混合负载,降低存储成本

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于 Flink 流计算实现的股票交易实时资产应用
一、背景 本次赛题思路源自于真实工作场景的一个线上项目,该项目在经过一系列优化后已稳定上线,在该项目开发的过程中数据平台组和技术负责人提供了许多资源和指导意见,而项目的结果也让我意识到了流计算在实际生产中优化的作用,进而加深了我对大数据应用的理解。 1.1 成员简介 陆冠兴:数据开发工程师,目前在互联网券商大数据部门工作,主要负责业务数据开发、数据平台建设、数据资产建设等相关工作,对流计算应用开发有一定经验。 1.2 内容概述 本次赛题的主要内容,是通过引入流计算引擎 Flink+消息队列 Kafka,使用 ETL 模式取代原有架构的 ELT 模式计算出用户的实时资产,解决原有架构下计算和读取压力大的问题,实现存算分离;并以计算结果进一步做为数据源构建实时资产走势等数据应用,体现了更多的数据价值。 1.3 一些概念 在股票交易系统中,用户需要先进行开户得到一个账户,该账户包含账户现金和账户持仓两部分,之后就可以通过该账户进行流水操作,同时也可进交易操作。 流水 出入金流水 = 往账户现金中存入/取出现金 出入货流水 = 往账户持仓中存入/取出股票 交易 买入股票 = 现金减少,股票持仓...
- 下一篇
GitLab 存在访问控制错误漏洞
漏洞描述 GitLab是一个基于Git的源代码管理和协作平台。 该项目受影响版本存在访问控制错误漏洞,由于权限检查不当,远程攻击者能够读取、添加或编辑其他用户的私有代码片段 漏洞名称 GitLab 存在访问控制错误漏洞 漏洞类型 访问控制不恰当 发现时间 2023-03-10 漏洞影响广度 一般 MPS编号 MPS-2022-60984 CVE编号 CVE-2022-3758 CNVD编号 - 影响范围 GitLab@[15.9, 15.9.2) GitLab@[15.8, 15.8.4) GitLab@[15.5, 15.7.8) 修复方案 升级GitLab到 15.7.8 、15.8.4 、 15.9.2 或更高版本 参考链接 https://www.oscs1024.com/hd/MPS-2022-60984 https://nvd.nist.gov/vuln/detail/CVE-2022-3758 https://github.com/gitlabhq/gitlabhq/commit/df765f1063ef7c9d50f48b9d7cfe6689dc88b1b4#diff-...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启