需求类别 | 需求内容 | 需求场景 | 优先级 | 社区情况反馈 | 跟踪责任人 |
资源池化 | 资源池化方案支持 | 需要资源池化的方案说明材料支撑 | 高 | 资源池化的使用材料可见社区官网；技术讲解材料可会后提供 | 陈栋 |
资源池化: 1. 稳定性（研发故障计划ing) 2. 文档 3. GaussDB似乎不同方案，对一下开源4. 用户遇到稳定性问题 (6.0上特性更稳定） | 高 | 6.0.0资源池化商用版本发布，涵盖189种故障模式库，97%手动可恢复，80%可自动恢复，RAC多写方案在下次UC明确技术路径： | 熊小军 | ||
高可用 | 对于CM软件在高可用方面进一步提升，在各种异常场景下都能恢复，比如5个节点内，本中心已经丢失2节点，结合同步策略，建议从同城中心选主。 | 多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当两个DN故障时，仍能优先从本AZ中选取主 | 高 | 当前支持AZ级优先级选主，需设置选主优先级 | 熊小军 |
CM丢失3节点后，如何快速从剩余2节点中找到主节点，提高用户的灾备响应能力。 | 多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当三个DN全部故障时，如何容灾切换到其他的AZ选取 | 高 | 如果是5节点，挂了3个，剩下2个不满足多数派，无法自动选主，需手动强起； | 熊小军 | |
双活方案支持 | 大概率是双集群容灾方案支持 | 低 | 社区支持通过发布订阅的方式实现异地双活；也支持双集群实现异地容灾 | - | |
优化CM，能够支持单独切换、启停功能 | 高可用场景下DN级别的灵活维护能力 | 低 | 当前支持CM暂停集群管理功能，也支持对单个DN的启停切换 | - | |
两地三中心，支持双写场景（目前社区说两地写有问题，数据一致性需要根据实际处理） | 采用两地部署，两地写（逻辑复制）时能够保证数据一致性 | 低 | 当前通过发布订阅实现异地双活，提供用户自定义的冲突解决机制：当订阅端同步数据时遇到主键或唯一键冲突时，数据库通过参数配置进行报错、保留本地或者应用远端。 | - | |
版本升级 | 针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 | 跨大版本升级的易用性、平顺性 | 高 | 社区支持跨大版本升级，如3.0.0->6.0.0，当前社区文档版本升级路径显示不支持从3.0->6.0的升级，需要刷新 | 熊小军 |
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 | 数据库完全不停机情况下的小补丁升级 | 高 | 社区今年规划了热补丁升级能力 | 朱芳芳 | |
针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 | 跨大版本升级的易用性、平顺性 | 低 | 社区支持跨大版本升级，如3.0.0->6.0.0 | - | |
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 | 数据库完全不停机情况下的小补丁升级 | 低 | 社区今年规划了热补丁升级能力 | - | |
向量数据库 | 有向量化引擎要求，目前引入了Rust编写的面向向量的搜索引擎Qdrant，openGauss需要在7.0版本下DataVec能使用 | 大概率是openGauss的datavec对客户当前已使用的Qdrant相关功能的兼容或替换 | 高 | 当前社区7.0DataVec版本具备Qdrant完整对标/替换能力，后续单独与国能对接。 | 阙鸣健 |
内核 | 高并发（10k甚至2-3k）：物理机资源高（cpu等），抖动。业务使用随便. | 高 | 大概率是issue，结合移动现网后续跟进解决 | 李居隆 | |
行存压缩 | 民生、广州汇智 | 高 | 25年明确商用交付，当前方案开发完成，协同海量版本测试中，同时与民生对接后续落地计划 | 李标 | |
WAL回放性能 | 高 | 25年已规划 | 阙鸣健 | ||
日志和数据库状态都只能omm用户看，我们想普通用户也能查? 不能hardcode omm | 高 | 熊小军 | |||
兼容性 | 增加informix的兼容性 | 客户从informix迁移到openGauss，希望有更好的兼容性 | 低 | Informix迁移社区暂无规划，目前可通过恩墨的mtk工具完成迁移 | - |
信创改造要求，需逐步替换国外开源数据库MySQL和PGSQL，有Oracle迁移需求，暂无实际的项目计划； | 通用性国外数据库兼容性场景 | 低 | 对MySQL已支持常用语法100%兼容；Oracle通过使能伙伴完成全量语法50%兼容，今年会进一步增加兼容度；PG语法的兼容性今年暂无规划，后续通过DBV、高校合作项目补齐。 | - | |
针对其他数据库迁移到oG，比如PG，提供语法兼容和迁移方面的规划和工具。 | 从pg迁移到og的兼容性、迁移工具的支持 | 低 | PG的迁移工具已在实现中，预计630交付 | - | |
工具 | 异构数据库迁移工具，目前能支持MySQL数据迁移和PGSQL迁移，其他商用数据库支持，比如达梦，Oracle等； | 在企业进行数据库系统迁移或整合时，支持将数据从原有的业务数据库如MySQL、PostgreSQL、达梦或Oracle迁移至openGauss，以确保业务的连续性和数据的完整性。 | 低 | 社区已支持mysql迁移，已规划对pg的迁移；对oracle的迁移已在24年年初由南大贡献；对其他国产数据库如达梦的迁移，建议DBV伙伴来实现 | - |
数据库监控平台工具，目前主从监控待引入datakit工具，短信和邮箱报警正在开发，需要监控看板页面，支持运行中的sql语句级别的审计功能。 | datakit工具能力 | 低 | 当前datakit不支持审计，后续规划实现 | - | |
短信或邮件报警 ，看板监控（社区datakit这些功能已实现，待今年落地国能） | 社区datakit工具在国能短信、邮件报警，看板监控场景使用 | 低 | Datakit已支持短信和邮件通知，已提供配置服务的入口 | - | |
openGauss GCC编译工具需适配操作系统自带的GCC和依赖工具，不再独立一套编译工具 | 企业服务器和操作系统种类多，希望减少所需适配内容 | 低 | 不同OS的gcc版本可能不一致，待分析是否完全采用OS的 | - | |
希望社区在AI for DB的领域，对DBmind进一步开源和推广，促进数据库更加智能化。 | DBmind重点发展和推广 | 低 | 需要高斯回答 | - | |
适配 | 基于信创桌面系统的数据库和客户端链接工具，需要兼容UOS； | 操作系统适配 | 低 | 当前社区无规划适配UOS桌面系统 | - |
版本升级 | 针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 | 跨大版本升级的易用性、平顺性 | 低 | 社区支持跨大版本升级，如3.0.0->6.0.0 | - |
对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 | 数据库完全不停机情况下的小补丁升级 | 低 | 社区今年规划了热补丁升级能力 | - | |
驱动 | 1. 支持基于C# ADO.NET框架的数据库驱动程序实现 | 需要支持.Net开发语言开发项目 | 低 | 社区支持.NET，后续需要催熟、官网正式发布 | - |
2. 支持基于EntityFramework Core ORM框架的数据库提供程序实现 | 低 | - | |||
PHP语言下实现连接池代理，在单个连接查询下延迟大； | PHP语言下的连接池代理 | 低 | 是需要PHP驱动支持连接池代理？目前可采用PgBouncer | - | |
分布式 | 需要构建分布式事务能力 | 能够支持分布式节点 | 低 | 目前社区暂无分布式数据库规划，可采用南大通用的分布式方案 | - |
其他 | 社区上数据库内核及周边工具较多，掌握不容易，有条件的话可以赋能 | 国产数据库资料相对较少，上手门槛高 | 低 | 资料优化；内核和工具直播赋能 | - |
优化官方手册中描述（有些GaussDB描述或特性，在openGauss中并没有，但是文档和实际环境中还是存在） | 修正openGauss中不支持的特性，避免误导用户 | 低 | 资料优化 | - | |
文档结构还需要进一步清晰，建议尽量合并成一个整体的文档（大的方面可以分为运维和开发类），通过合适的导航和搜索以及链接方式，精确定位到用户关心的问题。当前文档多而散的模式，使用上反倒不方便。 | 文档结构、导航希望更加合理 | 低 | 资料优化 | - | |
进一步提高官方文档的质量，文档内容较多，部分信息冗余，部分文档解释模糊，甚至解释不准确，用户无法完全理解，上生产操作前需要反复验证。 | 文档内容质量提升，包括信息冗余、解释模糊、解释不准确、用户可读性差的问题。上生产操作前需要反复验证。 | 低 | 资料优化，同时建议用户遇到问题可先直接提issue反馈 | - | |
监控：社区再完善一点. | 低 | 视图/监控部分规划：轻量级锁跟踪、全链路跟踪、视图可视化等25年陆续交付。 | - | ||
AI4DB: 移动已经在用，还挺不错（From DBA）, 训练问题：数据安全 | 低 | DBMind使用情况和问题后续单独组织会议对齐-沈金伟 | - | ||
分区表：索引问题？不确定具体问题，线下讨论。 | 低 | 分区表性能优化（3000+分区场景，TPCC性能损耗小于30%） | - |
participants (1)
-
opengauss