借鉴与参考

今天的题目展开了是两句话，成功仅供参考，失败可以借鉴。昨天XPROSS针对沙利文的2021年的分布式数据库发展报告组织了一场关于分布式数据库的线上圆桌会议。

昨天参会的金融行业的朋友比较多，大家也都十分关注数据库选型的问题，实际上昨天的几个问题也都和数据库选型有关。期间，广发银行负责研发的李总发言表达了对数据库选型的一些想法，他认为数据库选型实际上并不关键，关键是选型后怎么去面对，怎么去客服困难，解决问题，把选择的数据库用好。而参会的平安科技的汪洋总则认为数据库选型是需要慎重考虑的，他们的首选是拥抱开源技术，因此他们以PostgreSQL和TIDB这两个开源项目为基础，自己研发了自己的数据库产品，并用于平安集团，取得了良好的效果。家家有本难念的数据库选型经，数据库选型的经验很难有一个标准的答案可以借鉴，因为不同的企业的企业文化、业务场景、安全诉求、IT投资规模、研发能力、运维能力、原有数据库运行环境等各不相同，因此在数据库国产化替代工作中采取的措施也会差异很大，僵化的照搬成功经验风险极大。
而作为企业信息系统中场发动机的数据库产品，对于企业数字化转型至关重要。数据库选型的正确性会影响到企业数字化转型的效率、成本、可持续性等因素。企业数字化转型中的一个特点是数据与数据处理需求的爆发性增长，随着频繁发布的业务，数据库也滚雪球似的增长，因此功能强大的数据库系统依然是提高企业研发效率的最重要的手段之一。而对于绝大多数传统企业来说，研发效率的提升意味着研发投资降低，业务优化加速。
而在数据库选型上，需要根据企业自身的业务特点、历史技术储备以及数据库应用现状。作为企业的高层决策者来说，数据库选型最重要的还是要看成本。这个成本不是简单的数据库采购成本，而是整体拥有成本，全生命周期使用成本。从应用迁移、部署实施成本，到运维支撑的成本变化都是要综合考虑的。另外与现有云平台的融合成本、与数据中台、数据仓库的接口改造，数据库备份备份与高可用方面的改造成本也不是一笔小钱，而且往往是我们在选型初期容易忽略的。我想一个精明的企业CIO绝对不会简单的依靠招标的最低价来选择数据库产品。
还有很多朋友总是说，我们直接借鉴互联网企业的成功经验不就可以了。事实上，很多传统企业的CIO都持有这种观点，在全面否定了自己IT建设的过往之后，很多人都会走到另外一个极端去。不过企业自身特点的差异，业务类型的差异决定了绝大多数互联网企业的成功经验无法拷贝到传统企业来，并成功应用。成功是仅供参考的，互联网企业的成功只说明了采用此种模式是会成功的，并不说明你去照抄也会取得成功。一个只会用SQL开发MIS系统的研发队伍，你非要然他们去采用互联网企业的领域建模，微服务架构去开发一套复杂的业务系统，其效果往往是惨不忍睹的。我以前说过一个案例，某企业学习互联网企业的经验，采用微服务架构开发新一代营业系统。不过研发企业的能力有限，大部分程序员只会写SQL语句来实现业务。最终只能把拆分成30个小数据库的系统合并为6个大型数据库，即使如此，很多功能模块还是遇到了巨大的挑战，因为上一代系统是基于一个单一数据库开发的，很多复杂的业务逻辑在上一代系统中都是用超级复杂的SQL完成的，开发人员不敢随意修改。最后只能在这6个数据库之间又创建了上百张表的多向复制，才算完成了这套系统，这套不伦不类的微服务架构的系统，今后的升级与运维都存在巨大的风险。并不是微服务架构不好，领域建模不够先进，而是企业自身的研发能力不足，导致我们只能看着领居家香喷喷的饭菜眼馋，自己却做不出来。
隔壁老王的成功无法复制，不过幸运的是，失败的经验总是可以拿来借鉴的。因此多学习学习别人失败的案例还是十分有必要的，只不过是大多数企业哪怕失败了也只能打掉了牙往肚里吞，想了解失败案例并不容易。
正是因为每个企业有自己的特点，因此照搬成功经验或者借鉴失败教训都不是一件容易的事情。事情到了自己头上还是要靠自己的力量来解决。对于IT力量十分强大，自身研发能力较强的企业，比如平安科技，那么选择开源数据库进行自己消化吸收，既可以避免被某个原厂锁定（VENDOR LOCK-IN），又可以避免被云厂商锁定（CLOUD LOCK-IN）。应对VENDOR LOCK-IN可能很多大型企业都已经有经验了，在采购中培植多个可以相互竞争的产品，就可以有效的避免VENDOR LOCK-IN的结果最恶化。不过CLOUD LOCK-IN是一个更深的陷阱，一旦你选择了采购某个云产品，则CLOUD LOCK-IN就不可避免了。等到你选择的数据库要上云的时候，云厂商往往会千方百计的阻挠某些数据库产品上云。不过面对具有较强IT基础设施研发能力，并且有自身自用的需求已经足够大的企业来说，这一切都不是问题，采用类似平安科技的方法，选择开源代码为基础，研发自己的数据库产品，供自己使用。
如果IT基础设施研发能力并不是很强，或者没有足够信心直接使用开源数据库产品，那么只要你的应用研发自主性够强，能力足够，那么数据库选型确实也不是特别难的事情，在乱花渐欲迷人眼的产品面前，选择企业规模够大、历史不算太短、业内口碑不错的数据库产品就不会有太大问题了。遇到的数据库问题，都可以用通过应用想办法去解决掉。这类企业重点考虑的是成本问题就可以了。整个企业的业务部门提出对业务系统的需求；运维部门制定好运行方式，完成运行架构、高可用、备份、双活等的运行规范；研发部门评估系统迁移的成本，确定应用改造、数据迁移、SQL优化的方案；IT高层管理人员组织方案编写，方案评审，最终批准整个方案就可以了。
如果很不幸，你们不属于前面的两种情况，那么数据库选型确实就会成为一个十分重要的问题了。如果选型错误，就会对你的信息系统建设与迁移造成极大的影响。某大型企业的财务中台，以前系统是Oracle的，大量使用了存储过程。迁移方案当时听从了云厂商的建议，使用RDS，经过一年时间的改造迁移，在试点运行时发现问题了，RDS能够承受的数据量、并发处理能力十分有限，如果要完成全面部署，需要300多个RDS实例才能完成。这么大集群的分库分表，读写分离，研发，部署，运维都是灾难性的。于是项目组准备改方案，云厂商又建议使用DRDS。用户单位的领导有点怕了，就找了一些专家来帮着评审一下方案。我正好参加了那次评审，我看了方案，就问了一个问题，DRDS现在能支持存储过程了吗？
如果我们身边的经验教训都不足以帮你做出合理的选择，那么先做一些尝试也是可以避免出现大问题的方法。先不要太多的去考虑选型正确性问题，而是通过初步的分析，选择出几个可行的方案。找自己的一套要迁移的系统，一定不能找最为简单的，可以选择中等规模，中等重要程度的系统，用首选方案做一次迁移。看看整个迁移过程是否顺利，上线后是否和评估时的情况差不多。
我的一个客户采用首选方案完成了一套系统迁移后，感受到这个数据库产品和他们期望的还有些不同，于是第二套系统选择了另外一个备选数据库产品。经过两次迁移后，他们发现第二次的选择对他们来说更适合，迁移成本更低，迁移后运行，维护也更顺利。于是他们决定大规模使用第二套方案开展迁移工作。
不管怎么样，与其在那思考来思考去，先走出第一步可能是最重要的。不过在这些选择过程中，还是要记住这句话，成功仅供参考，失败可以借鉴。