精华内容
下载资源
问答
  • 什么是云原生数据库
    万次阅读 多人点赞
    2021-07-07 10:35:10

    写在前面

    本文隶属于专栏《100个问题搞定大数据理论体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!

    本专栏目录结构和参考文献请见100个问题搞定大数据理论体系

    解答

    云原生数据库即「Cloud-Native Database Systems」。

    在传统数据库的系统架构下,必须是紧耦合的设计方式,才能最大效能地发挥系统的优势。传统扩容过程非常漫长,而业务高峰过后缩容也很痛苦,往往会造成极大的资源浪费,也很难应对业务层需要的快速变化能力,这是传统架构非常大的弊端之一。

    「云」就是使用虚拟化的技术将资源池化。水是资源,不用紧耦合的方式来部署和使用。资源池化以后可以做到按需按量使用,弹性调度,甚至还可以将资源进行解耦。这就是云原生核心逻辑,将不同类型资源解耦,并进行池化。具体的,比如在云原生的计算存储分离架构下,业务节点可以根据需要自由地对计算、存储进行快速的扩缩容等操作。

    云原生带来的本质性变化就像水井和池塘,随着池塘不断变大,越来越多应用迁移上云,池塘不再是池塘,而变成了江河大海。云原生带来的最大技术红利以及经济红利就是规模化应用后带来边际成本下降效应,因此向云原生技术演进的趋势自然发生并且非常清晰,无论用公共云还是专有云私有化部署。这个边际成本下降效应体现在产品上,客户就会因此受益,TCO也一定会下降。

    TCO (Total Cost of Ownership ),即总拥有成本,包括产品采购到后期使用、维护的成本。这是一种公司经常采用的技术评价标准。

    数据库的未来:云原生+分布式

    全球知名咨询公司Gartner指出,云将主导数据库市场的未来,到2022年,75%的数据库将被部署或迁移至云平台,只有25%的数据库会在本地运行。云化无疑代表了未来,企业如何在云原生架构下使用数据库,就成为必须要思考的问题的。

    随着企业业务全面向数字化、在线化、智能化演进,企业面临着呈指数级递增的海量存储需求和挑战,业务有更多的热点和突发流量带来的挑战,企业需要降本增效,进行更智能的数据决策,传统的商业数据库已经难以满足和响应快速增长的业务诉求。

    在架构创新上,我们将云原生与分布式结合起来,全新的云原生分布式架构的数据库具备了高扩展性、易用性、迭代快速、成本降低等特点,可以很好的帮助企业解决上述问题。未来数据库也将全面进入云原生加分布式的时代。具体来讲:

    1. 高扩展性

    云原生分布式数据库与底层的云计算基础设施分离,所以能够灵活及时调动资源进行扩容缩容,以从容应对流量激增带来的压力,以及流量低谷期因资源过剩造成的浪费。生态兼容的特点,也让云原生数据库具备很强的可迁移性。

    2. 易用性

    云原生分布式数据库非常易于使用,它的计算节点在云端部署,可以随时随地从多前端访问。因其集群部署在云上,通过自动化的容灾与高可用能力,单点失败对服务的影响非常小。当需要升级或更换服务时,还可以对节点进行不中断服务的轮转升级。

    3 快速迭代

    云原生分布式数据库中的各项服务之间相互独立,个别服务的更新不会对其他部分产生影响。此外,云原生的研发测试和运维工具高度自动化,也就可以实现更加敏捷的更新与迭代。

    4 节约成本

    建立数据中心是一项独立而完备的工程,需要大量的硬件投资以及管理和维护数据中心的专业运维人员。此外,持续运维会造成很大的财务压力。云原生分布式数据库以较低的前期成本,获得一个可扩展的数据库,实现更优化的资源分配。

    更多相关内容
  • 云原生数据库介绍

    千次阅读 2022-01-22 22:46:29
    文章目录数据库系统发展行业趋势:云原生+分布式云原生概念数据库在云原生时代面临的挑战云原生数据库具有的主要技术特点1. 分层架构2. 资源解耦与池化3. 弹性伸缩能力4. 高可用与数据一致性5. 多租户与资源隔离6. ...

    数据库系统发展

    冯·诺依曼体系中有最核心的两个要素:计算和存储,它们构成了冯·诺依曼架构的基石,可能还要加上第三个要素——计算和存储之间的通信。在单机部署情况下,通信就是计算和 Memory Bus、IOBUS。但在集群部署的情况下,计算和存储的通信就是网络,这是经典计算机架构。

    传统的数据库系统都是基于上述经典的传统架构来设计的,但这里出现了一个问题,传统数据库系统因系统架构方式, 必须是紧耦合的设计方式 ,才能最大效能地发挥系统的优势。传统扩容过程非常漫长,而业务高峰过后缩容也很痛苦,往往会造成极大的资源浪费,也很难应对业务层需要的快速变化能力,这是传统架构非常大的弊端之一。

    随着云原生的到来,无须使用紧耦合的方式来部署和使用资源,客户不需要自己配置管理硬件资源,而是由云提供统一的资源管理,客户只需要按需申请使用资源,这就是资源池化。在资源池化之后,可以按需按量使用、弹性调度资源。也可以将资源进行解耦。

    时下,业界在计算存储分离方面,是将 CPU 和 Memory 绑在一起,和 SSD 持久化存储分开。随着 NVM 非易失技术的成熟,下一步甚至会将 CPU 和内存再进行隔离,内存再进行池化,形成三层池化,进一步隔离、弹性,更好地帮助客户实现按需按量使用资源。

    行业趋势:云原生+分布式

    全球知名咨询公司Gartner指出,云将主导数据库市场的未来,到2022年,75%的数据库将被部署或迁移至云平台,只有25%的数据库会在本地运行。云化无疑代表了未来,企业如何在云原生架构下使用数据库,就成为必须要思考的问题的。

    随着企业业务全面向数字化、在线化、智能化演进,企业面临着呈指数级递增的海量存储需求和挑战,业务有更多的热点和突发流量带来的挑战,企业需要降本增效,进行更智能的数据决策,传统的商业数据库已经难以满足和响应快速增长的业务诉求。

    在架构创新上,将云原生与分布式结合起来,全新的云原生分布式架构的数据库具备了高扩展性、易用性、迭代快速、成本降低等特点,可以很好的帮助企业解决上述问题。未来数据库也将全面进入云原生加分布式的时代。具体来讲:

    1 高扩展性

    云原生分布式数据库与底层的云计算基础设施分离,所以能够灵活及时调动资源进行扩容缩容,以从容应对流量激增带来的压力,以及流量低谷期因资源过剩造成的浪费。生态兼容的特点,也让云原生数据库具备很强的可迁移性。

    2 易用性

    云原生分布式数据库非常易于使用,它的计算节点在云端部署,可以随时随地从多前端访问。因其集群部署在云上,通过自动化的容灾与高可用能力,单点失败对服务的影响非常小。当需要升级或更换服务时,还可以对节点进行不中断服务的轮转升级。

    3 快速迭代

    云原生分布式数据库中的各项服务之间相互独立,个别服务的更新不会对其他部分产生影响。此外,云原生的研发测试和运维工具高度自动化,也就可以实现更加敏捷的更新与迭代。

    4 节约成本

    建立数据中心是一项独立而完备的工程,需要大量的硬件投资以及管理和维护数据中心的专业运维人员。此外,持续运维会造成很大的财务压力。云原生分布式数据库以较低的前期成本,获得一个可扩展的数据库,实现更优化的资源分配。

    云原生概念

    云原生的概念最早由Pivotal公司在2014年提出,并在2015 年组织成立了云原生计算基金会。

    关于云原生,至今并没有明确的定义。云原生是云计算时代新的团队文化、新的技术架构和新的工程方式。

    云原生指的是一个灵活的工程团队,遵循敏捷的研发原则,使用高度自动化的研发工具,开发专门基于并部署在云基础设施上的应用,以满足快速变化的客户需求。这些应用采用自动化的、可扩展的和高可用的架构。工程团队通过高效的云计算平台的运维来提供应用服务,并且根据线上反馈对服务进行不断的改进。

    对应数据库领域,云原生的数据库服务应该包括基于云基础设施构建的数据库管理系统、高度灵活的数据库DevOps(Software Development and IT Operations)团队,以及与之配套的云原生生态工具。

    从用户视角来看,云原生的数据库服务应该具备“计算存储分离”、“极致弹性”、“高可用”、“高安全”、“高性能”等核心能力;数据库服务具备智能化的自省能力,具体包括自感知、自诊断、自优化和自恢复等;借助云原生生态工具,能够实现数据的高安全、可监控和可流动;有一支遵循DevOps 规约的数据库技术团队实现数据库服务的快速迭代与功能演进。

    数据库在云原生时代面临的挑战

    传统数据库架构依赖于高端硬件,每套数据库系统服务器少、架构相对简单,且无法支持新业务的扩展需求。

    云原生数据库采用分布式数据库架构,可实现大规模扩展,由于每套数据库系统横跨多台服务器和虚拟机,因此带来了全新的系统管理挑战。

    其中,最核心的挑战就是如何实现弹性及高可用,即实现按需按量使用,让资源高效利用。

    更重要的是,虽然传统的大数据处理牺牲部分ACID换来的分布式水平拓展满足了很多场景中的需求,但是应用对ACID的需求一直存在,即使是在分布式并行计算的场景中,应用对ACID的需求也变得越来越强。

    因此,云数据库在分布式事务的协调、分布式查询的优化和强ACID特性的保证等方面,具有非常大的挑战。

    除此之外,云原生数据库面临的其他挑战有:

    • 多服务器安装部署、自动化扩容带来的运维挑战。
    • 复杂云环境下的实时监控、节点故障和性能问题的安全审计挑战。
    • 多种数据库系统与其业务系统的管理挑战。
    • 海量数据数据迁移的挑战。

    云原生数据库具有的主要技术特点

    1. 分层架构

    云原生数据库在架构设计上最显著的特点,即将原本一体运行的数据库拆解为计算服务层、存储服务层和共享存储层。

    其中,计算服务层负责解析SQL请求,并转化为物理执行计划。存储服务层负责数据缓存管理与事务处理,保证数据的更新和读取符合事务的ACID语义,在实现中不一定是物理分离的,可能一部分集成在计算服务层,一部分集成在共享存储层。共享存储层负责数据的持久化存储,利用分布式一致性协议保证数据的一致性与可靠性。

    2. 资源解耦与池化

    在云原生时代,云基础设施通过虚拟化的技术实现资源池化。基于分层架构,云原生数据库可以有效地将计算和存储资源解耦,从而分别扩展。因此在资源池化之后,云原生数据库可以按需按量使用、弹性调度资源。

    在资源解耦进展上,目前业界是将CPU和内存绑在一起,和SSD持久化存储分开。但随着非易失存储技术和RDMA技术的成熟,下一步甚至会将CPU和内存进行隔离,内存再进行池化,形成三层池化,更好地帮助客户实现按需按量使用资源。

    3. 弹性伸缩能力

    传统的中间件分库分表的方案和企业级的透明分布式数据库都会面临一个挑战:在分布式架构下,数据只能按照一个逻辑进行分片(Sharding)和分区(Partition),业务逻辑和分库逻辑不是完美一致的,一定会产生跨库事务和跨分片处理,每当ACID要求较高时,分布式架构会带来较高的系统性能挑战。例如在高隔离级别下,如果分布式事务占比超过整个事务的5%,那么系统吞吐量会有明显的损耗。

    完美的分库策略是不存在的,这是分布式业务需要解决的核心挑战,同时需要保证在这个架构数据的高一致性。

    云原生的架构,在本质上,下层是分布式共享存储,上层是分布式共享计算池,中间层用于计算存储解耦,这样可以非常好地提供弹性高可用能力,做到分布式技术集中式部署,从而对应用透明。

    4. 高可用与数据一致性

    分布式系统的多个节点通过消息传递进行通信和协调,其不可避免地会出现节点故障、通信异常和网络分区等问题。采用一致性协议可以保证在可能发生上述异常的分布式系统中的多个节点就某个值达成一致。

    在分布式领域中,CAP理论认为任何基于网络的数据共享系统最多只能满足一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)三个特性中的两个。

    其中,一致性指更新操作完成后,各个节点可以同时看到数据的最新版本,各节点的数据完全一致;可用性指在集群的部分节点发生故障时,系统可以在正常响应时间内对外提供服务;分区容忍性指在遇到节点故障或网络分区时,系统能够保证服务的一致性和可用性。

    由于是分布式系统,网络分区一定会发生,天然地需要满足分区容忍性,因此需要在一致性和可用性之间做出权衡。

    在实际应用中,云原生数据库通常采用异步多副本复制的方式,例如Paxos、Raft等一致性协议,保证系统的可用性和最终一致性,以牺牲强一致性的代价换取系统可用性的提升。

    在线上使用时,云原生数据库会提供不同的高可用策略。

    高可用策略是根据用户自身业务的特点,采用服务优先级和数据复制方式之间的不同组合,组合出适合自身业务特点的高可用策略。

    服务优先级有以下两种策略,可以方便用户在可用性和一致性之间做出权衡。

    • RTO(Recovery Time Objective)优先:数据库应该尽快恢复服务,即可用时间最长。对于数据库在线时间要求比较高的用户,应该使用RTO优先策略。
    • RPO(Recovery Point Objective)优先:数据库应该尽可能保障数据的可靠性,即数据丢失量最少。对于数据一致性要求比较高的用户,应该使用RPO优先策略。

    5. 多租户与资源隔离

    多租户指一套系统能够支撑多个租户。一个租户通常是具有相似的访问模式和权限的一组用户,典型的租户是同一个组织或者公司的若干用户。

    要实现多租户,首先需要考虑的是数据层面的多租户。数据库层的多租户模型对上层服务和应用的多租户实现有突出影响。

    多租户通常有某种形式的资源共享,需要避免某个租户的业务“吃掉”系统资源,影响其他租户业务的响应时间。

    一般实现多租户会采用一租户一数据库系统,或者多租户共享同一个数据库系统,通过命名空间等方式隔离,但是这种模式运维和管理比较复杂。在云原生场景下,数据库可以为不同的租户绑定相应的计算和存储节点以实现资源的隔离和面向不同租户的资源调度。

    6. 智能化运维

    智能化运维技术是云原生数据库的重要特性。云原生数据库一般通过简易的操作界面和自动化流程帮助用户快速完成常见的运维任务,并可以在多数任务下执行自动化操作:

    • 支持自定义备份策略,通过复制实例恢复到任意时间点,找回误删数据。
    • 自动在线热升级,及时修复已知Bug。
    • 资源和引擎双重监控,链接云监控自定义报警策略。
    • 节点故障秒级探测,分钟级切换。
    • 提供专家级自助式服务,可解决大部分场景的性能问题。

    云原生数据库的未来

    这里我们借用Amazon云科技数据库、数据分析、机器学习副总裁Swami Sivasubramanian (2007年 Dynamo 论文的合著作者之一,且是 Amazon DynamoDB 开发的主要贡献者 )的一段话:

    “现在,我们生活在这样一个世界中,就客户如何 IT 应用程序而言,云是新常态,而规模也是新常态,每个应用程序都要基于不确定性构建。云原生数据库本身将在这个持续的旅程中,根据用户需求继续进行创新。我们将继续朝着端到端的现代化数据战略使命迈进。正如我之前提到的,“没有数据库是孤岛”。

    客户不再只想在他们的数据库中存储和查询数据。然后,他们想要分析这些数据以创造价值,无论是更好的个性化或推荐引擎,还是可以使用机器学习运行预测分析的预测系统。

    将点对点连接起来,并继续使数据库更安全、更可用、更高性能和更易于使用,这将是我们永无止境的旅程。”

    展开全文
  • 云原生数据库可以说是当下最火的产品技术形态之一。火到什么程度?很多为了云而云的数据库产品也号称自己是云原生的。 概念大火的同时也让许多门外人打出了一串问号: 云原生数据库到底是怎么一回事儿? 它怎么就...

    微信图片_20200915094148.gif

    微信图片_20200921091138.png

    云原生数据库可以说是当下最火的产品技术形态之一。火到什么程度?很多为了云而云的数据库产品也号称自己是云原生的。

    概念大火的同时也让许多门外人打出了一串问号:

    云原生数据库到底是怎么一回事儿?
    它怎么就云了、怎么就原生了?
    什么是云原生?
    云原生数据库又有什么用?

    所有的疑惑汇成一句:“你说的这个云原生数据库……它厉害么?”

    先说小偶的结论:**云原生数据库厉害,而且很厉害。**那么它究竟厉害在哪儿呢,咱们还得先从云原生说起。
     

    到底什么是云原生?

    微信图片_20200921091149.png

    直到今天,关于云原生的定义仍然没有一个确切和统一的说法。

    云原生这一概念的提出者** Matt Stine 于2017年将云原生归纳为模块化、可观察、可部署、可测试、可替换、可处理**6特质。

    而云原生领域影响力最大最有话语权的组织CNCF,他们给出的定义则是这样的:

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API

    这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

    CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”


    CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”

    概念众说纷纭,而且又都使用了大量的技术名词去描述,难免让人看的一头雾水,不得要领。我们可以试着从字面意思来解读,以此揭开一些云原生的面纱。

    云原生中的“云”表示存在于云中,而不是传统的部署于本地。比如云盘中的文件就在云中,而不是存储在用户电脑的硬盘中。“原生”则代表着应用从设计环节便考虑到云环境的因素,为云而设计,在云上运行。

    也就是说云原生是生在云上,长在云上,也应用于云上,这么一个足以称之为“根正苗红”的技术。

    微信图片_20200921091200.jpg

    了解了云原生,接下来让我们看看云原生数据库拥有怎样的神通,它因何而火?

     

    云原生数据库应该长什么样?

    云原生技术对于数据库产品的意义之一,便是它有利于构建和运行可弹性扩展的应用。也就是说,云原生数据库具备更好的弹性扩展能力。因为云原生数据库拥有以下这些特征。

    首先是普遍可访问高可用性。因为云原生数据库是完全存在于云上的,所以它可以随时随地的从多前端访问,提供云服务的计算节点。因其集群部署在云上,所以单点失败对服务的影响特别小。而且当需要升级或更换服务的时候,可以对节点进行不中断服务的逐渐升级。

    微信图片_20200921091208.jpg

    其次是高扩展性可迁移性。云原生数据库会与底层的云计算基础设施分离,所以能够灵活及时的调动资源进行扩容和缩容,以从容应对流量激增可能带来的压力,以及流量低谷期因资源过剩造成的浪费。也正是因为能够灵活扩缩容,云原生数据库也具备很强的可迁移性,我们甚至可以粗暴的理解为在新的位置扩容100%又在旧的位置缩容全部的50%。

    此外,基于高扩展性、高可用性以及可迁移性等特征,云原生数据库还具备可监控性安全性的特征。

    微信图片_20200921091212.jpg

    一方面黑箱状态下无法保证及时处理扩容、节点故障等需求和问题;另一方面全盘部署在云上且各服务之间相互独立,可以对应用或服务提供更多层的安全防护和实现许多新的容错服务。

    最后是演进式设计快速迭代。云原生数据库中的各项服务之间是相互独立的,个别服务的更新并不会对其他部分产生不利影响,而不是一旦出了问题就只能全场熄火。此外,云原生的研发测试和运维工具是高度自动化的,这使得应用的更新会更加快速频繁。

    将网络资源和云更好的融合在一起,处处独立而又自然联系着,才能更充分的发挥数据库上云的优势,得到更高的效率。

     

    怎样才算一个好的云原生数据库?

    如果一款数据库产品具备了存储和计算的完全分离以及执行引擎的完全弹性这两点,那么它就能称得上真正发挥了上云的优势,就可以将数据和云更好地融合在一起,就可以说自己做好了云原生。

    微信图片_20200921091217.png

    拿小偶家的核心产品OushuDB来说,作为可以原生运行在云平台中的并行数据仓库引擎,它就做到了存储和计算的完全分离

    存储和计算的完全分离真正实现了不把所有的鸡蛋放在一个篮子里,而不是像一些仅仅声称自己是云原生的数据库产品,实质上是把两个篮子绑在一块或者在篮子中插了一块隔板而已。

    实现存储和计算的完全分离,不仅能使数据库产品在安全性上有巨大提升,而且还是实现产品执行引擎完全弹性的重要基础之一

    由于OushuDB的执行引擎具备完全弹性,所以它可以很容易很方便的做动态的缩容和扩容,无论是存储节点还是计算节点需要增加就可以马上增加需要减少就可以马上减少,可以动态的把计算派遣到数据所在的位置。

    这就让产品的性能和功效真正成为了完美的革命一块砖,哪里需要哪里搬。而且是需要多少就可以搬多少,不需要那么多的时候还可以把多余的砖头收回去,不需要找个地儿堆着。避免了小马拉大车或者高射炮打蚊子这种尴尬情况的发生。

    也正是因为具备了这两个特点,OushuDB才算得上是原生运行在容器云平台里的一个分布式数据库

    微信图片_20200921091224.jpg

    真正的云原生数据库就应该像城市自来水系统那样,无论你在哪里,只要拧开水龙头,就可以随意取水使用,只需要事后按用量交水费就可以了。

    不然的话,如同那些为了上云而上云的产品,本质上是自来水龙头接在了楼旁的水塔上,水用完了要等着水塔下次补水。水不够用,想换个大水箱,还得考虑水塔能不能承受得住?要不要连水塔主体一块盖个新的?这样的自来水又和挑水回家存在缸里又有什么差别呢?

    云原生在数据库上的应用并不会改变云和数据库本身的状态,但它的应用让云变成了更理想的云,也让数据库上云有了货真价实的意义。

    聊了这么多,那升华了数据库的云原生究竟有多厉害呢?用一个套娃行为来说就是:

    2011年,Netscape公司的创始人马克·安德森说:“软件正在吞噬事件”;
    而后在2016年,OpenStack基金会创始人Jonathan·Bryce 补充说:“世界的一切源于开源”;
    近几年来,云计算又用极快的速度扛起了指引未来方向的大旗;
    而在云计算概念日趋清晰且细化的今天,只有云原生才是那个能号令天下的宝刀屠龙。
     


               

                                                偶 数 科 技


    ⌈偶数科技⌋是一家领先的AI和大数据产品、解决方案提供商,致力于赋能全球各行业客户。公司的愿景和使命是 “让人类只为兴趣而工作”。偶数科技的产品已在金融、电信、制造、公安、能源和互联网等行业得到广泛的部署和应用。目前⌈偶数科技⌋已经获得多轮国际顶级VC的投资,是微软加速器成员企业,并入选美国著名商业杂志《快公司》“中国最佳创新公司50”榜单。
     

    drawing

    展开全文
  • 阿里云原生数据库系统:机遇与挑战 摘要 由于各种应用程序对弹性和按需(elasticityand on-demand)使用的需求,云原生数据库在云计算时代变得越来越重要。这些来自云应用程序的挑战为云原生数据库带来...

    目录

            1、简介

            2、阿里巴巴数据库系统架构

            3、阿里巴巴数据库系统的其他关键功能

            4、阿里云本机数据库

            5、应用和操作

            6、结论


    Cloud-Native Database Systems at Alibaba: Opportunities and Challenges

    阿里云原生数据库系统:机遇与挑战

    摘要

    由于各种应用程序对 弹性和按需(elasticity and on-demand)使用 的需求,云原生数据库在云计算时代变得越来越重要。这些来自云应用程序的挑战为云原生数据库带来了新的机遇,传统的企业内部数据库系统无法完全解决这些问题。云原生数据库利用软硬件协同设计来探索新硬件(如 RDMA、NVM)和 DPDK 等内核绕过协议提供的加速(A cloud-native database leverages software-hardware co-design to explore accelerations offered by new hardware such as RDMA, NVM, kernel bypassing protocols such as DPDK)。同时,新的设计架构,如共享存储,使云原生数据库能够将计算与存储分离,并提供出色的弹性特性对于需要水平伸缩性的高度并发工作负载,云原生数据库可以利用一个无共享层来提供分布式查询和事务处理。应用程序还需要云原生数据库通过分布式共识协议提供高可用性。

    在阿里巴巴,我们探索了一套设计云原生数据库系统的技术。我们的存储引擎 X-Engine 和 PolarFS 通过使用 LSM 树设计和自适应的冷热数据记录分离来提高写入和读取吞吐量。在此基础上,我们设计并实现了 POLARDB 及其分布式版本 POLARDB-X,成功支持了 2018  11  11 日全球购物节期间极端交易负载,并在阿里云上取得了商业成功。我们还设计了一个名为 AnalyticDB(简称 ADB )的 OLAP 系统,用于实现大数据的实时交互式数据分析。我们开发了一个自动驱动(self-driving)的数据库平台,实现了数据库的弹性伸缩和智能化管理。我们将分享关键技术和经验教训,强调阿里巴巴云计算数据库系统面临的技术挑战和机遇。

    1简介

    随着越来越多的应用程序和系统向云端迁移,云原生数据库系统开始获得广泛的支持和普及。云服务供应商提供的云数据库服务,如 AWS、Microsoft Azure、阿里云、Google 云等,为云原生数据库的开发做出了贡献。因此,近年来,云数据库的市场份额迅速增长。越来越多的企业和组织已经将其业务从内部数据中心迁移到云端。云平台提供了高弹性、严格的服务级别协议(SLAService-level Agreement),以确保可靠性和易管理性,同时降低运营成本。云数据库在支持基于云的业务方面起着关键作用。它成为连接底层资源(IaaS)和各种应用程序(SaaS)的中心枢纽,使其成为云计算的关键系统。

    在阿里巴巴集团,数据库系统需要支持一个丰富而复杂的商业生态系统,涵盖娱乐和数字媒体、电子商务和电子支付,以及各种新的零售和 o2o(offline to online)业务运营。在 2018  "光棍节" 全球购物节(2018年11月11日)期间,阿里巴巴的数据库每秒处理多达 49.1 万笔销售交易,相当于每秒处理超过 7000 万事务。由于对灵活性、可伸缩性和可管理性的需求,传统的数据库内部部署已经不能满足这种复杂的业务操作。

    例如,如 图1 所示(2018 年阿里巴巴光棍节期间,TPS 增长超过 100 倍,响应时间稳定。),在光棍节购物节的第一秒,TPS 突然增加,大约是前一秒的 122 倍。当我们简单地将 MySQL  PostgreSQL 部署在本地SSD和高I/O虚拟机的云实例(cloud instance)上时,得到的数据库实例容量有限,不适合提供可伸缩的数据库服务。它无法在潜在的磁盘驱动器故障中生存;数据库实例必须管理数据复制以提高可靠性。此外,该实例使用通用文件系统,如 ext4  XFS。当使用低 I/O 延迟硬件(如 RDM A或 PCIe SSD)时,内核空间和用户空间之间的消息传递成本可能会迅速地使吞吐量达到饱和状态。相比之下,采用云本地设计的数据库(如计算和存储的解耦、自动缩放)更具吸引力,能够提供更多的计算和存储容量,并提供更快的恢复能力和更低的成本[30,7]。

    对于云原生数据库来说,还有其他至关重要的能力:支持异构数据源和多样化查询接口的多模型;自动管理和调整数据库实例的自治性和智能性,以降低手动操作的成本;软硬件协同设计,利用高性能硬件的优势;高可用性,满足严格的 SLA 需求(例如,RPO = 0,RTO 非常小)。考虑到这些设计,云原生数据库在基于云的部署方面获得了快速增长。

    在本文中,我们发表了在阿里云上建立企业云原生数据库的最新进展[1],该数据库还支持阿里巴巴集团内各个业务部门(从娱乐、电子商务到物流)的整个业务运营。为了满足各种各样的应用程序需求,我们提供了广泛的数据库系统和工具,如图3所示。我们为每个节点开发了 100TB 的数据库处理容量。为了进一步扩展容量,我们已经开发了 POLARDB-X,一个集成了共享内容和共享存储设计的分布式 OLTP 数据库。我们还开发了 AnalyticDB,这是一个 OLAP 数据库,作为下一代数据仓库,用于 PB 级的高并发、低延迟和实时分析查询。为了管理云端承载的大量数据库实例,我们构建了 SDDP,这是一个自治的数据库操作平台,它可以自动管理实例并调整性能,只需很少的 DBA 参与。在阿里云上运行的数据库实例有近 50 万个(来自客户和阿里集团内的各个业务部门)。 POLARDB  AnalyticDB 在电子商务、金融、媒体和娱乐、教育、新零售等广泛的商业领域都获得了快速增长。这些云数据库系统和技术成功地服务于阿里巴巴集团内部复杂的商业生态系统和许多外部企业客户。

    2阿里巴巴数据库系统架构

    根据共享的内容,我们在阿里巴巴探索了三种流行构建数据库系统的架构,如 图2 所示。第一类是单实例,这是主流数据库最常用的架构。在这个模型中,数据库中的所有进程共享处理器内核、主内存空间和本地磁盘(即在一台机器上)。这样的体系结构促进并简化了系统内部的通信和协调。

    随着 Google、Amazon、Microsoft、Alibaba 等大型互联网企业在数据量和工作负荷上的快速增长,人们发现单实例架构有其局限性。单台机器的无法满足日益增长的业务需求。因此,提出了共享存储架构,以 AWS Aurora  Alibaba POLARDB为代表。在该模型中,底层存储层(通常由多个节点组成)被解耦,存储的每个数据记录都可以被运行在任意节点上的任何上层数据库内核访问。通过利用 RDMA 等快速网络,数据库可以与共享分布式存储层进行交互,就像与单个(共享)本地磁盘进行交互一样。在这个共享存储之上,我们可以轻松地启动多个计算节点来创建单个数据库的副本,在同一数据上具有相同的视图。因此,可以将请求分发到不同的(只读)节点进行并行处理。但是,为了避免写冲突,避免处理分布式事务和分布式提交的复杂性,通常只有一个节点处理数据库的所有写请求(例如,插入、更新、删除)。这种体系结构通过改变只读节点的数量,可以根据需要动态调整查询容量。允许对多个节点(即多主节点)的写入以扩展写容量也是可行的,但通常需要复杂的并发控制机制和一致协议[6,12,16,17,23,34]。

    共享存储体系结构也有其自身的局限性。首先,计算节点和存储节点之间的低延迟数据传输不能总是得到保证。对于跨交换机、数据中心甚至区域传输的消息,传输时间将大大增加,特别是当使用本地 RDMA 网络时。其次,单个数据库支持的只读节点数量是有限的。当节点数量达到一定的规模时,大量的请求将被阻塞,使得访问远程存储的成本高得令人望而却步。因此,一个实际的限制是大约有十几个只读节点。为了解决这个问题,我们需要一个无共享的架构(shared nothing architecture)。在共享存储体系结构中,逻辑数据库被分成多个分片,每个分片分配给一个节点。这些节点可以放置和复制到不同的数据中心和区域。这种架构的一个典型实现是 Google Spanner[7],它使用 GPS 和原子钟来实现跨区域的副本一致性和事务一致性。在阿里云上,我们构建了 POLARDB-X,它扩展了 POLARDB。我们探讨了在多个数据库之上构建一个无共享系统的好处,而每个数据库都有一个共享的分布式存储。(we build POLARDB-X that extends POLARDB and explores the benefits of building a shared-nothing system on top of multiple databases each with a shared distributed storage)

    请注意,这种共享和共享存储体系结构(shared-nothing and share-storage architectures)的混合体带来了一些特殊的好处。我们可以在顶层应用分表,但是将多个节点分配给一个分片(而不是每个分片一个节点)。在这个分片下面,这些节点可以访问共享存储。这种混合架构的好处是它减轻了小碎片过多的缺点。特别是,它有助于简化分片重新平衡的过程,降低跨分片事务的概率(并减少昂贵的分布式提交量)。同时,它还支持出色的水平扩展性这种混合架构同时利用了无共享和共享存储的优点,是我们在 POLARDB-X 数据库设计中探索的一个很有前途的方向。

    3、阿里巴巴数据库系统的其他关键功能

    除了探索不同的系统架构外,在阿里巴巴复杂的业务应用程序的驱动下,阿里巴巴数据库系统的设计还考虑了一些其他关键特性。

    3.1 多模型分析

    阿里巴巴的一个重要应用场景是支持多模型分析,它包括两个方面:southbound 和northbound 的多模型访问。Southbound 多模型访问表明底层存储支持不同的数据格式和数据源。存储的数据可以是结构化的,也可以是非结构化的,例如图形、矢量和文档存储。然后,数据库提供一个统一的查询接口,如 SQL 或类似 SQL 的接口,用于查询和访问各种类型的数据源和格式,形成数据湖服务。Northbound 多模型访问表明,单个数据模型和格式(例如,在大多数情况下,键值模型)用于将所有结构化、半结构化和非结构化数据存储在单个数据库中。在这个单一存储模型的基础上,数据库支持多个查询接口,如 SQL、SPARQL  GQL,这取决于应用程序的需要。微软 CosmosDB[9]就是这类系统的代表。

    除了满足我们内部的业务运营需求外,能够支持多模型分析也是云数据库服务的基本要求。许多云应用程序需要从异构数据源收集大量数据,并进行联合分析,以链接不同的数据源并揭示业务洞察力(即 southbound 多模型访问)。另一方面,云数据库(例如,大型 KV 存储,如HBase)通常是一个中央数据存储库,由具有不同应用需求的多个应用程序访问。由于可用性和效率的原因,他们可能更喜欢使用不同的查询接口,在这种情况下需要进行 northbound 多模型分析。

    3.2 性和智能性

    鉴于阿里巴巴数据库系统需要管理的数据库实例数量庞大,工作负载复杂,因此,提高数据库操作平台的自(autonomous)和智能性是必不可少的要求。在我们的平台上运行着数十万个实时数据库实例,以每个实例的方式来响应传统的基于 DBA 的手动操作、调优和维护是不可行的。从数据库内核和底层操作平台的角度来看,支持自主操作的机会很多[8、18、19、21、24、26、29]。基于此,我们致力于建设一个具有自我检测、自我决策、自我恢复和自我优化能力的自驱动数据库平台(SDDP)。以自优化为例,数据库内核中的各个模块(如索引、查询优化器和缓冲池管理)将通过采用机器学习技术进行增强,以便这些模块能够针对动态工作负载进行自适应优化。然而,由于机器学习模型的训练和推理成本很高,使得它们在数据库内核中既有效又高效是一项具有挑战性的任务。另一方面,自我检测、自我决策和自我恢复的目标是提高数据库操作平台的效率和有效性。如何自动检测实例状态和检测异常行为,以及一旦检测到错误,如何在较短的反应时间内做出正确的修复决策,是一个关键的挑战。

    3.3 软硬件协同设计

    阿里巴巴数据库系统创新的另一个关键课题是在硬件领域探索和利用快速发展和创新硬件。与任何其他系统一样,我们的目标是设计和实现我们的数据库系统,这些系统能够以安全和高效的方式使用有限的系统硬件资源。这一目标意味着系统必须关注硬件性能的不断变化和改进,以便能够利用创新的新硬件特性的优势。作为一个性能为主的系统,数据库系统需要充分利用可用的资源,稳健高效地执行查询和事务。随着新的硬件性能不断提高,简单地遵循现有的数据库设计并期望它们在新硬件上的性能最大化是不明智的。例如,直接运行在支持 RDMA 的分布式存储上的复杂数据库(如 MySQL)的性能明显低于具有相同 CPU 和内存配置的本地 PCIe SSD 上的性能,这需要仔细重新设计[5]。因此,新硬件带来的机遇是设计阿里巴巴数据库系统的重要考虑因素。例如,我们广泛探索和集成了新的硬件技术,如 RDMA、NVM、GPU/FPGA  NVMe SSD。

    3.4 高可用性

    高可用性是阿里巴巴数据库系统的基本要求之一,以确保我们的业务运营和云客户零停机,因为大多数企业客户无法容忍业务中断。高可用性的一个标准解决方案是复制,它可以在数据库实例、表或表碎片的粒度上完成。广泛使用的主备份三向复制(primary-backup and three-way replications)在大多数情况下都能胜任。对于需要更高可用性的银行和金融部门,可以强制执行四个或更多副本,这些副本通常放置在不同的数据中心(可用区域)和区域,以便在大区域故障(如网络故障和数据中心停机)中生存。

    在采用复制时,必须仔细处理副本之间的数据一致性。CAP 定理的结论是,在一致性、可用性和分区容差之间,只有三个属性中的两个可以满足。在阿里巴巴,我们在设计和实现我们的数据库系统时考虑到了"C"(一致性)和"P"(分区容差),并通过定制的 Parallel Paxos 协议(称为 X-Paxos)来确保高可用性,从而确保我们仍然可以提供高达99.999%的极高可用性。X-Paxos 实现并优化了复杂的复制技术和一致性协议,并通过日志确保数据的一致性和可用性。

    4阿里云本机数据库

    在本节中,将分享我们在阿里巴巴构建云原生数据库系统方面的最新进展。图3 总结了阿里巴巴和阿里云上的数据库系统和产品的完整概述。重点讨论了 POLARDB(共享存储 OLTP 数据库)及其分布式版本 POLARDB-X(一个基于 POLARDB 之上的共享 OLTP 数据库)、AnalyticDB(一个实时交互式OLAP数据库)和 SDDP(一个自主的数据库操作平台)。

    4.1 POLARDB:云原生 OLTP 数据库

    POLARDB 是基于 AliSQL(MySQL/InnoDB 的一个分支)[2]构建的关系型数据库系统,在阿里云上作为数据库服务提供。POLARDB 遵循云本地架构,提供高弹性、高容量和高并发性。另外,POLARDB  MySQL  PostgreSQL 完全兼容,帮助客户进行透明、流畅的业务应用迁移。

    4.1.1 系统设计

    POLARDB 遵循共享存储架构,如 图4 所示。它由三层组成:PolarProxy 作为统一的访问门户、多节点数据库集群和分布式共享文件系统 PolarFS。PolarProxy 是一个具有自适应能力的分布式无状态代理集群。

    它集成了多个计算节点的资源,为应用程序提供了一个统一的访问门户。它的动态扩展能力支持灵活地增加/减少节点。POLARDB 中的数据库节点分为 主节点  多个只读节点 两种类型。主节点可以同时处理读和写查询,而 RO 节点只处理读查询。主节点和 RO 节点共享 Redo 日志文件和数据文件,这些文件由 PolarFS(第4.1.2节)管理,PolarFS 是一种具有超低延迟、高吞吐量和高可用性的分布式文件系统。

    这种体系结构有几个独特的优点。首先,计算和存储资源被解耦。计算和存储节点可以使用不同类型的服务器硬件,并且可以单独定制。例如,计算节点不再需要考虑内存大小与磁盘容量的比率,这高度依赖于应用场景,并且很难预测。其次,它突破了单节点数据库(如 MySQL、PostgreSQL)的局限性。存储节点上的磁盘形成一个存储池,这降低了碎片化、使用不平衡和空间浪费的风险。存储群集的容量和吞吐量可以透明地横向扩展。POLARDB 能够提供 100TB 的存储容量,每个节点实现 100万 QPS。第三,由于数据都存储在存储集群上,计算节点上没有本地持久状态,这使得执行数据库迁移更容易、更快。由于 PolarFS 提供的数据复制和其他高可用特性,数据可靠性也可以得到提高。

    除了 POLARDB,其他云数据库服务也可以从这个架构中获益。首先,数据库可以基于虚拟化技术(如 Xen[3]、KVM[13]  Docker[20]构建一个更安全、更易于扩展的环境。其次,由于后端存储集群提供了快速 I/O、数据共享和快照功能,因此可以轻松实现数据库的一些关键功能,如多个只读实例和检查点。

    4.1.2 PolarFS  PolarStore

    数据存储技术持续地快速变化,当前的云平台很难充分利用 RDMA  NVMe SSD 等新兴硬件标准。例如,一些广泛使用的开源分布式文件系统,如 HDFS[4]  Ceph[31],被发现比本地磁盘有更高的延迟。当使用最新的 PCIe SSD 时,性能差距甚至可能达到数量级。与具有相同 CPU 和内存配置的本地 PCIe SSD 相比,直接在这些分布式存储上运行的 MySQL 之类的关系数据库的性能要差得多。

    为此,我们构建 PolarFS[5] 作为 POLARDB 的共享存储层。它是建立在 PolarStore(基于RDMA 网络的共享分布式存储)之上的分布式文件系统,通过以下机制提供超低延迟、高吞吐量和高可用性。首先,PolarFS 充分利用了 RDMA  NVMe-SSD 等新兴硬件,在用户空间实现了一个轻量级的网络栈和 I/O 栈,以避免陷入内核和处理内核锁。第二,PolarFS 提供了一个类似 POSIX 的文件系统 API,目的是编译到数据库进程中,替换操作系统提供的文件系统接口,使整个 I/O 路径都能保存在用户空间中。第三,PolarFS 数据平面的 I/O 模型也被设计用来消除锁和避免关键数据路径上的上下文切换。所有不必要的内存拷贝都被消除了,而 RDMA 被大量用于在主内存和 RDMA NIC/NVMe 磁盘之间传输数据。所有的本地到文件端的系统延迟都大大降低了。

    由于大型 POLARDB 集群中的节点故障很常见,因此需要一个共识协议来确保所有提交的修改不会丢失。按位复制应该总是一致的。在 PolarFS 中,我们首先使用 Raft[23],这是 Paxos 家族[17,16]的一种变体,它更易于实现,并且广泛应用于许多分布式系统。然而, Raft 被应用时,我们发现它严重地阻碍了 PolarFS  I/O 可扩展性,在 PolarFS 中使用低延迟 NVMe SSD  RDMA(其延迟约为几十微秒)。因此,我们开发了基于 Raft 的一致性协议 ParallelRaft,它允许无序的日志确认、提交和应用,同时允许 PolarFS 遵循传统的 I/O 语义。使用该协议,并行 I/O 并发性得到了显著的提高。

    综上所述,PolarFS 支持 POLARDB,其特点是:(1)PolarFS 可以将文件元数据的修改(如文件的截断或扩展、文件的创建或删除)从主节点同步到 RO 节点,这样 RO 节点的所有更改都是可见的。(2)PolarFS 确保对文件元数据的并发修改是序列化的,这样文件系统本身在所有数据库节点上都是一致的。(3)在网络分区的情况下,两个或多个节点可以作为主节点并发地写入共享文件。PolarFS 可以确保只有真正的主节点成功服务,防止数据损坏。更多技术细节见[5]。

    4.2 POLARDB-X:分布式 OLTP 数据库

    POLARDB 可以很好地扩展到多达数十个节点(由于底层 RDMA 网络的限制),但这不足以支持大量数据和事务的高度并发工作负载,例如在单日购物节上发现的数据和事务。因此,我们扩展了 POLARDB 并构建了 POLARDB-X,这是一个分布式的无共享 OLTP 数据库,以支持水平扩展POLARDB-X 结合了共享存储和无共享架构。与在每个分片上使用单个节点实例的标准无共享体系结构相比,这种设计的好处是,由于共享存储体系结构引入的扩展能力,每个分片现在可以存储和处理更多的数据和事务。因此,对于相同数量的数据和/或事务处理需求,与标准的共享系统相比,混合体系结构需要的碎片数量要少得多;这反过来又减少了处理复杂且昂贵的分布式事务处理和分布式提交的机会。因此,它支持海量数据上的高并发事务,并通过 Parallel Paxos 协议 X-Paxos 确保 cross-AZ 和跨区域事务的一致性。

    4.2.1 系统设计

    图5 显示了 POLARDB-X 的体系结构,其中关系数据被划分为多个 POLARDB 实例,并由分布式关系数据库服务(DRDS)管理。DRDS 接受 SQL 查询或事务,解析并优化它们的计划,最后将它们路由到相应的 POLARDB 实例以供执行。如前所述,每个 POLARDB 实例由一个主节点和多个只读节点组成。每个读节点都作为主节点的一个副本,共享 PolarFS 上的相同存储,PolarFS 又位于 PolarStore(阿里巴巴的块存储系统)上。 POLARDB 节点中,有一个用于从 DRDS 推送的查询计划的计划执行器(用于事务处理的事务服务)和一个 X-Engine(阿里巴巴基于 LSM 树的 OLTP 存储引擎)。

    4.2.2 X-Engine

    我们发现,在阿里巴巴和我们的大企业客户处理此类交易时,必须解决三个关键挑战:(1)海啸问题——随着大型销售和促销活动的启动,交易量急剧增加(例如,阿里巴巴光棍节全球购物节出现了 122 次高峰),这给底层数据库带来了巨大的压力。(2)泄洪问题——大量的热记录很容易淹没系统缓冲区,如果缓冲区无法快速刷新,则会阻碍后续事务处理。(3)活动时快速移动问题——由于持续时间短的大量促销事件,记录的 "热度"(即热、、冷)频繁发生快速变化,这大大降低了缓存命中率。

    我们构建 X-Engine[10]是为了应对阿里巴巴电子商务平台所面临的上述挑战,因为事务处理性能的一个重要部分归结数据的持久性和从存储中检索的效率。X-Engine 利用多核处理器中的线程级并行性(TLP)来处理主存中的大多数请求,将写入与事务分离以使其异步,并将长写入路径分解为管道中的多个阶段,以提高总体吞吐量(decomposes a long write path into multiple stages in a pipeline in order to increase the overall throughput)为了解决泄洪问题,X-Engine 利用一种分层存储方法在不同层之间移动记录,利用了改进的 LSM 树结构[22,25]和优化的压缩算法。我们还将 FPGA 卸载应用于压缩。最后,为了解决当前快速移动的问题,我们引入了一个多版本的元数据索引,该索引以写时拷贝的方式更新,以加速分层存储中的点查找,而不考虑数据热度

    图6 显示了 X-Engine 的体系结构。X-Engine将每个表划分为多个子表,并维护LSM树、关联的元快照和每个子表的索引。X-Engine 为每个数据库实例包含一个重做日志。每个 LSM 树由驻留在主内存中的热数据层和驻留在 NVM、SSD、HDD 中的暖/冷数据层(进一步划分为不同的级别)组成,其中术语 Hot、Warm  Cold 指的是数据热度,表示应该放在相应层中的数据的理想访问频率。热数据层包含 一个活跃 Memtable  多个不可变的 Memtable,它们是存储最近插入的记录的跳板,以及缓冲热记录的缓存/冷数据层以树状结构组织数据,树的每一级都存储一个经过排序的区段序列。数据块打包记录块及其关联的筛选器和索引。

    X-Engine 利用 Redo 日志元快照索引支持事务处理的多版本并发控制(MVCC)。每个元快照都有一个元数据索引,用于跟踪快照中树的所有级别的所有内存表和扩展数据块。在相邻的一层或多个层次上存储一个或多个层次的硬盘驱动器。X-Engine 中的每个子表都有自己的热、和冷数据层(即 LSM 树),以面向行的格式存储记录。我们设计了一个多版本 Memtables 来存储不同版本的记录,以支持 MVCC。在磁盘上,元数据索引跟踪存储在扩展数据块中的所有记录版本。更多技术细节见[10]。

    4.3 AnalyticDB:实时 OLAP 数据仓库

    AnalyticDB 是一个实时的 OLAP 数据库系统,设计用于 PB 级的高并发、低延迟和实时分析查询。它从 3 个节点运行到 2000 多台物理机,并作为一个数据库服务在阿里云上提供相应的服务。它服务于电子商务、金融科技、物流、公共交通、气象分析、娱乐等多个业务领域的企业客户,以及阿里巴巴集团内部的业务运营。

    最近的著作[28,14,15,32,11]总结了设计 OLAP 系统的主要挑战:实现低查询延迟、数据新鲜度、灵活性、低成本、高可扩展性和可用性。与这些工作相比,来自我们应用场景的大规模分析工作负载将 AnalyticDB 提升到更大的规模:10PB+ 数据、数十万个表和数万亿行,这对 AnalyticDB 的设计和实现提出了重大挑战:1)今天的用户面临比以往任何时候都更复杂的分析场景,但仍然对低查询延迟抱有很高的期望。尽管来自不同应用程序的查询是多样和复杂的,但它们通常不能容忍花费很长时间的查询。2)新兴的复杂分析倾向于结合不同类型的查询和数据。超过一半的用户数据具有复杂的数据类型,例如文本、JSON 字符串或 vector。一个实用的数据库应该能够有效地支持对具有复杂类型的异构数据的查询。3)在以低延迟处理实时查询的同时,系统还需要每秒处理数千万个在线写入请求。在同一进程路径中读写数据的传统设计不再适合这种情况。应该考虑在查询延迟、写入吞吐量和数据可见性之间进行仔细的设计。

    为了解决这些挑战,我们用几种新颖的设计构建了 AnalyticDB。首先,AnalyticDB 嵌入了一个高效的索引引擎。在这个引擎中,索引建立在每个表中的所有列上,以显著提高复杂查询的性能。我们进一步提出了一种基于运行时过滤器比率的索引路径选择机制,以避免索引滥用导致的性能下降。由于在关键路径中更新大型索引的成本过高,因此索引是在非高峰时段异步构建的。我们还维护了一个轻量级的排序索引,以最小化异步索引构建对涉及增量数据(即,在当前一轮索引构建开始之后写入的数据)的影响。

    其次,我们设计了底层存储布局,以支持结构化数据和其他复杂类型数据的行列混合存储。特别是,我们使用快速顺序磁盘 I/O,因此无论是 OLAP 样式还是点查找工作负载(OLAP-style or point-lookup workloads),其开销都是可以接受的。我们进一步在存储中加入了复杂的数据类型(包括索引),以提供与结构化数据一起搜索资源(即JSON、vector、text)的能力。

    第三,为了支持高吞吐量写和低延迟查询,我们的系统遵循一种将读写解耦的体系结构,即分别由写入节点和读取节点提供服务。这两种类型的节点彼此隔离,因此可以独立伸缩扩展。特别是,写节点会持久地向盘古(阿里云上的一个可靠分布式存储)发送写入请求。为了确保服务查询时数据的新鲜,在读取节点上应用版本验证机制,这样就可以看到以前在写节点上处理的写操作。

    第四,为了进一步提高查询延迟和并发性,我们在 AnalyticDB 中增强了优化器和执行引擎,以充分利用我们存储和索引的优势。具体来说,我们提出了一种基于存储的 SQL 优化机制,根据存储特性生成最优的执行计划,并在基于成本的优化器(estimation in cost based optimizer)中提出了一种有效的基数估计实时采样技术。此外,我们还设计了一个高性能的用于混合存储的矢量化执行引擎,可提高计算密集型分析查询的效率。

    系统架构如 图7 所示。AnalyticDB 中主要有三种类型的节点,即协调器、写入节点和读取节点Coordinator, Write Node and Read Node)。协调器从客户机连接收集请求(包括写入和查询),并将它们分派到相应的写入和读取节点。写入节点负责处理写入(如INSERT、DELETE、UPDATE)以及将 SQL 语句刷新到盘古中以实现持久性。读取节点负责处理查询(例如SELECT)。通过这种方式,写和读节点彼此解耦。伏羲(阿里云上的资源管理器和作业调度器)利用所有这些节点上的可用资源为异步任务执行提供计算工作。此外,AnalyticDB 还提供了一个在计算工作上运行的通用管道模式执行引擎。以列块为单位的数据通过系统从存储器流向客户机。所有的数据处理都在内存中,并且在网络的不同阶段之间通过管道传输。这种流水线工作流使 AnalyticDB 能够以高吞吐量和低延迟服务于用户的复杂查询。更多技术细节见[33]。

    4.4 SDDP:自驱动数据库平台

    为了管理阿里云上众多的数据库实例,我们搭建了一个自的数据库管理平台 SDDP(Self-Driving database platform)。该平台收集所有运行数据库实例的实时统计信息,并使用机器学习和统计方法来优化实例和提供资源。

    4.4.1 系统设计

    图8 显示了 SDDP 的体系结构。混合云数据库管理(HDM)层从数据库实例收集 SQL 和度量,并将它们存储在时间序列数据库(TSDB)中。同时,HDM 检测数据库状态并将这些信息与控制器同步。数据库状态通常由 DDL 操作更改。例如,我们可以使用 ALTER TABLE t1 HOTCOLD='SMART' 将表设置为智能模式并自动分离热/冷数据(第4.4.3节)。HDM 还分配控制器来驱动机器学习任务,例如参数调整(第4.4.2节)、资源调度和异常检测。控制器将这些任务调度到模型训练平台(MTP,Model Training Platform)。MTP  TSDB 检索数据,包括 SQL 和衡量指标,并使用不同的模块来完成相应的作业。结果将由控制器传回 HDM 并应用于数据库实例。

    4.4.2 缓冲区大小调整

    缓冲池是 OLTP 数据库的一个关键资源,它作为一个数据缓存空间来保证理想的系统性能。对阿里巴巴超过 10000 个实例的 OLTP 数据库集群的实证研究表明,缓冲池平均消耗每个实例 98% 的内存空间。数据库管理员(通常基于固定的数据库配置和经验)一致推荐。这种手动过程既不高效也不有效,甚至不适用于大型云集群,尤其是当工作负载可能在单个数据库实例上动态变化时。

    为此,我们构建了 iBTune[27],个性化的缓冲区优化,以自动减少任何单个数据库实例的缓冲区大小,同时仍保持其响应时间的服务质量,而不依赖 DBA 来设置预定义的级别。我们利用未命中率和缓冲池大小之间的关系来优化内存分配。我们的模型利用类似实例中的信息。同时,我们设计了一个新的双深度神经网络,利用实例对的测量值来预测响应时间的上界。到目前为止,iBTune 已经部署在 SDDP 上,并应用于 10000 多个数据库实例。我们成功地将内存消耗减少了 17%(≥ 27TB),同时仍然满足我们多样化业务应用所需的服务质量。

    图9 显示了 iBTune 的体系结构和工作流的概述。有四个关键组件:数据收集、数据处理、决策和执行。iBTune 工作流形成了一个封闭的循环,因为数据首先从 DBMS 内核收集、处理并用于训练,然后生成的模型再次应用于 DBMS。在数据收集中,我们使用定制的代理从 DBMS 收集各种数据库衡量指标和日志。收集了 1000 多个指标。代理位于 DBMS 外部,以避免 DBMS 内核不必要的性能开销。所有的衡量指标和日志都以一秒的粒度收集并输入到消息队列中。在数据处理中,流处理系统从消息队列中读取数据,并执行某些数据操作/标准化操作,如规范化、聚合和日志转换。然后,处理后的衡量指标和日志存储在分布式数据存储系统中,用于分析和模型训练。在决策中,我们提出了一种新的预测 RT 和计算新的 BP(缓冲池)大小的方法。如果预测的 RT 满足要求,计算出的新 BP 大小将被发送到执行组件(execution component),该组件包含一个计划器和一个调度程序(planner and a scheduler)。为了处理大量的数据库实例,Action Planner 的目标是为成千上万个操作制定一个全局高效、无冲突的执行计划。它包括不同操作类别之间的优先级设置、同一实例的操作合并、操作冲突的检测与解决、canary 执行策略等。它最终将多个操作序列输出到 Action Scheduler。更多技术细节见[27]。

    4.4.3 其他场景

    除了缓冲区大小调整外,我们还探索了其他自治设计,如慢 SQL 优化、空间缩减、冷热分离、ML 优化器、故障检测和恢复。以热/冷分离为例,通过数据的热度(范围)来区分 X-Engine(第4.2.2节)中的水平。一个区段的热度是通过它在最近的窗口中的访问频率来计算的。当执行压缩时,X-Engine 使用阈值指定的数量选择最冷的数据块,例如 500 个数据块,并将这些数据块推到更深的级别进行压缩。通过这样做,X-Engine 保持了上层的热数据块(warm extents)和深层的冷数据块(cold extents)。但是这种方法不能很好地处理动态工作负载。例如,当前块的存取频率较低时,此算法会将来可能会变热的块视为冷数据。为此,我们研究了基于机器学习的算法来识别合适的热度范围。直觉是,除了范围之外,我们还使用行级别(record)作为粒度来推断热度(warm/cold)。如果在最近的窗口中从未访问过某个记录,则该记录被标识为处于 cold。否则,它被认为是 warm。因此,热度辨识转化为二元分类问题,并可使用分类模型(例如使用随机森林或基于神经网络的方法)来解决。

    5应用和操作

    在阿里云上运行的数据库实例已近 50 万个,既支持阿里集团内部业务运营,也支持外部客户业务应用。通过利用我们的云原生数据库系统,我们成功地为大量复杂的应用程序场景提供服务。

    POLARDB。POLARDB 在阿里云上的人数增长迅速。它为金融科技、游戏和娱乐、教育和多媒体等不同行业的领先公司提供服务。许多应用程序选择迁移到 POLARDB,因为它们的自部署数据库支持的事务处理速率有限。例如,一个应用程序在 MySQL 实例中,在高峰时间会增加 5 倍的延迟和频繁的事务失败。POLARDB 有助于将所有事务延迟保持在 1 秒之内,并将峰值吞吐量提高 3 倍。另外,一个 POLARDB 实例能够在 5 节点复制的 MySQL 集群上保持相同的查询性能,并减少经验丰富的 DBA 所需的工作。在大多数情况下,它可以将数据库的总体拥有成本(TCO)降低50-80%。

    POLARDB-XPOLARDB-X 已应用于阿里巴巴的许多性能为主和成本敏感的商业领域中。例如,2018年光棍节全球购物节开始时,我们处理的交易量增加了 122 倍,每秒处理多达 49.1 万笔销售交易,相当于每秒超过 7000 万数据库事务。为此,已经在线部署了 2000 多个 POLARDB-X 节点。随着 GMV(总商品量)的快速增长,管理 OLTP 数据库和维护底层服务器的成本迅速上升,这是阿里巴巴面临的一大挑战。为了降低成本,我们在阿里巴巴的许多业务中用 POLARDB-X 替换了 MySQL,这些业务利用了降级的硬件(例如,CPU 核数和存储量更少),同时保持了相同的 QPS/TPS 级别。在许多情况下,我们设法将数据库的总体拥有成本降低了50%。

    AnalyticDB。AnalyticDB 已经在阿里云 2000 多个节点上运行。它服务于广泛的商业领域,如电子商务、金融科技、物流、公共交通和娱乐。基于 AnalyticDB,我们扩展了一个端到端的解决方案,涵盖了从数据采集到数据可视化的整个分析途径。与其他解决方案相比,我们的客户能够无缝构建在线分析服务,同时降低总成本。AnalyticDB 帮助应用程序更好地利用其数据:对万亿级数据的即时多维分析和业务探索可以在毫秒内完成;用户可以通过调用内置函数和模块来定义和启动其分析任务;在许多情况下,可视化新获取的数据的端到端延迟减少到小于一分钟;并且不需要客户手动操作来维护服务。

    SDDP。SDDP 已经被用于管理阿里巴巴的数万个数据库实例。我们通过使用多个自主智能模块,成功地节省了大量集群资源:SQL 优化模块检测并优化了 2740万 条低效 SQL 请求;空间优化模块释放了 2.26PB 的存储空间(如通过去碎片化和删除无用的索引/表);iBTune 模块在保证服务质量的同时,节省了 27TB 的内存空间;全局工作负载调度模块将磁盘利用率从 46% 提高到 63%。

    6、结论

    云原生数据库系统是一个日益重要的研究和开发课题。它为数据库社区和行业带来了许多新的技术挑战和新的机遇。在阿里云内部,我们分享了阿里云在本地和本地数据库建设方面的丰富经验和教训。考虑到云技术的快速发展,云原生数据库系统在未来的道路上将变得更加关键,并为支持下一代云应用开辟新的令人兴奋的研究方向和工程挑战。

    原论文中的声明:

    本作品根据 Creative Commons AttributionNoDerivatives 4.0 国际许可证授权。要查看此许可证的副本,请访问http://creativecommons.org/licenses/by-nc-nd/4.0/。对于本许可证涵盖范围以外的任何用途,请通过电子邮件获得许可info@vldb.org。版权归所有人/作者所有。授权 VLDB 基金会出版权。

    展开全文
  • 聚焦产业趋势与技术前沿,打造产业互联网顶级盛会的2021腾讯数字生态大会日前在武汉举办,腾讯云数据库技术负责人程彬进行了《云原生时代的数据库技术实践》的主题演讲,分别从云原生时代数据库技术何去何从,新时代...
  • 作者:柯煜昌 顾问软件工程师目前从事 RadonDB 容器化研发,华中科技大学研究生毕业,有多年的数据库内核开发经验。你将 Pick 这些内容:云原生的概念云原生数据库的概念两种主流技术路...
  • 云原生数据库的概念 两种主流技术路线分析 六种云原生数据库方案和功能介绍 云原生数据库的核心功能和价值 背景 随着云计算的蓬勃发展,IT 应用转向云端,云服务出现如下若干特点: 提供按需服务; 用户只愿支付...
  • 什么是云原生分布式数据库

    千次阅读 2020-11-27 07:50:00
    这两天朋友圈中刷屏最多的是达梦数据库产品发布会,众多嘉宾,群星璀璨,此次一口气推出了达梦数据共享集群(DMDSC)、达梦启云数据库(DMCDB)、梦图数据库(GDM)、达梦新一代分布式数...
  • 背景 随着云计算的蓬勃发展,IT 应用转向云端,云服务出现如下若干特点: 提供按需服务。 用户只愿支付运营费用而不愿支付...起初,通过借助 IaaS,直接将传统的数据库 “搬迁” 到上,于是出现了关系型数据库
  • 2013年一个名叫“Docker”的开源项目发布,以“应用封装+容器镜像”直接将一个应用运行所需的完整环境实现了“一次发布,...伴随着云时代的演进,大家言必称“云原生”,而“云原生”也被很多人视为企业数字化转型的关
  • (二)阿里云全面引领云原生分布式数据库发展方向阿里云在云原生数据库领域做了多年的实践、尝试与探索,与开发者一起成长。我们认为接下来云原生数据库必须关注和发展的领域有以下五个:1)云原生分布式将云原
  • 随着海量计算的持续发展,给传统数据库带来了不少挑战,而云原生数据库却可以应对这些挑战。 什么是云原生数据库 简单来说,云原生数据库,是一种通过云平台进行构建、部署和分发的服务。这种云原生属性是它相比于...
  • 通过分析工业大数据的特点,提出并实现了一种基于技术的分布式实时数据库系统。该系统将技术与实时数据库技术相结合,既满足工控对于数据实时性的要求,又具有高扩展性、高容错性、高可靠性,满足工业大数据的...
  • 云原生数据库vitess简介

    千次阅读 2019-11-06 15:16:09
    vitess是用于MySQL水平扩展的数据库集群系统 具有以下特点 可扩展性 Vitess将许多重要的MySQL功能与NoSQL数据库的可伸缩性结合在一起。其内置的分片功能使您可以在不向应用程序添加分片逻辑的情况下扩展数据库。 ...
  • 凌云时刻作者:李飞飞,现任阿里巴巴集团副总裁,ACM杰出科学家,阿里云数据库产品事业部负责人,达摩院数据库与存储实验室负责人。来源:阿里技术云原生是一种新型技术体系,是云计算未来的发展...
  • TDSQL-C 将传统数据库与云计算的优势相结合,首先具有云计算的五大特点: On-demand self-service 按需自助服务 Broad network access 广泛的网络接入 Resource pooling 资源池化 Rapid elasticity 快速交付弹性扩展...
  • 简介:5月29日,阿里云开发者大会上,阿里云数据库宣布「云原生数据库 2.0:一站式全链路数据管理与服务」的全新品牌理念及开源云原生数据库能力,首次从客户场景视角提出了一站式在线数据管理平台的理念。...
  • 云原生数据库与数据仓库有哪些独特优势?在日前的 DTCC 2020大会上,阿里巴巴集团副总裁、阿里云数据库产品事业部总裁、ACM杰出科学家李飞飞就《云原生分布式数据库与数据仓库系统点亮数据上云之路》进行了精彩分享...
  • 云原生数据库是一种通过云平台进行构建、部署和分发的服务。作为一种云平台,云原生数据库以PaaS的形式进行分发,也经常被称作DBaaS;用户可以将该平台用于多种目的,例如存储,管理和提取数据。云原生数据库是什么...
  • 时代,一切变化皆有因。许多年以前,传统数据库一统天下,企业用户的核心应用也是基于这样的底层而构建,集中式架构代表着一个时代。现在,云计算深入各行各业,来自公共供应商...
  • 小程序开发拥有易接入、高性能、高可用等特性,提供完整的原生云端能力支持,可有效降低后端与运维成本,帮助开发者更专注于业务,实现快速上线与迭代。其中,小程序开发的数据库是一个既可在小程序前端操作、也...
  • OushuDB是世界上最快的新一代云原生数据库,同时支持公有云与私有云部署,兼容各大云计算平台,该产品采用了存储与计算分离架构,具有超高性能,遵循国际SQL标准,还具有弹性,支持大规模集群、混合工作负载、和可...
  • 【前言】Taurus是华为对标AWS Aurora的一款重磅云原生数据库。其设计思想是Log-as-database以最小化网络IO,采用计算存储分离的架构。Taurus的市场定位是OLTP的企业级市场以及高端MySQL客户,但兼顾中小客户。技术...
  • 此次VoltDB 进入 CNCF Landscape,意味着 VoltDB 正式成为了 CNCF 认可的构建云原生最佳实践中的一环。 云原生计算基金会(CNCF ,Cloud Native Computing Foundation)致力于云原生技术的普及和可持续发展。CNCF ...
  • 作者:赵宝宝链接:https://zhuanlan.zhihu.com/p/151086982来源:知乎著作权归作者所有。前言多年以来,各云数据库厂商基于传统的单体数据库为客户提供了上...
  • 自1970年 Codd 祖师爷提出关系模型开始,关系型数据库在五十多年的时间中蓬勃发展。早期互联网的流量并不想我们现在所处的年代,QPS的需求往往百级别就绰绰有余,但是2000年左右互联网应用如雨后春笋,一时间庞大的...
  • 云原生数据库与数据仓库有哪些独特优势?在日前的DTCC 2020大会上,阿里巴巴集团副总裁、阿里云数据库产品事业部总裁、ACM杰出科学家李飞飞就《云原生分布式数据库与数据仓库系统点亮数据上云之路》进行了精彩分享。...
  • 以 Oracle、DB2、SQL Server 为代表的三大商业数据库产品独占鳌头,随后涌现出 MySQL、PostgreSQL 等为代表的开源数据库 ,和以 Amazon RDS 等为代表的云数据库,拉开百花齐放的数据库新序幕。 我们知道,云计算十...
  • 小程序开发拥有易接入、高性能、高可用等特性,提供完整的原生云端能力支持,可有效降低后端与运维成本,帮助开发者更专注于业务,实现快速上线与迭代。其中,小程序开发的数据库是一个既可在小程序前端操作、也...
  • 摘要: 4月17日(巴黎时间)阿里POLARDB走出国门,亮相ICDE2018,并同步举办阿里自有的POLARDB技术专场。在会上,阿里进行了学术成果展示,从而推动Cloud Native DataBase成为行业标准。4月17日(巴黎时间)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,735
精华内容 5,494
关键字:

云原生数据库系统特点