找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

1888

积分

0

好友

255

主题
发表于 昨天 07:12 | 查看: 6| 回复: 0

OpenTeleDB 是天翼云基于 PostgreSQL 开发的企业级数据库发行版。该项目旨在解决原生 PostgreSQL 在高并发、高可用和存储管理方面的一些痛点。项目地址如下:

https://github.com/OpenTeleDB/OpenTeleDB

OpenTeleDB 诞生于中国电信“云改数转”的战略背景下,融合了 TeleDB 在电信内部业务及天翼云客户实践中打磨出的企业级特性。它着重解决了 PostgreSQL 存在的并发连接瓶颈、存储空间膨胀以及高可用切换依赖外部组件等问题。

本次开源版本主要引入了三大核心能力:XProxy、XStore 和 XRaft,并保持了与 PostgreSQL 的完美兼容,这意味着基于 PostgreSQL 的业务系统可以无缝迁移至 OpenTeleDB。

  • XProxy:提供高达十万级别的原生连接接入能力,支持自动读写分离与负载均衡,实现了系统的横向扩展,从而提升整体性能与可用性,让资源利用更充分。
  • XStore:原生 PostgreSQL 在高并发更新场景下,由于 MVCC(多版本并发控制)机制容易导致存储空间持续膨胀,并且周期性的 Vacuum 回收操作会引起显著的性能波动(例如在执行 TPCC 模型测试时性能波动常超过 40%)。OpenTeleDB 通过 XStore 存储引擎对存储层进行了全链路重构:采用原位更新Undo日志管理,从根本上杜绝了空间膨胀,表空间占用几乎零增长;同时对索引也采用原位更新,彻底告别了需要全表扫描的 Vacuum 操作,将执行 TPCC 模型时的性能波动压制在 5% 以内。
  • XRaft:在数据库内核层面实现了自动高可用,避免了脑裂问题,且不依赖任何第三方外部组件,架构简洁,有效保障了业务连续性。

为了快速体验 OpenTeleDB 中的 XStore 存储引擎,我制作了对应的 Docker 镜像,方便开发者一键部署和测试。

制作与获取镜像

镜像制作过程在此略过,您可以直接使用以下命令拉取已构建好的镜像。

ARM64 架构镜像:

docker pull registry.cn-hangzhou.aliyuncs.com/digoal/opensource_database:openteledb-17-arm64

x86_64 架构镜像:

docker pull registry.cn-hangzhou.aliyuncs.com/digoal/opensource_database:openteledb-17-amd64

如何使用镜像

可以通过以下命令快速启动一个 OpenTeleDB 容器实例进行体验:

mkdir -p ~/openteledb_docker_data1

cd ~/openteledb_docker_data1
PG_DATA=`pwd`
PG_USER="postgres"
PG_PASSWORD="123456"

docker run -d -it -p 0.0.0.0:5433:5432 --add-host=host.docker.internal:host-gateway \
  -u root -w /var/lib/postgresql -e LANG=en_US.utf8 \
  -e POSTGRES_INITDB_ARGS="-E UTF8 --locale=C --lc-ctype=en_US.utf8" \
  -v $PG_DATA:/var/lib/postgresql/data \
  -e PGDATA=/var/lib/postgresql/data \
  --cap-add=SYS_PTRACE --cap-add SYS_ADMIN --privileged=true --shm-size=1g \
  -e POSTGRES_USER=$PG_USER -e POSTGRES_PASSWORD=$PG_PASSWORD \
  --name openteledb-test1 \
  registry.cn-hangzhou.aliyuncs.com/digoal/opensource_database:openteledb-17-arm64

XStore 与 HEAP 引擎性能对比测试

启动容器后,我们可以进入容器进行 XStore 存储引擎的性能测试,并将其与原生 PostgreSQL 的 HEAP 存储引擎进行对比。

首先,优化一下数据库配置参数以更好地发挥性能:

psql

\! echo "shared_buffers = 2GB
maintenance_work_mem = 1GB
autovacuum_work_mem = -1
synchronous_commit = off
wal_writer_delay = 10ms
max_wal_size = 6GB
min_wal_size = 1GB
autovacuum = on
autovacuum_max_workers = 3
autovacuum_vacuum_cost_delay = 2ms
autovacuum_vacuum_cost_limit = -1" >> /var/lib/postgresql/data/postgresql.auto.conf

修改配置后,重启容器使配置生效,然后继续进行测试。

1. 创建测试表并插入数据

接下来,我们分别创建使用 XStore 引擎和 HEAP 引擎的表,并插入相同的数据量。

