Migrated repository
Go to file
2023-01-11 09:23:13 +08:00
.workflow update master-build.yml 2022-09-08 06:54:58 +00:00
config init commit based 0.6.0 2022-08-31 15:03:14 +08:00
contrib init commit based 0.6.0 2022-08-31 15:03:14 +08:00
doc modify postgres.conf and delete old initdata 2022-09-07 16:10:31 +08:00
hbr single thread backup&restore base on tikv 2023-01-11 09:23:13 +08:00
initdata modify postgres.conf and delete old initdata 2022-09-07 16:10:31 +08:00
licenses init commit based 0.6.0 2022-08-31 15:03:14 +08:00
src distinguish close and closefs api. 2023-01-11 09:19:23 +08:00
aclocal.m4 init commit based 0.6.0 2022-08-31 15:03:14 +08:00
configure init commit based 0.6.0 2022-08-31 15:03:14 +08:00
configure.ac init commit based 0.6.0 2022-08-31 15:03:14 +08:00
COPYRIGHT init commit based 0.6.0 2022-08-31 15:03:14 +08:00
GNUmakefile.in init commit based 0.6.0 2022-08-31 15:03:14 +08:00
HISTORY init commit based 0.6.0 2022-08-31 15:03:14 +08:00
INSTALL init commit based 0.6.0 2022-08-31 15:03:14 +08:00
LICENSE init commit based 0.6.0 2022-08-31 15:03:14 +08:00
Makefile init commit based 0.6.0 2022-08-31 15:03:14 +08:00
README.md add deploy doc 2022-09-05 06:24:40 +00:00

He3DB是什么?

He3DB是移动云开源的云原生数据库产品。

He3DB受Aurora论文启发基于开源数据库PostgreSQL 改造的云原生数据库产品。架构上实现计算存储分离主备节点共享一份数据容量上限100T 支持一主15备RTO 绝对时间<30秒,我们打造的核心理念:高性能,低成本。

为什么叫He3DB

He3 是氦元素同位素是一种核聚变燃料具有清洁、安全、高效等特点。和我们He3DB 追求的目标不谋而合。

产品定位:

云上一般小型业务比较看重低成本更偏向于使用RDS数据库服务。而中大型业务对性能或者可用性要求更高而不得不选择云原生数据库。当前各大云厂商的云原生数据库从产品力的角度看已经大幅领先RDS但是市场占有率RDS依然占据大头最重要的原因就是RDS成本优势。我们团队认为RDS成本和云原生数据库产品力之间存在一个权衡而正是这种权衡让我们决定研发He3DB,我们对He3DB的定位既能向下占据部分RDS市场又能向上承接部分云原生数据库业务。

He3DB不会一味的追求更大更快更强而是会设置一个产品力上限而这个上限能够满足移动云绝大多数用户使用场景在这个前提下我们会把降低成本作为He3DB持续追求的目标。

架构:

图片

He3DB架构分4层: 代理层, 计算层, 高性能存储层, 低性能持久层

中间件用户通过中间件请求数据库服务中间件支持PG协议100%兼容PG SQL。中间最核心的能力就是选择合适的备机节点保证读写数据的一致性以及备节点负载均衡未来中间件能够自动感知业务负载动态扩缩容备节点保证服务的持续稳定。

计算引擎 基于Postgresql 源码改造架构上实现了计算存储分离主备共享数据。部分模块也做了相关优化实现Aurora论文中提到的log is database以及为了RTO时间绝对可控实现wal 日志的delay replay

存储引擎:实现冷热分层:高性能存储层,以及冷数据持久层。

He3DB 目标实现思路:

高性能

目标读QPS >100W 写TPS >10W

关健技术:

  • 降低计算层往存储层写的数据量从而提升写TPS性能。主要删除计算层往数据层写数据页(只写wal日志)以及关闭wal日志为了解决部分写而要写整个数据页的机制. 初步评估相比PG 本身写数据量能下降2/3左右
  • 缩短RTO时间。 通过备机的wal delay replay技术只回放内存中存在数据页的WAL日志把回放操作由磁盘IO优化为内存IO.从而最大化的降低RTO时间
  • 实现智能化中间件保证读强一致性通过记录主备wal replay点实现最终能够通过增加备机增加读吞吐能力。
  • 数据冷热分层我们能够定义每个备节点缓存不同的热数据通过中间件保证每一个读请求选择最佳缓存备节点极端情况下我们能够保证所有的读请求全部内存命中需要修改buffer缓存算法由空间考虑优化为缓存热数据

低成本:

  • 计算引擎提供serverless服务按需扩缩量保证计算资源的效能最大化未来考虑进一步拆分CPU和内存资源能够更精准管控计算资源
  • 存储引擎:业务数据根据使用场景标识温度数,架构上实现冷热数据分层以及支持多种压缩算法。最终目标是保证性能前提下,最大化降低存储成本

高可用,高可靠:

  • 实时备份备份过程对业务零影响备份进程独立于计算节点直接操作S3对象存储
  • 高性能存储层通过Raft算法保证高可用
  • 冷数据持久层基于S3对象存储实现S3由云服务商保证数据高可用以及高可靠

扩展性:以下每一层都可以独立基于业务需求完成扩缩容

  • 计算引擎可以通过增加备机,线性增加读吞吐能力
  • 高性能存储层可以通过增加follower节点或者learner节点增加读吞吐能力
  • s3可以增加节点增加吞吐以及容量

产品现状:

  当前开源版本为0.6版本还无法用于生产这个版本主要验证计算存储分离以及共享架构的正确性性能不是我们关心的重点。0.6版本重点是计算引擎以及中间件存储部分使用的开源juicefs作为共享存储层做了部分模块的改造后续会有相关源码分享。下半年重点开发模块就是高性能存储层也就是性能将作为最重要的目标。

为什么从0.6版本开始开源,而不是等到年底所有模块开发完成,几方面原因:

  • He3DB年初立项就非常明确会完全以开源的方式运作我们希望在项目早期就能够吸引开发者进来参与开发以及功能讨论。之所以等到8月份才开源第一个版本0.6,是因为前期需要做大量的论文研读,多种可行性方案验证以及基础框架的开发。
  • 我们希望借助社区的力量,推动整个项目的发展。我们团队也会陆续推进一系列内核分析文章以及视频帮助开发者能够尽快参与到内核开发
  • 我们团队希望尽早能够以完全开源的方式推动项目向前发展包含后续需求的确认模块管理问题沟通的方式项目月报等。我们希望社区能够看到He3DB的快速发展相信我们团队的能力

部署:

He3DB 部署步骤

Roadmap

短期

  • 研发高性能存储(重点优化性能) 9-10月
  • 支持冷热分层以及数据压缩(重点降低成本) 10-11月
  • 高可靠高可用包含cluster管理主备切换网络异常处理等 10-12月      

中长期

  •    多模支持gis,时序)
  •    去O主要是SQL兼容性以及生态工具开发
  •    HTAP 能力(多主,算子下推,共享内存)

Slackhttps://join.slack.com/t/dbspecialzone/shared_invite/zt-1fe4g7uf4-iC_rdhnWpQkP0oQl_GUSKQ