一个真实的案例，一些真实存在的数据库选型误区

一个真实的案例，一些真实存在的数据库选型误区

最近，老鱼听说了一个案例！

某银行计划部署分布式数据库来替换业务核心的集中式数据库。先期计划在某一核心业务进行试点，然后根据试点情况，再决定是否继续大规模实施。

试点的核心业务使用的是“O”记数据库，一个3节点RAC ，3台小型机， 2台用于业务系统，1台放在同城灾备中心作为远程数据备份。替换后，数据库为某分布式数据库，使用多达600多台的X86服务器。

目前，该试点业务已经部署完成，峰值性能（TPS）较替换前提高50%，平均性能（TPS）提升33.3%，平均事务响应时间未知。

最终，该银行决定不再继续实施，而是维持现状。

到这里，相信大家应该也能看出点什么。

3节点RAC能做的事，为什么需要如此多的X86？

没错，即使不同银行的核心业务复杂度有所差异，即便替换后有50%的性能提升，但是！但是！但是！重要的事情说3遍，反正，在老鱼询问了多位专家后，大家观点是完全一致的，都不认为需要如此之多的机器，这是在烧钱！即便不差钱，也应该考虑给开发和运维团队在未来工作中带来剧增的额外工作量及复杂度。

如果是由于分布式事务导致网络延迟，因此需要更多的服务器，只能说明这个分布式数据库架构设计差强人意。平均事务响应时间未知，这是因为在应用层实现了？那以上网络延迟又被推翻。

这个项目5年TCO并不难测算，投入破亿是肯定的。硬件成本（服务器、交换机等）、软件成本（操作系统、数据库授权），包含第四/五年维保成本都很容测算。

但有一项成本可能很容易被忽略，那就是运维成本，它或许会占到整体采购成本的20-30%。分布式数据库运维是痛点，分布式改造后运维和开发的工作量必然激增。

从运维角度看，因为硬件大量增加，假设原来3台小型机只需要2个运维，那现在600多台X86需要的运维就得翻倍，甚至更多。假设一个运维平均年薪20万，5年就是100万，如果增加3个就是300万。其次，大量增加的机器，势必导致电费、散热、机房使用等成本提升。

从开发角度看，架构的改变，很少不动应用的，甚至完全重构应用都有可能。

因此，无论是从性能还是成本来说，这个案例都是没有性价比的。

虽然这个案例有些极端，但反映出的一些市场上真实存在的潜在问题或认知误区，值得我们去深入探讨。

最近几年，分布式数据库成为潮流，在各种光环加持下，仿佛黑暗中的灯塔，难免有些过度神话了。

不仅各路厂商或主动、被动的发布自己的分布式数据库产品，市场产品群雄逐鹿。很多传统企业也在纷纷试水分布式数据库。大有不上分布式数据库就要被时代淘汰，没用过分布式数据库就显得特别LOW的架势。

在试水的企业中，有成功的，也有失败的。由于分布式数据库尚无统一的业界标准，因此，各有各的看法。

老鱼认为，没有万能的数据库，只有最合适的数据库。

分布式数据库虽好，但也并非万能“银弹”，也分场景，也有自己的短板。而要清楚当前分布式数据库的最佳适用场景，这就要从分布式数据库的历史背景及走红原因说起。

▍历史背景

分布式数据库在数据库历史的早期就有了，其研究始于20世纪70年代，世界上第一个分布式数据库系统SDD-1是由美国计算机公司（CCA）于1979年在DEC计算机上实现。

但分布式数据库直到最近几年才被关注，其原因也是多方面的。

在互联网诞生以前，企业数据规模不大，以“O”记为代表的传统数据库足以满足绝大多数数据管理的需求，因此，分布式数据库并无用武之地，这其中还有两个方面的原因，首先，这个时期，市面并没有较好的分布式数据库产品，其次，分布式数据库本身不可以免的存在一些缺陷。

但进入互联网时代以后，面对时刻增长的海量数据、同时在线的海量用户，传统数据库的已经难以支撑业务发展。于是，以互联网行业为首的企业开始探索有效的解决方案。

先是NoSQL发展起来，NoSQL牺牲了关系型数据库的一些限制，例如：强一致性，为数据处理带来的扩展性。之后又催生了NewSQL，定义了一种新型的数据库，兼具扩展性与传统关系型数据库的特性，最典型的代表就是基于谷歌Spanner/F1 论文。

在这个过程中，传统数据库也在进行自我救赎，最常见的就是分库分表方式，但这种解决方案需要应用系统做大量改造，需要感知数据存储位置，同时增加了运维复杂性。

于是，就有了分布式数据库的两种技术路线：开源数据库+分布式中间件的解决方案，比如MyCat，优点是可以利用现有开源数据库成熟稳定的产品功能，缺点是中间件毕竟只是一种迂回的方式，会受限于单机数据库的功能。

另一种技术路线即原生分布式数据库，天生具有分布式的特性，从设计之初就是针对分布式架构进行设计的，缺点是产品成熟度还有待提升，还需要经过不同场景、不同规模数据量和不同行业应用的检验、改进和完善。

