背景
一直以来,大一统还是碎片化,是数据库发展趋势的两种最主流预测。随着数字化进程的推进,单一场景无法满足应用多样化的需求,数据库碎片化已呈不可逆的趋势。在当前,市场占有率最高的商用数据库——Oracle并没有明显短板的情况下,各种全新的数据库依旧如雨后春笋般层出不穷。如今,DB-Engines上已有超过余种数据库参与排名。
应用场景的不断扩张,加速了数据库碎片化的进程,数据库的架构、协议、功能、适用场景也愈加多样化。在数据库架构方面,基于单机系统演进而来的集中式数据库与原生面向分布式的新一代数据库并存;在数据库协议方面,MySQL和PosrtgreSQL这两大主要开源生态以及周边厂商所提供的服务生态也在全球数据库体系中各自占有一席之地;每种数据库的独特功能和适用场景,也在相关的领域大放异彩。
在企业的应用现状中,数据库的多元并存已是常态。在互联网行业中,以MySQL+数据分片中间件作为核心业务存储的架构模式为主,以GreenPlum、HBase、Elasticsearch、Clickhouse等其他大数据生态作为分析型数据的计算引擎为辅助。与此同时,一些遗留系统(如:通过.NET转型时遗留的SQLServer、或通过外采而遗留的Oracle)的数据库仍在运行;在金融行业中,核心交易系统仍然大量使用Oracle或DB2,新业务向MySQL或PostgreSQL迁移,部分业务则逐渐尝试使用自主研发的数据库。除了交易型数据库,分析型数据库的种类则更加繁多。
因此,碎片化是数据库领域的大势所趋,单一品类的数据库无法适用于所有场景,只能适用于某一种或某几种擅长的场景。
数据库碎片化带来的问题
随着企业采用的数据库种类不断增加,各种问题和痛点也随之出现。
1.架构选型困难
当应用架构为了适应更加灵活多变的业务需求,将架构设计从单体式向服务化再到微服务进行转化之后,用于存储业务核心数据的数据库则成为分布式系统的下一个焦点。
相对比无状态的应用,具有状态的数据库的设计难度则有过之而无不及。分而治之是分布式系统的最佳实践,显然,数据库体系也不能简单的用单一产品以及一体化集群来响应所有的服务请求。
首先,单一品类的数据库无法满足业务应用的全部需求,在高吞吐量、低延时、分布式无感知、强一致性、运维友好度甚至稳定性等方面难以做到面面俱到。一个应用需要多种数据库共存的可能性尚且不高,但多个应用混用多种数据库的可能性则大大提升。
其次,无论是单机数据库,还是AllinOne的分布式数据库集群,都难以成为众多微服务应用后端的唯一存储支撑。单机数据库无法承载越来越大的数据量和访问量,所以越来越多的应用选择采用分布式解决方案。然而,多应用使用统一的数据库集群,在CPU、内存、磁盘、网络等方面的负载无法做到完全隔离。一个应用的超额资源使用,可能会导致众多毫不相干的应用服务质量下降。
如今,大部分分布式数据库的搭建成本相当高,在计算节点、存储节点和治理节点都需要备份和冗余的独立服务器。如果要为每一个微服务都搭建一套独立的分布式数据库,一定会造成非必要的资源消耗,最终导致企业无法承受。
最后,大量企业采用单元化架构。基于数据分片的解决方案,将数据库的拆分和单元化一并放到应用端解决。随着数据库数量的增多,架构设计的复杂度会呈指数级增长。长此以往,业务开发团队将无法把精力集中在最擅长的业务研发层面,反而需要花费大量精力投入到基础组件的维护。尽管ApacheShardingSphere的数据分片功能可以较好解决相关问题,但面对更多元的数据库,仅支持单一品类数据库的水平分片能力是远远不够的。
2.技术挑战众多
当碎片化数据库共存成为常态时,研发人员的学习与开发成本将不可避免的持续增长。尽管数据库大多支持SQL的操作方式,但各数据库间仍有大量SQL方言的差异。除此之外,各数据库间驱动程序的使用方式也或多或少存在不同。
因此如需精细化使用每一种数据库,必定会占用研发工程师大量的精力,且沉淀下来的知识和经验不易传承;如果采用粗粒度的标准模式统一使用异构数据库,将会湮没数据库自身的特点,而无法发挥其应有的作用。
3.运维复杂度高
掌握各种数据库特征,并结合实际场景制定行之有效的运维规范,需要大量时间和实践经验的积累。除了最基本的运维工作,数据库周边配套工具的差异性也非常大。通过周边配套工具所组成的监控、备份及其他自动化运维等工作,随着数据库种类的增加将会产生巨大的运维成本。
4.数据库间缺乏协作和统管能力
站在数据库的角度,其首要目标是完善自身的能力,而非面向其他数据库的在线协作能力。跨越异构数据库的关联查询、分布式事务等功能,是无法在数据库本身实现的。
与相对标准的SQL不同,数据库自身的协议和周边生态工具缺乏统一的标准。对异构数据库的统一管控能力也受到越来越多的