-- 创建并测试 XStore 表
create extension if not exists xstore;
drop table if exists tbl_xstore;
create table tbl_xstore (id serial primary key, info text, ts timestamp) using xstore;
insert into tbl_xstore (info, ts) select md5(random()::text), clock_timestamp() from generate_series(1,5000000);
select pg_size_pretty(pg_total_relation_size('tbl_xstore'));

-- 结果示例
 pg_size_pretty
----------------
 570 MB
-- 备注:当前版本下 XStore 表的大小主要受 xbtree 索引影响,其尺寸相对较大。

-- 创建并测试 HEAP 表
drop table if exists tbl_heap;
create table tbl_heap (id serial primary key, info text, ts timestamp) using heap;
insert into tbl_heap (info, ts) select md5(random()::text), clock_timestamp() from generate_series(1,5000000);
select pg_size_pretty(pg_total_relation_size('tbl_heap'));

-- 结果示例
 pg_size_pretty
----------------
 472 MB

2. 执行更新压测

我们使用 pgbench 工具对两张表进行持续的随机更新操作,以对比其更新性能(TPS)和存储膨胀情况。

  • XStore 表更新压测脚本与命令:
\! echo "\set id random(1,5000000)
update tbl_xstore set info=md5(random()::text), ts=clock_timestamp() where id=:id;" > ~/xstore.sql

\! pgbench -M prepared -n -r -P 1 -f ~/xstore.sql -c 8 -j 8 -T 300
  • HEAP 表更新压测脚本与命令:
checkpoint; -- 先做一次检查点,确保测试环境一致

\! echo "\set id random(1,5000000)
update tbl_heap set info=md5(random()::text), ts=clock_timestamp() where id=:id;" > ~/heap.sql

\! pgbench -M prepared -n -r -P 1 -f ~/heap.sql -c 8 -j 8 -T 300

3. 测试结果对比

在完成一段时间的压测后,我们对比两者的更新效率和存储膨胀率:

引擎 更新 TPS 存储膨胀率
xstore 107831 0% (初始570MB,压测后大小无变化)
heap 104360 6.1% (初始472MB,膨胀至501MB)

从结果可以看出,在本次测试中,XStore 引擎不仅提供了与 HEAP 引擎相近的更新吞吐量(TPS),更关键的是完全避免了存储空间的膨胀。而 HEAP 表则出现了约 6.1% 的空间增长,这证实了 XStore 的“原位更新”和 Undo 日志机制在解决 PostgreSQL 空间膨胀问题上的有效性。

4. 性能波动对比

除了绝对性能,更新的平稳性(抖动情况)也是衡量存储引擎的重要指标。从下面的性能监控图可以直观看到,XStore 的更新 TPS 曲线比 HEAP 更加平稳。由于 HEAP 表在测试初期已经开始膨胀,如果持续延长测试时间,相信 XStore 在长期稳定性方面的优势会更加明显。

XStore 与 HEAP 引擎更新 TPS 对比折线图

对于追求极致稳定性和可控存储成本的应用场景,例如高并发在线事务处理系统,XStore 引擎的特性颇具吸引力。

深入测试:长时间压力下的异常

为了进一步测试稳定性,后续又运行了长达 3000 秒的持续更新负载。HEAP 表在膨胀到约 507MB 后趋于稳定,而 XStore 表在长时间压力下出现了崩溃,数据库日志中记录了如下错误信息:

INFO:  undo record discontinuous,logno 131073, buffer 77453, startingByte 601, page start 24, page end 8192, alreadyWritten 0, lastPageWritten 0, diffpage true, urp 9223442407746503257, newpage true.

初步分析可能与 Undo 日志管理相关。检查了相关参数,配置值已经设置得相当大,理论上不应成为瓶颈,因此这很可能是一个需要关注的潜在 Bug。

postgres=# show xstore.undo_max_size_per_transaction;
 xstore.undo_max_size_per_transaction
--------------------------------------
 32GB
(1 row)

postgres=# show xstore.undo_max_total_size;
 xstore.undo_max_total_size
----------------------------
 256GB
(1 row)

总的来说,天翼云开源的 OpenTeleDB 及其 XStore 引擎为 PostgreSQL 生态带来了新的思路和解决方案,特别是在解决存储膨胀这一经典难题上表现突出。本次通过 Docker 镜像的快速部署和初步性能测试,验证了其核心价值。对于数据库技术爱好者或正在评估新型数据库存储方案的开发者而言,这无疑是一个值得深入研究和测试的开源项目




上一篇:Python量化交易教程:基于TradingGym的强化学习交易环境搭建与回测实践
下一篇:阿里云域名注册与DNS解析全流程指南:新手避坑教程
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-1-11 14:17 , Processed in 0.201407 second(s), 40 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2025 云栈社区.

快速回复 返回顶部 返回列表