图片来自Unsplash
最近,老宇听说了一个案例!
一家银行计划部署分布式数据库,以取代其业务核心的集中式数据库。它计划先在特定的核心业务中试点项目,然后根据试点情况决定大项目是否会变大。应继续执行创建的项目。
飞行员的核心业务使用“ O”数据库,3节点RAC,3台小型计算机,2台用于业务系统,以及1台用于同一城市中的灾难恢复中心进行远程数据备份。交换之后,该数据库是具有600多个x86服务器的分布式数据库。
目前正在部署试验服务,与替代产品相比,峰值功率(TPS)增加了50%,平均功率(TPS)增加了33.3%,平均交易响应时间未知。
最后,该银行决定不继续执行,而是保持现状。
在这一点上,我相信每个人都能看到一些东西。
3节点RAC可以做什么?为什么需要那么多X86?
没错,即使不同银行的核心业务复杂度不同,即使更换后性能提高了50%,但是!但!但!最重要的事情说了三遍,老俞问了许多专家之后,每个人的观点都是完全一样的,他们认为不需要那么多机器,真是烧钱!虽然钱还不错,但是应该考虑到开发,运营和维护团队,这极大地增加了他们未来工作的工作量和复杂性。
如果网络延迟是由分布式事务引起的,因此需要更多服务器,则只能表明分布式数据库体系结构的设计不令人满意。平均事务响应时间是未知的。这将在应用程序级别实现吗?上面的网络延迟已被删除。
该项目的5年总拥有成本不难计算,可以肯定的是投资将超过1亿美元;第四至第五年的硬件成本(服务器,交换机等),软件成本(操作系统,数据库许可)包括维护成本很容易计算。
但是,有些成本很容易被忽略,即运营和维护成本,可能占总采购成本的20%至30%。分布式数据库的运行和维护是一个问题,分布式转换后的运营,维护和开发工作量必然会急剧增加。
从操作和维护的角度来看,假设3台小型计算机只需要2个操作和维护,硬件的大量增加,则现在必须将600多个X86单元所需的操作和维护加倍,甚至增加甚至更多。假设一个操作和维护的平均年薪为200,000,即5年100万,如果增加3,则为300万。其次,机器的大量增加不可避免地导致电力,散热和使用计算机室的成本增加。
从开发的角度来看,体系结构中的更改很少不会更改应用程序,甚至有可能完全重新设计应用程序。
因此,就性能或成本而言,这种情况并不具有成本效益。
尽管这种情况有些极端,但它确实反映了市场中实际存在的一些潜在问题或误解,值得我们进行深入讨论。
近年来,分布式数据库已成为一种趋势,在各种灵光的祝福下,就像黑暗中的灯塔一样,不可避免地会有过多的神话。
不同的供应商不仅会主动和被动地发布自己的分布式数据库产品,而且市场正在相互竞争。许多传统公司也在尝试分布式数据库。随着时间的推移,大多数分布式数据库都将被删除,并且在不使用时,分布式数据库显得特别低。
在测试水的公司中,有成功的公司,有的失败了,并且由于分布式数据库没有统一的行业标准,因此每个公司都有自己的见解。
老俞认为,没有通用数据库,只有最合适的数据库。分布式数据库虽然不错,但不是万能的“银弹”。它被分解为多个场景,并具有自身的缺点。为了确定当前分布式数据库的最适用方案,我们需要从分布式数据库的历史背景及其流行的原因入手。
故事背景分布式数据库存在于数据库历史的早期.1970年开始研究.1979年,美国计算机公司(CCA)在DEC计算机上实现了世界上第一个分布式数据库系统SDD-1。
但是,分布式数据库只是在最近几年才被注意到,并且有很多原因。
在Internet诞生之前,公司数据并不大。用“ O”表示的传统数据库足以满足大多数数据管理的需求。因此,分布式数据库毫无用处。这有两个原因。首先,在此期间市场上没有任何好的分布式数据库产品;其次,分布式数据库本身不可避免地存在一些缺陷。
但是,随着Internet时代的到来,随着数据量的不断增加和在线用户数量的增加,传统的数据库无法支持业务发展。结果,以互联网行业为首的公司开始寻找有效的寻求解决方案。
NoSQL是最早开发的,NoSQL牺牲了一些关系数据库的限制,例如:B.强大的计算一致性和可扩展性。之后,NewSQL诞生了,它定义了一种具有可伸缩性和传统关系数据库属性的新型数据库。最典型的代表是基于Google Spanner / F1论文。
在此过程中,常规数据库也可以执行自救操作,最常用的方法是子数据库子表,但是此解决方案需要对应用系统进行全面改造,必须识别数据存储位置并增加操作和维护的复杂性。
因此,分布式数据库有两种技术方法:开源数据库+分布式中间件解决方案(例如MyCat),优点是可以使用现有开源数据库的成熟且稳定的产品功能,缺点是中间件只是一种类型。绕行受到独立数据库功能的限制。
另一个技术路线是本机分布式数据库,它是固有分布式的,从设计之初就针对分布式体系结构而设计,缺点是需要提高产品成熟度,并需要运行不同的场景和不同的数据规模通过并检查,改进和完善不同行业中的应用程序。
当前,人们普遍达成共识,除非存在高度的并行性,否则如果没有高水平的并行性,数据量将无法达到一定规模,不会出现超高峰值,也不需要使用分布式数据库,因为很可能不仅无法实现明显的收益,而且可以实现集中的独立牺牲,可伸缩性以及易于开发,操作和维护。
实际上,如果仅要实现局部替换,那么一些本地生产的关系数据库也可以满足需要,并且不需要直接访问分布式数据库。
通常,分布式数据库的优点是可伸缩性好,可以将数据存储在多个节点中,可以实现水平扩展,并且可以并行运行多个节点,从而提高了整体吞吐量。
缺点是分布式事务处理的成本很高,这主要是由于两阶段传递导致消息传递过多所致,潜在的锁争用增加,多个副本的复制和高可用性增加。其次,需要提高产品的成熟度,并且操作和维护复杂。
常见错误
1.分布式转换只是一个技术问题
从传统的集中式架构到分布式架构的过渡不是一个简单的技术问题,而是一个技术生态变化的问题。分布式数据库不仅带来了数据库系统的重构,而且带来了应用系统的重构。分布式数据库通常不支持存储过程,SQL执行效率很低,这些问题通常只能在应用程序端解决。
与传统数据库相比,分布式数据库的开发,运行和维护的技术要求更高。民生银行技术总监曾表示,在分布式改造中开发智能运维平台非常重要。
因此,在访问分布式数据库之前,您需要创建一个总体计划,并在资源,环境转换,人员技能,管理自动化和技术储备方面进行充分准备。2.分布式转换降低总体拥有成本分布式数据库有两条技术路线:开源数据库+分布式中间件和本机分布式数据库。由于大多数开发分布式数据库产品的公司都是互联网,初创公司等,因此他们通常将它们用作MySQL的主体。因此,许多人认为部署分布式数据库将减少软件采购成本并取代X86 RISC并显着降低单位硬件价格,因此总拥有成本将降低。但是,实际情况可能并非如此。
例如,本文开头的案例就是一个例子,当然这个案例有点极端,让我再举一个例子。
在某国家银行的信用卡系统中,原来的数据库系统由4台微型计算机组成,分布式改造后需要120个数据库服务器,软件和硬件的购买成本降低了50%,但运维人员却减少了降低了66%,开发人员减少了5倍,则5年的总拥有成本比原始成本高出60%以上。节省的购置成本无法弥补后期增加的运营,维护和开发成本。
在这种情况下,分布式转换仅降低了TCA的初始购置成本,而总拥有成本TCO却没有降低。
3.不要检查现有系统的潜力,而盲目复制Internet模型
俗话说“技术跟随商业”。IT体系结构的开发和更新必须与公司业务的转型保持同步。落后限制了业务发展,激进主义导致投资浪费甚至业务风险。
传统企业和互联网公司的业务根本不同。互联网业务具有三大显着特征,即大量用户,高频率的用户访问和交易以及斗隐,快手和头条等公司的高频率创新,您每年可以发展成千万的用户。用户每天登录并使用多次,因此IT基础结构必须首先具有可伸缩性和灵活性。
传统公司的核心业务相对稳定,用户数量有限,交易频率不高,开发人员数量少,IT支出低,IT的业务需求与Internet的业务需求有根本的不同公司。难以承受分布式转型的经济成本和技术风险,通常只能影响第三方的整体解决方案和服务,因此,传统的集中式数据库仍然是此类业务的最佳选择。
例如,在本文开头的情况下,提高数据库系统性能所需要做的就是将硬件平台从两路和四路服务器升级到大型服务器(例如八路服务器)。以及可以满足大多数业务需求的16路服务器成本不一定比直接分发成本高,甚至可以更低。当前,家用服务器和小型计算机种类齐全,价格非常透明。如果这还不够,请联系RAC集群。许多国内关系数据库也具有RAC集群扩展器解决方案。
最后写
通常,要使用的数据库完全取决于业务需求。公司将数据库用于什么目的?分析还是交易?或两者?业务流程处理什么样的数据?对数据库性能有哪些要求?
当与“金钱”相关的传统ERP,CRM,财务和其他核心业务系统需要交易完整性和ACID交易时,传统的集中式关系数据库无疑是最佳选择。
业务流程处理什么样的数据?结构化的?半结构化?非结构化数据?确定应支持的数据模型。原则上,“无论数据模型如何,都使用库”。
如果要存储和处理图像,音频和视频等非结构化数据,则NoSQL数据库是您的最佳选择。另外,公司需要在游戏场景中存储角色信息,体验信息,朋友排名等信息,该信息通常与ID(密钥)相关联,因此密钥值数据库是一个不错的选择。
公司必须处理什么数据规模,并发吞吐量和响应时间要求?确定数据库的性能要求。
当涉及高峰,春节火车票等时,有些服务具有极高的高峰和并行度,因此分布式数据库是一个不错的选择。总而言之,可以说一直存在关于体系结构和数据库选择的讨论,但是在核心方面必须明确:“业务需求支配技术创新”,对体系结构和分布式数据库选择的合理分析和处理。方法是为业务场景选择最合适的体系结构和数据库。