关键应用数据库选型防跑偏指南

题图：来自unsplash（Abbilyn Zavgorodniaia）

数据库选型一直是业界热议的话题之一

如今，国内数据库界可以说是百花齐放，各有千秋，选择多了，选型就变得困难。因为，没有数据库厂商会告诉你，他们的产品不好，只会说自己的产品。但是，一“库”包打天下，就连头部的Oracle都做不到,何况其它数据库。

因此，没有完美的数据库，每个数据库产品都会有着自己的优点和缺点，并且价格从免费到数百万不等。

不同企业，因为组织架构和数据库选型要求不同，采购流程也有一定区别，因此，数据库选型也没有的正确答案。

定位关键应用数据库选型，就意味着业务数据价值较高，对数据库产品技术指标，如：高可用、强一致、高性能等的要求就较为，对于容灾、备份、安全、运维管理的全方位体系都是需要考量的。而供应商品牌声誉、行业案例、生态建设、服务能力等也是选型中不可缺少的外围考量因素。

因此，在为你的关键应用系统选择数据库时，尤其需要小心，而在众多的选型核心指标当中，老鱼认为以下5个方面可能容易跑偏。

数据库“ 稳 ”是位的，尤其是关键应用数据库。大多数运行关键业务的企业，担心的不是硬件损坏带来的金钱损失，而是因某个业务异常停止工作给企业的生产、运作、安全乃至企业客户带来的无法估量的经济和名誉损失。

道理谁都懂，但是到真正考量时就容易跑偏了，数据库代码是否经过充分长期的验证，是否有足够的安装和生产案例，是否有完善的知识库解决问题，架构上是否即便发生Core Dump也不会有全局影响，对于构成数据集群的组件各种各样故障RTO能不能尽可能接近0是非常重要的。

尤其是关键业务系统需要的业务连续性的架构设计，从计算节点高可用到存储节点高可用，到备份可用性验证甚至零数据丢失的技术，从方法论到部署实例的佳实践都需要落地。

但现实中，往往容易走到仅仅盯着发生几率极低的站点级故障容灾方案是怎样的，日常更加容易影响业务连续性的情况被忽略。

稳，意味着要采用被其他用户多次使用过的数据库，这就像我在电商买商品，必须要看该商品的购买量，购买量是1000，就比100要好，如果是10万+我们就可以比较放心。毕竟我们不是前几个吃螃蟹的。

关键业务支撑需要强一致性，也就是需要ACID。相对于单机较容易实现的ACID，分布式环境中却要难的多。

目前，无论是互联网公司还是新兴数据库公司，数据库层面都强调自己的分布式数据库能做到强一致。

但是现阶段各家提出相应的解决方案，如：2pc/3pc、TCC机制、事件队列/本地消息表机制、大努力通知机制等解决方案都不完美，需要进一步的探索。

不少分布式数据库脱胎于Google Spanner论文，但仔细看论文，你会发现终一致性在业务上到后期是难以承担的，这不是预测，而是有真实案例发生。真正意义上的ACID和某些中间过程基于BASE的数据库能力还有巨大差别的。

性能犹如粮食，在数据库的历史上，一直就不够用，虽然现在各种高性能的架构其实已经让性能不再成为问题，但是，还是会发现，这种担心性能不够的心理还在影响着非常多的人。

有一点可以肯定，如果不用担心性能，必然可以充分释放业务的想象力。

可扩展性不应该以牺牲高性能、低响应时间为前提。业务日趋复杂，单笔交易可能需要上百条SQL，如果由于架构问题导致每条SQL延迟增加数百us甚至ms级别，那整体业务的响应时间直接就会降低客户满意度。

同时不应该由于分布式引入导致性能严重下降而需要机器、节点的数量暴增10倍甚至几十倍，这样的运维管理成本是难以接受的。同时在某些特定场景要求响应时间需要越快越好，避免应用服务器和数据库服务器过多网络交互的场景，分布式架构数据库是否有高性能的数据库内置的过程化语言也是非常重要的一个高性能考量点。

计算与存储分离的技术也是数据库高性能与动态扩展的重要能力评估，但计算节点的数据缓存能力（包括本节点或者其他节点的数据）避免进行跨节点通信是的加分项，如果都是无状态计算的逻辑会导致每笔事务大量的存储节点访问，效率降低。

近年来支持HTAP混合负载的数据库产品正在受到越来越多的关注。什么才是HTAP一体化支持的王道？

要避免数据在OLTP系统和OLAP之间的迁移带来冗余、迁移过程错误等等问题，同时让生产性报表不用等T+1才能提供。

随着业务越来越复杂，单纯的基于索引访问的纯OLTP、完全做全表扫描和JOIN的DW或将成为历史，越来越多的DW变成数据中台，一样要直接参与生产直接参与业务交互，也需要支持大并发的类OLTP访问。

真正的HTAP应该包括OLAP/DW中大量的ETL操作，全表扫描对OLTP业务的小影响，不仅仅是集群算力控制，还包括IO资源的动态分配，内存缓存资源等等方面都是要考虑的因素。支持内存里列式存储的数据库存储引擎好是跟数据库一体而不是单独COPY一份数据，按照新的格式来存储，这才是HTAP一体化支持的王道。

选型不仅只关注产品技术相关指标，很多外围指标也要考虑进去。

选型前期，企业需要注意供应商在行业内的口碑、综合声量和案例丰富性。

对于一个的数据库产品而言，周边生态和原厂的技术支持能力是不得不说的话题。

产品能否为客户提供丰富的企业级能力，例如存储过程、复杂查询。应用开发是否便捷，分布式对于应用开发复杂度等侵入影响决定具体实施还离不开人工方式来解决。市面上是不是有足够多、足够技能的人才可以招聘得到，足够多的各类运营及开发接口及现成应用能够对接也是重要因素。

其次，真正用以支撑关键业务，数据库不是仅仅能跑就行，从长期的运维管理来看，多版本维护、补丁分析、版本升级之外还有大量重要的功能点，这往往很容易被忽略。比如是否具备真正完善的备份恢复能力，安全性，等保级别保证，补丁操作管理和回退机制等等。

另外，技术支持能力取决于是否掌握核心技术，因为这直接关系到解决问题的能力。数据库运行，要想完全不出问题是不可能的，但是出了问题是否能够快速准确的定位问题，是否具备源码级解决问题的能力这是一个重要考量，否则企业面临的风险会很大。

后，关于数据库的选型，不同人的立场与出发点不同，面对的问题也不同，身后的压力也不同，所以，关于数据库选型每个人的观点可能都会有较大差异。

此前，老鱼曾经写过一篇《一个真实的案例，一些真实存在的数据库选型误区》的文章，其中就谈到一个为了去“O”，盲目跟风导致失败的案例，并未取得性能及经济效益大化的目的。

因此，时髦的不一定是适合你的，集中式数据库并不意味着落伍，分布数据库也并非万用良药，二者各有优势。事实上，大多数关键应用采用单机数据库，再加上读写分离，高可用集群的方案就足以支撑。如果你的关键业务还具有超高峰值、高并发等特点，那么这时候，分布式数据库就会是一个不错的选择。

总的来说，当真正为关键应用选择底层的数据库架构支撑时，其实很多现在流行的说法是有误导的成分的，要仔细研判需求，找到合适的数据库架构需要仔细的考量和分析。