数据库产品选型实践：内核、架构与生态的决策框架

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

上个月凌晨，一个做技术负责人的朋友给我打电话，声音都是抖的。他们公司半年前拍板换数据库产品，图便宜选了个小众产品。结果上线不到两周，核心交易系统每天卡死两三次，客户投诉堆成山，信创替代的deadline又卡在年底。他问我：现在换，还来得及吗？这个教训告诉我们：选数据库产品，最大的成本从来不是授权费，而是试错带来的成本。

这个电话让我想写这篇文章。"数据库产品"这四个字，天天有人挂在嘴边，可真要动手选，大部分人还是懵的。今天不讲入门概念，讲点更实在的，怎么从内核、架构、生态三个层面，把一款数据库产品看透。

一、数据库产品是什么？先把三层概念拆开

很多人把"数据库"“数据库管理系统”"数据库产品"混着说，其实这是三层东西，一层比一层具体。

数据库，是数据按某种结构组织起来的集合，是个抽象概念。数据库管理系统（DBMS），是真正跑在机器上的那套软件，负责存储、查询、事务、并发控制。而数据库产品，是DBMS的产品化交付形态，内核只是其中一层，外面还包着兼容层、驱动、管理工具、同步迁移工具、生态和厂商的技术支持。说白了，数据库产品等于内核加工具链加生态加服务。看产品只看内核，就像买房子只看户型不看物业和地段，后面有的是亏吃。

二、评价一款数据库产品，我只看四个层面

我评一款数据库产品，基本固定看四个层面：内核、架构、兼容、生态。任何一个有短板，都可能在生产环境放大成事故。内核层看存储引擎和事务模型，这决定单机性能的下限，也决定一致性做到什么程度。架构层看它是集中式、分布式还是云原生，这决定能扛多大的量、能不能弹性伸缩，是上限问题。兼容层看它对 Oracle、MySQL、SQL Server 的语法兼容到多深，直接决定迁移要改多少代码、花多少钱。生态层看工具链齐不齐、社区活不活跃，这决定你半夜出问题时能不能快速找到人问。这四层里，内核和架构是硬指标，兼容和生态是软实力，硬指标决定能不能用，软实力决定用起来累不累。

三、主流数据库产品，按架构路线重新排

比起按"关系型还是 NoSQL"来分，我更习惯按架构路线排。原因很简单，数据库产品选型时真正要拍板的，是架构，不是某个具体产品名。先把架构定下来，再在同一路线里挑产品，能少走很多弯路。

四、内核决定下限：存储引擎和事务模型

内核这层，最容易看出产品底子。我一般盯着两个东西看：存储引擎和事务模型，这俩直接决定一款产品单机状态下的表现。

存储引擎分两派。B+树代表是InnoDB，适合点查和范围查，随机读友好，绝大多数关系型产品都走这条路。LSM树代表是RocksDB那一系，靠顺序写加后台合并压缩，写入吞吐极高，代价是读放大。你业务是写多读少还是读多写少，直接决定了更吃哪一套。

事务模型看ACID和MVCC。ACID是底线，这个不用多说。MVCC才是拉开差距的地方，多版本并发控制让读写互不阻塞，隔离级别从读未提交到可串行化，每一档都有代价。选产品时别只看它支不支持事务，要问它默认隔离级别是什么，在什么负载下会退化成锁等待。

最后看查询优化器。现在主流产品都是基于代价的CBO，靠统计信息选执行计划。统计信息准不准、能不能手动干预，决定了慢SQL能不能被救回来。这块我吃过亏，后面避坑清单里细说。

五、架构决定上限：集中式、分布式、云原生的权衡

内核再好，架构不对，也扛不住增长。这是我在一次扩容事故里学到的，当时单机跑不动了，临时加机器才发现整个架构就是单机的思路，改起来比换产品还费劲。所以架构要在选型阶段就定，别等业务倒逼。

集中式是最稳的选择。单机加主备，或者上共享存储集群，多个实例读同一份数据，Oracle RAC是这个路线的标杆。优点是运维简单、事务一致性天然成立；缺点是扩展有天花板，单机终究会到顶。

分布式是共享无架构，数据按分片键拆到多台机器，用分布式事务和一致性协议保证整体一致。它能扛的量级确实大，但代价是真金白银的复杂度：跨分片事务、全局唯一ID、分布式死锁，全是坑。我的判断是，数据量没到单机上限，别碰分布式。

云原生这两年火，核心是存算分离。计算节点和存储节点独立伸缩，秒级扩容，流量回落再缩回来。适合弹性明显的业务，但要看清楚厂商锁定的问题。还有一条HTAP的路线，一份数据同时支撑交易和分析，省掉传统的ETL链路，对报表需求重的业务，能省下一套数仓的成本。这个方向今年很热，HTAP在金融交易和实时风控里的普及率，预计能过六成。

