第六十九期另一种累

Oracle 23c的相关内容先缓缓，有些数据库管理相关的还是得正式版发布后才好去做实验。这周相较于之前那种割接较多的累还有点不一样，这周陪着客户交流了大把国产数据库厂商，每次1-2个小时，需要全神贯注，协助客户提问。

1 国产数据库沟通

为啥要沟通的背景就不说了，这周以线上和线下方式沟通了人KingBase、AntDB、GoldenDB、DM、MogDB、Gbase，算上有意向还未沟通的还有GreatDB、OceanBase，和以前沟通过的TiDB、PolarDB、TDSQL等。
其中分布式占了大多数（即使现在没有也在做）。
本周沟通的除了达梦是自研的以外基本都是基于MySQL、PostgreSQL（含OpenGauss）或Informix二次开发（通俗点叫包装or套壳）的，通过单个数据库架构基本都只能实现OLTP，如果要组合OLAP或实现HTAP大多需要叠加更加复杂的架构。
下面对部分国产数据库的基本信息做个汇总：

数据库名称	厂商	数据库内核	部署模式	数据库模态
KingBase	人大金仓	基于PostgreSQL	集中式	OLTP
AntDB	亚信	基于PostgreSQL	集中式、分布式	OLTP
GoldenDB	中兴	基于MySQL	分布式	OLTP
DM	达梦	自研	集中式、分布式	OLTP
MogDB	云和恩墨	基于OpenGauss	集中式	OLTP
GBase	南大通用	基于MySQL、PostgreSQL、Informix	集中式、分布式	OLTP
TiDB	PingCap	自研	分布式	HTAP
OceanBase	蚂蚁金服	自研	分布式	HTAP
PolarDB	阿里巴巴	基于MySQL/PostgreSQL	分布式	OLTP
TDSQL	腾讯	基于MySQL	分布式	OLTP
GreatDB	万里开源	基于MySQL	分布式	HTAP

上面本周沟通的信息还算比较准确。有些以前沟通或还未直接沟通的信息可能不大准，欢迎大家指正。还有就是这个表不代表排名！！！

2 问题

在沟通过程中，其实还是暴露出不少问题：

云底层
其实这周沟通的基本上都能实现独立部署，但是之前沟通过的某些数据库是必须依赖配套的云底层（说白了就是用附加条款的方式绑死），但是众所周知，我客户这是不让的。
分布式
绝大多数使用分布式架构的国产数据库厂商基本上都在有意无意的避开分布式改造这件事情，其中需要涉及的代码改造、业务逻辑改造、数据逻辑改造要么不提要么就一笔带过，其实集中式换分布式需要避的坑，我在第三十六期写过，有兴趣的可以去看看（可能往后还会重新总结一次）。
售前
虽然说绝大多数国产数据库厂商的售前还是不错，也会有研发之类的技术做补充。但是不得不说，某些数据库厂商的售前真是垃圾（根据就是销售转的完全没技术背景），除了照本宣科以外基本就是一问三不知或者open yellow gun。
PPT
之前在DBA群里有人问过，国产数据库排名，我回了一句是按照PPT排还是实际使用，嘿嘿。不得不说大多数厂商的PPT做的还是很不错的，但是“吹”的成分还是偏高，比如：某些功能仅PPT实现、某些项目PPT中已达成、吾乃国产之光（其余都是垃圾）、性能突破天际、我们没有问题等等。
混乱
这里的混乱主要是某些数据库的技术架构混乱、产品构成混乱、发展方向混乱和沟通混乱。
马内
在很多国产数据库眼中，似乎客户都是不差钱的主，单从替换的硬件需求层面，很多就不考虑客户实际情况（往多往好的整），更不会考虑客户是不是要在业务改造上花钱。看起来license便宜（还有买断制的）其实可能花更多的钱。

3 我的建议

根据客户要求我也做了一个国产数据库选型的很粗的建议：

实现尽可能平滑、安全的迁移
– 双平面数据库支持能力，支持业务回切
– 减少代码改动量，需要全面支持语法、存储过程与触发器
– 减少数据库逻辑层面改造（暂时不选择分布式，选分布式的话还是建议重构）
数据库能力
– 全面的硬件、操作系统、数据库管理监控工具，实现集中化管理、调优、告警、自愈等功能
– 需要具备横纵向扩展能力，支持未来业务发展
– 性能测试满足各业务系统要求，业务响应不能慢于当前环境
–异地灾备能力，满足支持读写分离的可切换灾备架构或双活架构，RTO、RPO满足条件
– 多租户能力，支持数据库硬件资源隔离
– 一定程度的HTAP能力
其他
– 硬件的全面支持，需要支持国产CPU及其他硬件
– 国产操作系统全面支持，欧拉、龙蜥
– 原有硬件的少量改造，包含10GE以上网络（25GE、40GE等）、SSD（NVMe、SAS等）等，控制成本

当然还要根据实际的业务类型、业务压力、数据量综合讨论。这个肯定没有某些数据库服务大厂写的完善，写的好，但是是我这里真真切切的一线需求。