最近，老鱼听说了一个案例：某银行计划部署分布式数据库，以取代其业务核心的中心化数据库。前期计划在某项核心业务进行试点，再根据试点情况决定是否继续大规模实施。试点核心业务采用“O”型数据库，一台3节点RAC，3台小型机，2台业务系统，1台在市容灾中心进行异地数据备份。更换后的数据库为分布式数据库，使用了多达600台X86服务器。目前，试点服务已经部署。峰值性能（TPS）较替换前提升50%，平均性能（TPS）提升33.3%。平均事务响应时间未知。最终，银行决定不继续进行，而是维持现状。说到这里，相信大家应该也能看出点什么了。一个3节点RAC就可以做到，为什么还需要那么多X86？没错，即使不同银行的核心业务复杂度不同，即使换代后有50%的性能提升，但是！但！但！重要的事说三遍。反正老鱼问了很多专家之后，大家的意见是完全一致的。他们认为不需要那么多机器，这是在烧钱！即使钱不差，也要考虑到开发和运维团队会给以后的工作带来额外的工作量和复杂性。如果是因为分布式事务造成的网络延迟，所以需要更多的服务器，那只能说明这种分布式数据库架构的设计并不尽如人意。平均事务响应时间是未知的，因为它是在应用层实现的？上面的网络延迟再次被推翻。这个项目5年的TCO不难计算，投资过亿是肯定的。硬件成本（服务器、交换机等）、软件成本（操作系统、数据库许可），包括第四年和第五年的维护成本，都很容易计算。但是有一个成本可能很容易被忽视，那就是运维成本，可能占整体采购成本的20-30%。分布式数据库运维是一个痛点，分布式改造后运维和开发的工作量必然剧增。从运维的角度来看，由于硬件的大量增加，假设原来的三台小型机只需要两次运维，那么现在600多台X86需要的运维要翻倍甚至更多。假设一个运维的平均年薪是20万，5年就是100万，再多3个就是300万。其次，大量的机器必然导致电费、散热、机房使用等成本的增加。从开发的角度来看，架构的变化很少会改变应用，甚至有可能完全重构应用。所以无论从性能还是成本上来说，这种情况下都不划算。这个案例虽然有些偏激，但反映了市场上一些真实存在的潜在问题或误区，值得我们深入探讨。近年来，分布式数据库成为一种趋势。在各种气息的加持下，他们就像是黑暗中的灯塔，难免有些过于神话了。不仅各行各业的厂商都在主动或被动地发布自己的分布式数据库产品，市场上的产品也在相互竞争。许多传统企业也在尝试分布式数据库。如果你没有分布式数据库，你就会被时代淘汰。如果没有用过分布式数据库，会显得很LOW。在试水过的企业中，有成功也有失败。由于分布式数据库没有统一的行业标准，各有各的说法。老余认为，没有万能的数据库，只有最适合的数据库。分布式数据库虽然好，但也不是万能的“银弹”。它们也分场景，各有不足。要了解当前分布式数据库的最佳适用场景，就需要从分布式数据库的历史背景和流行的原因说起。历史背景分布式数据库存在于数据库历史的早期，其研究始于20世纪70年代。世界上第一个分布式数据库系统SDD-1是由美国计算机公司（CCA）于1979年在DEC计算机上开发完成的。然而，分布式数据库直到最近几年才受到重视，其原因有很多。在互联网诞生之前，企业数据规模较小，以“O”为代表的传统数据库足以满足大部分数据管理的需求。因此，分布式数据库是没有用的。造成这种情况有两个原因，首先，在这个时期，市场上没有更好的分布式数据库产品，其次，分布式数据库本身不可避免地存在一些缺陷。然而，进入互联网时代后，面对不断增长的海量数据和海量在线用户，传统数据库已难以支撑业务发展。于是，以互联网行业为首的企业开始探索有效的解决方案。首先，开发了NoSQL。NoSQL牺牲了关系数据库的一些局限性，例如数据处理的强一致性和可扩展性。后来，NewSQL诞生了，它定义了一种新型的数据库，它兼具可扩展性和传统关系型数据库的特点。最典型的代表是基于GoogleSpanner/F1的论文。在这个过程中，传统数据库也在自我救赎。最常见的方法是分库分表。但该方案需要对应用系统进行大量修改，需要感知数据存储位置，增加了运维的复杂度。因此，分布式数据库有两条技术路线：开源数据库+分布式中间件方案，比如MyCat，优点是可以使用现有开源数据库成熟稳定的产品功能，缺点是中间件只是毕竟是一种解决方案。迂回的方式会受到单机数据库功能的限制。另一条技术路线是原生分布式数据库，本质上是分布式的。它从设计之初就是为分布式架构而设计的。缺点是产品成熟度有待提高，需要经历不同场景、不同规模的数据量。以及对不同行业应用的检查、改进和完善。目前普遍的共识是数据量不超过一定规模，没有超高的峰值，在没有高并发的场景下没有必要使用分布式数据库，因为很可能不仅不能获得任何明显的优势，而且还牺牲了集中式单机的扩展性和开发运维的便利性。如果只是为了实现本地化替换，其实国内的一些关系型数据库也能满足需求，没必要直接访问分布式数据库。总的来说，分布式数据库的优点是具有很好的可扩展性，数据可以分布存储在多个节点上，可以实现水平扩展。并且多个节点可以并行执行，提高整体吞吐量。缺点是分布式事务处理成本高。这个开销主要是由于两阶段提交导致的过多的消息传输；可能的锁争用变大；多副本复制和高可用性。其次，产品成熟度有待提高，运维复杂。常见误区1、分布式转型只是技术问题从传统的中心化架构向分布式架构转型，不是简单的技术问题，而是技术生态的切换问题。数据库的分布式带来的不仅仅是数据库系统的重构，还有应用系统的重构。分布式数据库普遍不支持存储过程，SQL执行效率低，这些问题通常只能在应用端解决。与传统数据库相比，分布式数据库的开发和运维的技术要求会更高。民生银行技术总监曾表示，在分布式改造过程中，开发智能运维平台非常重要。因此，在使用分布式数据库之前，需要在资金、环境改造、人员技能、管理自动化、技术储备等方面进行统筹规划，做好充分准备。2、分布式改造将降低TCO分布式数据库有两条技术路线：开源数据库+分布式中间件，原生分布式数据库。由于开发分布式数据库产品的公司大多是互联网和创业公司，所以一般都使用MySQL。因此，很多人认为部署分布式数据库会降低软件采购成本。X86将取代RISC，硬件单价将大幅降低，所以TCO会下降。但现实中可能并非如此。比如本文开头的案例就是一个例子。当然，这个案例有点极端，我再举个例子。某国家银行的信用卡系统，原来的数据库系统由4台小型机组成。分布式改造后，需要120台数据库服务器。软硬件采购成本降低50%，但运维人员增加66%，开发人员数量增加。5倍，计算5年的总拥有成本，比原来增加了60%以上。节省下来的采购成本无法覆盖后期增加的运维和开发成本。从这个案例来看，分布式改造只是降低了初始采购成本（TCA），而总拥有成本（TCO）并没有降低。3、盲目复制互联网模式，不挖掘现有系统的潜力。有句话叫“技术跟随商业”。IT架构的演进升级需要与企业的业务转型同步。落后会制约企业发展，激进则会造成投资浪费，甚至给企业带来风险。与传统企业和互联网公司的业务相比，有着根本的区别。互联网企业具有三大显着特征，即用户数量庞大、用户访问和交易频率高、业务创新频率高，例如抖音、快手、今日头条，可以在一个周期内培养数千万用户。年。每个用户每天登录多次。因此，IT基础架构必须以可扩展性和灵活性为第一追求。传统企业核心业务相对稳定，用户数量有限，交易频率不高，开发人员少，IT支出小。业务对IT的需求与互联网公司有着根本的不同。难以承担分布式改造带来的经济成本和技术风险，通常只能依赖第三方提供的整体解决方案和服务。因此，对于这类企业来说，传统的集中式数据库仍然是最好的选择。例如本文开头的案例，要提高数据库系统的性能，只需要将硬件平台从2路、4路服务器升级到8路、16路等大型服务器即可。套接字服务器，可以覆盖大部分业务需求。成本可能不会比直配高，甚至可能更低。目前国产服务器和小型机种类齐全，价格也很透明。如果这样还不行，来个RAC集群，国内很多关系型数据库也有RAC集群扩展方案。写在最后一般来说，使用什么数据库完全取决于业务需求。企业用数据库做什么？分析还是交易？或两者？业务需要处理什么样的数据？对数据库的性能要求是什么？如果传统ERP、CRM、财务等与“钱”相关的核心业务系统要求交易完整性，保证ACID交易，那么毫无疑问，传统的中心化关系型数据库是最好的选择。业务需要处理什么样的数据？结构化的？半结构化？非结构化数据？确定需要支持的数据模型。原则上，“用什么数据模型，用什么库”。如果要存储和处理图片、音频、视频等非结构化数据，那么NoSQL数据库将是最佳选择。再者，业务需要存储游戏场景中的角色信息、经验值信息、好友排行等信息，而这些信息一般都与ID（key）挂钩，所以key-value数据库是一个不错的选择。业务需要处理的数据规模、并发吞吐量和响应时间要求是多少？确定数据库的性能要求。如果业务是秒杀、春运火车票等，超高峰值、高并发的业务，那么分布式数据库会是一个不错的选择。综上所述，虽然关于架构和数据库选型的讨论一直存在，但其核心，必须明确一点：“业务需求引领技术创新”，理性分析和对待架构和分布式数据库的选型，选择最合适的架构而针对业务场景的数据库才是王道。