六、国产数据库产品的分水岭：兼容和生态

聊到国产，真正的分水岭不是性能跑分，是兼容和生态。跑分这事，各家都能晒出漂亮数字，真到了迁移，才知道兼容深度才是硬功夫。

兼容这层，很多人只看SQL语法能不能过。其实远不止。存储过程、函数、游标、触发器、数据类型映射、包，这些对象的兼容度，才决定一个Oracle老系统的迁移工作量。语法兼容只省写代码的工夫，对象兼容才省改代码的工夫。

生态这层，看工具链。迁移要有评估、转换、校验三件套，同步要支持增量CDC，再加上监控、备份、开发工具。工具链断一环，迁移就得靠人工补，成本翻着倍往上走。

我上手过的国产库里，金仓的KingbaseES算兼容做得省心的一个。拿Oracle迁移来说，存储过程、数据类型这些最容易卡壳的地方，它基本接住了，实际要改的代码比预期少不少。金仓在部委和央企的底子比较厚，部委占有率超过七成。我接触的项目里，金融、政务圈子里拿它顶 Oracle 的，也确实一年比一年多。金仓这两年还有个明显变化，把集中式和分布式收进同一套内核。起步用集中式，量上来了再扩成分布式，中途不用换产品线。核心代码走自主研发，这在国内库里不算多见。

七、一个真实案例：金融核心系统的国产化替换

讲个我参与过的项目，那家区域性银行的信贷系统，原来跑Oracle，领导拍板要替换成国产，前提只有两个：性能不能掉，成本要压下来。

我们最后选了金仓的KingbaseES。评估阶段最担心的就是存储过程和数据类型，结果它的Oracle兼容帮了大忙，大部分对象基本没怎么改就过了。上线压测，事务吞吐量比原架构高了35%，成本降了50%。这两个数我盯过测试报告，不是听销售吹的。

我印象最深的是切换那天。业务方本来做了最坏打算，结果平稳得没话讲。这让我确认了一件事：核心系统能不能上国产，决定性的不是宣传页上的跑分，是兼容深度和迁移工具链。

八、数据库产品怎么选？我的四步决策框架

踩了这么多年坑，关于数据库产品怎么选，我固定用一个四步框架。这套东西不保证选到最好的，但能帮你避开大多数因为拍脑袋造成的返工。

第一步，先定架构。数据量和并发没到单机上限，就选集中式，别为分布式而分布式。真到了要拆库的量级，再上分布式或云原生。

第二步，再看内核。写多读少还是读多写少，决定你吃B+树还是LSM。事务要求高的，把MVCC和默认隔离级别问清楚。

第三步，卡兼容。有存量系统要迁的，把Oracle、MySQL兼容深度和迁移工具链摸透。信创采购多了个硬门槛，国测安全可靠测评，分I级II级。没过名单的，基本进不了采购。这一步能直接淘汰一半候选。像金仓这种兼容和工具链做得全的，会在这一步自然浮出来。

第四步，跑验证。拿真实业务做POC，性能、兼容、迁移成本三样都实测一遍。宣传册再漂亮，也顶不上自己的业务跑一遍真实数据。

九、数据库产品选型，我踩过的坑

写到最后，说几个我踩过的坑，都是真金白银换来的。

先说跑分。我早年被TPC分数忽悠过一次，选了款跑分漂亮的产品，结果真实业务一上，慢得怀疑人生。跑分是实验室里的理想状态，跟你的业务场景是两码事，一定拿自己的场景去测。

迁移成本这事最容易算漏。很多人只盯着软件授权费，等真动手才发现，改代码、迁数据、培训人，三样加起来比授权费还贵。预算得按总成本算，不能只算那点授权费。

还有个印象深的，是统计信息失真。有次优化器因为统计信息过期，选错了执行计划，一条SQL从毫秒级掉到几十秒，查了一天才定位。所以选产品时一定问清楚，统计信息能不能自动更新、能不能手动干预。

最后一个是追新。我见过团队硬上分布式，数据量还没到单机上限，白养一堆节点，运维天天喊累。选型真不是越新越好，是够用就好。

总结：数据库产品选型，就认这四层

回头看，数据库产品选型，其实就是四件事：内核保下限，架构定上限，兼容省迁移，生态保平安。四层都过关的，才敢往核心系统上放。

金仓的KingbaseES我印象里，是四层都还算均衡的一个，没有特别明显的短板。最戳我的是它一套库能接多种数据模型，不用为了个文档存储再单独挂一套。正在做信创替换的团队，可以把它放进POC名单里跑一跑，适不适合自己的业务，一测就知道。

你选数据库产品时，踩过最深的坑是哪个？评论区聊聊，我挑几个有代表性的，下篇展开讲。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