国产数据库需要扩大场景覆盖面才能在竞争中更有优势

白鳝的洞穴 2025-04-14

456

最近在分布式数据库领域的两个大佬OceanBase和TiDB纷纷推出了单机版。在周六的TiDB南京站的活动中，副总裁刘松介绍了TiDB单机版的一些预览特性。这两家最早的国产分布式数据库厂商纷纷推出集中式数据库，这是为什么？

其实最关键的还是场景适配的问题，对于一个数据库到底好不好用，用起来怎么样，不同的用户有不同的感受，有些是极端的好评，有些是极端的差评。其实这都是真实感受，因为场景不同，导致了使用体验的极端差别。

分布式数据库大多数是互联网场景下发展起来的，最初是为了支撑高并发下的极致响应要求。因此大多数早期的分布式数据库都是分库分表的一种升级，使用的存储引擎多采用MySQL innodb系列。后来为了适应企业应用需求，才逐步向现在的分布式数据库方向发展。

大家都知道Oracle是集中式数据库的天花板，特别是在Exadata一体机加持下的Oracle，其强大能力是很多没用过一体机的朋友难以想象的。就别说Exadata加持下的Oracle了，前两天一个客户的系统有点卡顿，让我们帮助分析一下原因。我居然发现这套跑在两台2路服务器上的Oracle RAC 11204，周末的高峰期单节点一分钟平均事务量超过1.5万笔交易/秒，一小时平均值超过6000笔交易/秒，一小时平均的REDO量接近60MB/秒，而工作日这个系统的负载还要高一些。按照一分钟平均1.5万算，最高峰估计接近6万了，而且事务规模也不小，平均每个事务大概9K到22K REDO的规模，比Benchmark要大多了。可以看出在高性能全闪存储等现代硬件的加持下，10多年前的Oracle版本对这种互联网场景支持得也相当不错了。

从上面一个案例也可以看出，目前国产数据库想要替代目前各行各业的Oracle数据库，其压力还是不小的。就上面那个客户的系统而言，他们在未来两年内也是要做数据库国产化替代的，目前他们也正在测试国产数据库。在测试过程中，他们发现TDSQL、GoldenDB这些MySQL生态的国产数据库在这样的压力负载下，交易延时要比这些感觉上更加高大上的商产品要低一些。我和他们分析了其中的原因，这些数据库虽然在应用适配方面需要花更多的改造成本，不过一旦改造完成，innoDB高效轻量化的引擎，轻量化的全局事务管理，会让交易延时在分布式环境中达到最小。

而TiDB则走了另外一个极端，TiDB是对应用开发极其友好的，在Oracle上开发应用的开发人员，不需要掌握分库分表的技能就能把Oracle数据库的数据迁移到TiDB上，应用也无需做单元化或者表组等方面的性能适配。不过还是那句话，没有完美的数据库，TiDB也是如此。LSM-TREE存储引擎的较长的查询路径以及TiDB Server的无状态下全局缓冲的缺失，会让用户遇到“稳定的慢”这个问题，TiDB很稳定，性能也是如此，但是TiDB目前的版本在追求极致的响应时间场景相对不如友商产品。当然TiDB也在努力在低延时道路上探索，不过受限于架构，这方面想要有较大提升还是比较困难。一个数据库产品，需要在任何地方都完美很难。

回到开头说的OceanBase和TiDB推出单机版的话题，为什么这两家分布式数据库做得那么好的企业还要推出单机版呢？还是应用场景适配的问题，分布式数据库在某些关键行业的核心系统上有着丰富的应用场景，但是并不是所有的场景和用户都适合使用分布式数据库的。集中式数据库市场在数据库国产化替代中还是最大的一块蛋糕。作为一个数据库产品，如果只能适合于大型的业务场景，无法覆盖集中式数据库的广泛应用场景，那么在市场上依然是会处于被动局面的。

单机版的TiDB和OceanBase，无需做分片分区，无需全局事务管理，可以有效地解决提升业务延时。存储过程的性能也可以得到极大的提升，这对于想要降低网络通讯延时的大型批处理业务来说也是一个利好。最关键的是使用成本大大降低了，运维管理的难度也大大降低了。中小型用户的市场是集中式数据库产品的主战场，这些分布式数据库厂商的加入，会让竞争更加激烈了。

上面我讲的内容似乎有点杂，其实这些纷繁的杂事还是围绕着“应用场景”这四个字的，看一个数据是不是好用，要看应用场景，看一个数据库产品能否成功，也是要看其支持的应用场景的范围。国产数据库产品只有扩大场景覆盖面，才能在竞争中占有优势。