目前，一般性的共识是数据量不上一定规模，没有超高峰值，没有高并发的场景就没必要用分布式数据库，因为，很可能不但不能获得什么明显优势，还要牺牲集中式的单机扩展性和开发及运维简单便捷性。

如果只是为了实现国产化替代，其实一些国产关系型数据库也能满足需求，并没有必要直接上分布式数据库。

总的来说，分布式数据库的优点是扩展性好，数据能分散存储在多个节点，能实现水平扩展。并且多个节点，可以并行执行，提高了整体的吞吐。

缺点是分布式事物处理的代价较高，这种代价主要源于两阶段的提交造成过多的消息传输；可能的锁争用变大；复制多副本和高可用。其次，产品成熟度有待提升，运维复杂。

▍ 常见误区

1、分布式改造只是个技术问题

从传统集中式架构改造为分布式架构，并非一个简单的技术问题，而是一个技术生态切换的问题。

数据库的分布化，带来的不仅是数据库系统重构，还有应用系统的重构。分布式数据库一般不支持存储过程，SQL执行效率低，而这些问题通常只能在应用端解决。

相比传统数据库，分布式数据库的开发和运维的技术要求会提高一个档次，民生银行的技术负责人就曾表示，分布式改造时，开发一个智能化的运维平台非常重要。

因此，上分布式数据库前，需要做好整体规划，在资金、环境改造，人员技能、管理自动化和技术储备等各个方面做好充分准备。

2、分布式改造会降低TCO

分布式数据库有两种技术路线：开源数据库+分布式中间件，原生分布式数据库。由于研发分布式数据库产品的公司多为互联网、创业公司等，它们一般都以使用 MySQL 为主，因此，很多人认为部署分布式数据库，软件采购费用会降低，X86替代RISC，硬件单价会大幅降低，所以，TCO会降下来。但实际情况也可能并非如此。

比如本文开头的案例，就是个例子，当然这个案例有点极端，再举个例子。

某全国性银行的信用卡系统，原数据库系统为4台小型机，分布化改造后，需要120台数据库服务器，软硬件采购成本降低了50%，但是运维人员增长了66%，开发人员增长了5倍，计算5年整体拥有成本，比原来提高了60%以上。节省的采购成本并不能覆盖后期增加的运维和开发成本。

从这个案例看，分布式改造只是降低了首次购买成本TCA，整体拥有成本TCO并没有降低。

3、不发掘现有系统潜力，盲目照搬互联网模式

有句俗话叫“技术跟着业务走”。IT架构的进化升级需要与企业业务转型同步，落后则制约业务发展，激进则会造成投资浪费，甚至给业务带来风险。

传统企业和互联网公司的业务相比有着根本性的不同。互联网公司有三个显著的特点，即海量的用户、用户的高频访问和交易、业务的高频创新，比如抖音、快手、今日头条，一年时间就可以发展几千万用户，每个用户每天多次登陆使用。所以，IT基础架构一定以扩展性、灵活性为第一追求。

传统企业的核心业务相对稳定，而且用户数量有限，交易频率不高，开发人员少、IT支出少，业务对于IT的需求同互联网公司有着根本性的差异。很难承受分布式改造带来的经济成本和技术风险，通常只能依托第三方提供的整体方案和服务，因此，对于这类企业，传统的集中式数据库仍然是最好的选择。

比如本文开头的案例，要提高数据库系统性能，只需要把硬件平台从双路、四路服务器升级到八路、十六路等大型服务器上，就可以覆盖绝大部分业务需求。成本未必比直接上分布式高，甚至可能还要低。目前，国产服务器、小型机品类齐全，价格也很透明。如果这样还不够，就来个RAC集群，不少国产关系型数据库也大都有RAC集群扩展方案。

▍写在最后

总的来说，用什么数据库，完全取决于业务需求。

业务用数据库来做什么？分析还是交易？或者两者兼而有之？业务要处理什么样的数据？对数据库性能需求是什么？

如果是传统的ERP、CRM、财务等与“钱”相关的核心业务系统，需要事务完整性，保证ACID事务，那么，毫无疑问，传统的集中式关系型数据库是最佳选择。

业务要处理什么样的数据？结构化？半结构化？非结构化数据？决定需要支持的数据模型。原则上“什么数据模型，就用什么库。”

如果你要存储和处理的是图片、音频、视频等非结构化数据，那么，NoSQL数据库会是最佳选择。进一步来说，业务要存储游戏场景中的角色信息、经验道具信息、好友排名等信息，而这些信息一般都和 ID（键）挂钩，那么，键值数据库是个很好的选择。

业务需要处理的多大的数据规模、并发吞吐量、响应时间需求是什么？决定了对数据库的性能需求。

如果业务是秒杀，春节火车票等，有超高峰值、高并发的业务，那么，分布式数据库会是一个不错的选择。

综上所述，虽然针对架构和数据库选型的讨论会一直存在，但归其核心，一定要明确的一点就是：“业务需求主导技术创新“，理性分析和对待架构和分布式数据库的选型，选择业务场景最适合的架构和数据库才是王道。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。