国产数据库选型，你该做好这几点

摩天轮上收录的国产数据库多达280多种，百库大战的背景下，无疑给企业的数据库选型带来了巨大的挑战，毕竟更换数据库是一项投入巨大的工作。那么对于决策者来说，如何选择适合自己的数据库呢，今天我们来说说这个话题。

没有哪个单位能忍受三天两头的宕机，轻则劳民伤财，重则乌纱不保，所以这个指标放在第一位。纵观当前市场上主流的国产数据库产品，稳定性做的都还不错。用于核心系统的基本都采用多副本的分布式架构，这种架构下少数单节点的故障并不会对数据库整体的正常运行带来影响;而采用单机架构的非核心系统，要么系统压力很小，要么其重要程度不高，即使出现问题也不会引起太大的关注。

稳定性检测技术也比较成熟，各种极限破坏性测试，持久疲劳性测试，会让稳定性不够好的系统现出原形。

性能问题从两个方面来看，一是某个场景下的处理峰值，比如OceanBase、TDSQL等都宣称自己打破了记录，这种需要大量服务器的堆叠以及应用和数据分布的精心设计，才能发挥整体架构的最大性能，这个数据大家做个参考就好，不必太当真。另一个是混合负载下的真实业务场景，这个需要结合各单位自己的业务去综合评估，比较考验实施厂商和客户开发和运维部门的水平。

性能方面不建议片面的考察某些记录值，结合真实业务需求选择适合自己的就可以。做过运维的同学都知道，系统一如既往的慢其实问题也不大，因为大家的预期就是这样，一个批量跑5个小时和8个小时，只要不在关键路径上，其实并没有本质的区别，怕的是昨天5小时今天8小时这种突然的变化。领导每天早上8点要看报表，结果你说今天11点才能给。谁尴尬谁火大，经历过的都知道!

生态是一个很大的话题，也是数据库选型工作中需要重点考虑的因素之一。

数据库不是独立存在的，作为应用系统中承上启下的关键组件，选型关系到中间件、操作系统、硬件平台等上下游的产品，良好的生态支持能够大大节省应用改造、数据迁移和日常运维的成本，反之亦然。

很多国产库在宣传的时候，都说自己能够兼容Oracle、兼容MySQL。其实兼容也要从两个方面来看，一种是单纯意义上的SQL语法兼容，更重要的是优化器对于复杂SQL性能上的支持，这一点国产数据库和Oracle等国外商业数据库还有不小的差距，因此在国产化改造的时候通常需要对SQL语句进行改写，尤其是将复杂的SQL语句尽可能拆分为单表操作，尽量减少多表关联等复杂操作。

相信大家都有过这样的经历，对于自己不熟悉的东西，是不敢轻易去做决策的，对应到数据库选型也一样。所以人才培养是一个长期的过程，今天的小兵学习了某个名不见经传的新兴国产数据库，某个合适的机会就会向领导推荐，甚至将来小兵走上领导岗位，可能就直接拍板了。

国产数据库面世时间比较短，网上能找到的资料相对较少，即使是官方文档质量也参差不齐，很多时候依靠自己的DBA根本解决不了问题，这时候社区就能派上大的用场。

但是当前有些厂商对社区和人才培养并不重视，一个问题可能几天也没有人回复，一个初级的认证培训5000+，要说是认真做生态，我是不信的!

相关的产品在同行业有没有成功案例，客户对产品的反馈如何，这是产品能力和厂商开发、实施能力最直接的证明，因此也成为决策过程中非常重要的考察因素。所以有些厂商前期不惜血本的投入，就是为了拿到成功案例，然后依此为辐射向外扩张。

相信大多数朋友都经历过2011年团购业的“百团大战”，最终只有美团活了下来;2017年大小城市的马路边停满了各种颜色的共享单车，巅峰时甚至七色彩虹的颜色都不够用，如今还能在路边见到的不外乎青桔、哈罗和美团三个品牌。

当前行政力量催生的数据库行业“百团大战”，最终仍然会遵循市场的规律，预计未来的3-5年，最终可能只有不到10%的厂商能够活下来。对于决策人来说，当前选择的数据库，未来5年是否还活着，是否还有厂商更新产品提供更强大的功能，提供技术支持修改Bug，是一个非常重要的考量点。

总的来说，数据库国产化替代是一项复杂度非常高的工程，尤其是核心系统，通常都是以5年期来进行规划的，涉及到的资金投入达亿元以上。错误的决策可能会带来后期运维等多方面的成本增加，严重的甚至导致上亿的投入打水漂。

当年的共享单车不知道大家还没有押金没有退的，一两百的押金可能都会让你心疼一阵子，何况这些巨额的投资呢?!

关于国产数据库的选型，您还有什么建议呢?欢迎留言讨论。