建设网站管理规定,网站建设方案有哪几种,市场营销方案案例范文,wordpress免费好用主题简介#xff1a;作者#xff1a;蔡乐
本文主要分享一下Polar DB for PG的开源路线图#xff0c;虽然路线图已经拟定#xff0c;但是作为开源产品#xff0c;所有参与者都能提出修改意见#xff0c;包括架构核心特性的技术以及周边生态和工具等#xff0c;希望大家能够踊…简介作者蔡乐
本文主要分享一下Polar DB for PG的开源路线图虽然路线图已经拟定但是作为开源产品所有参与者都能提出修改意见包括架构核心特性的技术以及周边生态和工具等希望大家能够踊跃提供想法和建议帮助产品提升。
本文主要围绕项目的背景和路线图来展开传统数据库产品已经研发了40多年知名厂家有很多产品也是层出不穷。看看数据库排行榜就知道我们面对多么丰富的数据库产品族谱加上最近10年来大数据NoSQL、NewSQL的兴起数据库产品逐渐和大数据处理产生融合的趋势任何一个新研发的数据库产品一定离不开这些背景选择一个数据库产品的技术方向同样受到大环境的影响和约束。
本文将花一些时间阐述对这个背景的理解和分析并在此基础上提出产品开源的路线图及其所要达成的目标和需要解决的问题。
一、 背景
一饮水思源回馈开源成就开源
首先介绍的背景是关于开源讲讲现在数据库上云是如何利用开源的然后如何回馈了到开源产品并且最终成就开源。 过去数据库作为传统的IT基础设施基本上垄断在几大主力的厂商手里。虽然开源数据库产品很多也很流行比如MySQL等都是叫好不叫座挣钱能力不足商业能力可能不是很好这其实由下面的一些因素来决定。因为数据库作为核心的IT基础设施因此对其可靠性、稳定性、功能全面性和性能要求很高每个企业在选型数据库时非常谨慎开源数据库在10年前也没有拿出足够的能力来撼动这些商业数据库的地位。
其次就是在商业上由于以前使用数据的大部分都是大客户有充足的资源他们当然希望被大公司来服务。上述两个因素形成了商用数据库的生态用户DBA开发以及中间商大家都是基于这些商用数据库工作所以一个新产品如果想要进入它面临的门槛是非常高的自然就形成垄断造成某些厂商一枝独大。
随着IT的云化公有云市场的发展比如AWS阿里云等这些后期的IT提供商从计算存储资源优化开始为用户提供按需的资源进而自然进入基础软件的供应。
显然使用来自垄断厂商生产的商用数据库为云用户提供服务将导致云的利润都被商用数据库厂商拿走将开源数据库特别是像MySQL、PostgreSQL推上前线和商用数据库一争高低是其背后的商业背景和目的决定的其中的路径基本上有下面几步。
首先是完善这些数据库的企业级管理能力也就是今天所谓的RDS服务比如数据库的部署数据库的启动、停止升级扩容备份恢复等操作。这些管理能力的云化和完善使得上云的用户不再需要DBA来管理数据库极大减少了用户的运营成本。
因此第一步是开源数据库上云用云化管理来替代DBA实现对商用数据库的商业模式的超越。当然云化的数据库资源的随用随取也是一个非常重要的点。完成这一步还不够毕竟开源数据库在本身能力上和商业数据库是有一定差别的。
要想取得商用数据库开辟的大市场开源数据库的云化增强就开始了因为补上差距是不够的不能够吸引客户转投开源数据库必须有超越商用数据库技术的的技术和竞争力。
比如阿里云开发了PolarDB首先对数据库依赖的存储系统进行云化改造提供云延伸的扩展性和资源弹性同时对外维持开源数据库的所有特性保证开源数据库的生态可以很好地被继承。
改造解决了商用数据库对底层存储硬件固有的依赖比如其性能和容量完全受限于存储硬件不容易扩容也不能实时在线地提供按需吞吐后续引入的一写多读分布式以及Global DataBase的技术使得云原生基于开源数据库的产品完成了对传统商业数据库的技术超越为用户提供了它们不能提供的价值和竞争力。
阿里云在使用开源数据库的同时也在不断地为开源社区输出企业级的技术。比如阿里维护了MySQL分支AliSQL比如我们推入PG社区的全局临时表功能。
我们无法往社区推很多东西因为PG社区非常谨慎的对每一个特性的需求和设计都有非常严格的要求需要经过多位重量级的Commit的同意和竞争开发者的同意。很多特性在社区历史上都被其他开发者开发过只是设计角度和覆盖方面没有满足社区的需求而被搁置。任何一个Patch都是需要超越以前的版本最终才能被PG社区接收。
我们经过半年多的时间最终实现了被社区所接受的特性。考虑到社区版本演进的谨慎性我们有许多技术可以回馈开源社区但是因为社区的相对谨慎我们很难做到这个事情其中的周期非常长这就成为我们开源PalarDB的一个重要原因。我们希望开源的技术是对社区内核能力的辅助增强所以最好都是垂直于社区能力用户拿我们的开源软件加上社区的内核版本就可以同时享用两边的贡献就是我们目前选择开源高可用能力、分布式扩展能力、后续云化运维能力等功能的主要考虑因素。
通过这些技术的开源我们就可以和社区共同成长我们的技术就是社区的一份子同时社区的发展也能够帮助我们更好地服务客户最终收益的是开源社区和我们的用户社区和开源数据库的用户们获得了共同成长的利益和价值而阿里数据库团队将成为其中的一个助力这是我们对开源产品的理解。
二数据库架构
接下来介绍的是关于数据库的架构它是如何演进现在有哪些数据库的架构。 上图列了三种架构最左边的是单机数据库一台服务器在运行一个数据库存储就是本地磁盘系统用户通过网络连接数据库进行SQL查询和计算。
很明显这种架构的问题是当数据库故障的时候用户服务将会被中断同时本地盘系统的容量和吞吐有限当用户负载增加的时候单机数据库会出现服务响应时间过长等性能问题。但有些商用数据库、开源数据库、MySQL、PostgreSQL它在一台服务器上部署的时候就是这种类型。
中间这个架构又称为共享存储或Shared Everything架构其特点是多个数据库实例共享一个存储系统。一般这种存储系统它是由硬件厂家生产或者通过云化的存储服务具备更高的性能和容量。多个数据库实例除了可以共享这种系统外还可以共享一个数据库包括其字典表、用户表等。这些数据库实例可以写也可以读比如Oracle其数据库实例就是可以同时读写共享存储。PolarDB现在只有一个写节点其他节点都是读节点。这个架构的特点是计算和存储分离数据库计算有专门的数据库节点来完成而存储有专门的硬件或者云化存储系统来实现。
另外一个特点是当有实例故障的时候可以快速恢复快速地切换负载到其他实例上去执行中断时间非常短。但用户负载和要求吞吐增加的时候这个架构需要提升硬件的规格来实现能力的提升比如增加数据库节点的CPU核数增加共享存储的能力等所以这种扩展能力我们称之为垂直扩展或叫做Scale up。
最右边这个架构称为Shared Nothing架构或者叫分布式架构每个数据库实例和单机数据库类似有自己的存储和计算资源每个数据库实例都是一个独立的数据库。但是这些数据库通过一定的MetaData和字典表的管理实现对用户来看就是一个数据库。每一个数据库实例其实管理一个分片数据库存储一部分数据库的数据相互之间是逻辑和物理的隔离所以称之为是Shared Nothing架构。其主要特点是当涉及多个分片数据库时需要执行分布式的SQL计算需要通过分布式事务保持事务一致性这种架构的优点是系统可以水平扩展。
当用户需要更大的存储容量更高的计算吞吐时就可以通过增加数据库分片也就是数据库节点的方式来提升系统容量性能这种扩展方式称为水平扩展或叫Scale out。
开源的Polar DB将是后面两种架构的融合。
三数据库系统的演进
接下来介绍一下数据库系统的演进以及演进对我们开源数据库产品的路线的影响。 无论是传统的商业数据库还是我们开源数据库MySQL或PG它处理的都是关系型的数据也就是结构化的数据。其中又分为两种,RDBMS也就是关系型数据库管理系统主要处理在线的交易型负载比如ATM商家的在线交易等等。
另外一个称为Data Warehouse也就是数据仓库。和RDBMS一样都使用标准的SQL来处理数据但是其负载涉及大量数据很多表计算非常复杂典型的应用为ETL和在线分析计算。
随着大数据的兴起Hadoop平台的普及用户希望处理的数据类型逐渐多样化比如时间序列、地理数据、图、向量、文本等等。相应的数据处理产品涌现它们区别于关系型数据库的最大差别是处理的数据类型和使用的处理语言是不一样的以及它们和Hadoop等大数据平台的融合带来了极高的可用性和扩展性能够水平扩展到几十台甚至几百台、上千台服务器上。
受这些产品的启发许多新型数据库系统开始转向分布式的高可用、高扩展引入了共识协议实现高可用同时维持对数据库处理语言SQL的支持典型例子有Google的Spanner虽然这些NewSQL实现了上述目标但是其对SQL支持的完整度上和开源数据库仍然有一定的差距可以说只是后者的子集需要投入很大的资源来完善这部分功能。
我们的想法是能否在开源数据库的基础上引入分布式引入共识协议以及存储和计算层的弹性优化实现NewSQL产品的高可用、高扩展、高弹性但是保留对开源生态SQL的完整支持这是我们开源路线图一个支撑的因素。
四业务痛点分析
下面我们来分析一下当前看到的传统数据库或者集中数据库的业务痛点。 虽然有这些痛点这些数据库仍然能够服务用户的很多需求。但是随着互联网移动IoT还有人机交互方式的不断演进数据量和并发量不断地增加逐渐超过了单机数据库或集中式数据库的吞吐比如超高并发每秒上千上万的病房对于大部分单机数据库来说是很难处理的要么就牺牲性能延时极大并且伴随着大量的超时查询要么系统可能就会被击垮。
集中式通过读写分离和存储计算分布式有限地提升了应对这种并发的能力但是仍然存在单点处理能力不足的瓶颈。同样的业务通过ETL产生的数据对存储容量的需求逐渐超越单机或集中式能够提供的限制这些其实都可以通过分布式化的Shared Nothing的产品架构来应对。比如将查询事务分摊到多个计算节点来成倍地提升吞吐加入更多节点来实现存储容量的水平扩展等。
不仅如此通过复杂大数据查询的分布化在各个计算节点上并行运行可以大大提升单机或集中式对这些查询的处理效率。另外一方面对于MySQL这样的IoT表来说单表太大也将影响查询性能。水平分区有效减少单个数据库内的表的大小避免查询性能受到比如说像缓存命中下降Scan效率降低的影响。
这些业务痛点其实都是提出了对分布式和水平扩展的需求也是考虑我们技术路线图的一个因素。
五技术趋势云化分布式资源共享
背景方面我们最后主要讨论一下数据库的技术趋势背景但数据库技术很多我们不可能每一个点都覆盖因此主要从云化的角度去理解因为毕竟数据库产品现在的主要方向是云化。 从云化角度来看首先数据库需要云化的技术是什么呢
我们得看云化的核心是什么云化的核心就是要极大地减少用户使用数据库的代价或者叫TCOTotal Cost of Ownership。这个代价主要包括管理、运维、软件、硬件代价。基于这个核心目前公有云数据库服务首要提供的就是管控功能帮助用户减少和避免管理和运维的投入。同时云化服务支持按需的软硬件配置发挥软硬件的最大效率并保留实时的弹性保证用户能够最有效的支持负载水平所需的资源。云化技术目标可以总结为简单易用性价比最高。
其次数据库还需要分布式技术不管是存储的分布式还是计算层还是事务一致性层甚至是故障恢复和数据冗余方面都需要分布式的技术。
业务层面上现在的数据库系统需要支撑海量的数据业务所带来的高并发负载和混合负载。从云化角度分布式能力是实时弹性所需要的核心能力所以也是云化的必要条件。
最后的技术趋势是资源要共享资源要隔离实现按资源或按系统分层的独立扩展。比如计算和存储的分离就可以实现数据库计算按需扩展相应的如果存储容量需要增加则只需要增加存储层的资源和节点、这种隔离和独立扩展能力可以扩展到内存扩展到计算、存储网络甚至数据数据库的一些核心处理能力比如事务处理和复杂查询处理等等。
在上述的趋势下我们来看云化数据库需要发展的一些核心技术和特性。
首先数据库的高可用将成为重点发力的地方因为这关系到云数据库的核心能力即简化用户运维和管理的代价。如果一款数据库产品在任何故障下用户都不掉线查询都不受影响那将极大提升用户对产品的信心简化背后管理的复杂度。同时如果数据库任何运维操作比如备份恢复、增删节点、Scale up节点等等都不会中断负载不仅用户在使用体验上更上一层楼也为数据库调优、提供更加自由和更多维度的方便。比如Scale up操作就可以更加动态地进行使得硬件能力更加贴近负载。
其次另外一个技术趋势就是扩展性包含各种能力的扩展存储/计算事务和复杂查询。比如事务存储是否可以按需扩展比如并发数是否可以扩展比如复杂查询能否根据数据量扩展分布式计算能力从而减少查询延时。
另外一方面这种扩展是否有瓶颈比如为提升事务吞吐我们一般会采用MVCC机制也就是所谓的多版本并发控制。在分布式下MVCC需要全局时钟或者全局排序的数列产生全局数列将对扩展规模形成约束因为产生全局序列的服务可能就成为扩展的瓶颈。Google Spanner的Truetime就是为解决这个瓶颈而设计的我们也设计了自己的时钟机制来应对这样的约束。
在具备了极高的高可用和多层次的扩展性以后弹性地引入将会为产品带来云化所必须的按资源使用的特性。以什么样的弹性颗粒度来进行弹性操作以多快的速度提供资源的扩缩用户负载和性能是否受到影响等等都是弹性技术所需要面对的。
另外一个层面的弹性叫Serverless大家可能都听说过或者看过别的产品在实现这方面的技术。所谓的Serverless实际上就是一个自动化的弹性按需使用不用时自动回收这需要上述这些技术的综合并且能够提供自动化的资源管理能力。
最后回到对用户应用性上的支持用户经常已经有很多应用跑在传统数据库或者跑在开源数据库产品上但是它没有云化的基础没有云化的这些技术的支持比如应用和高效的管控极致的高可用分布式扩展以及Serverless弹性等。如何让用户的这些应用可以顺利简单地以较低的代价迁移到云化产品上将是产品应用性的首要考虑。这其中维持SQL和生态的兼容性至关重要比如用户应用的SQL程序都不需要改动可以直接切换到云化的数据库是否可以减少大量的用户投入来改造应用。比如用户的应用仍然可以使用相同生态类的工具那么用户就不需要购买新的工具省去为适配这些工具而需要的开发工作。
往往这些方面的一些应用性的缺失是造成用户迁移的主要阻力。那么兼容性和易迁移性也将是我们考虑的重点。
所以概括起来我们对云化数据库技术趋势就是4个方面高可用、扩展性、弹性和兼容性。
六背景小结
基于以上背景最后我们总结出开源Polar DB应该走哪些路线然后实现哪些目标如上图所示。 在架构上我们要支持分布式技术上我们要云化同时解决客户的业务痛点在生态上拥抱开源。
二、 开源路线图
一开源路线图
基于背景、技术架构等方面的考量我们最终提出了开源产品的路线图。 首先开源的版本是基于 X-Consensus共识协议的高可用集群版本该版本主打的是高可用特性让用户可以快速自建一个和阿里集团内能力一样的数据库集群底座。
在实现极高吞吐的情况下支持Leader跟Follow间的全局一致性故障时保证数据不丢失并且Follow能够快速地升为Leader对外进行服务该版本解决用户对高可用的一些最根本、最初步的需求。
在第二阶段我们将推出基于混合逻辑时钟HLC的高扩展分布式版这个版本将实现Shared Nothing架构支持数据库集群的水平扩展解决单机存储容量受限问题并支持高并发和高吞吐的事务处理。
通过分布式事务和分布式时钟HLC做到分布式全局一致也就是说整个分布式数据库集群对外呈现单机数据库的特性用户应用像使用单机数据库那样获得ACID的支持。
在第三阶段我们把前两个阶段积累的大部分能力以插件化的形式改写包括分布式事务分布式SQL计算Sharding和弹性从而使得我们的工作对社区内核的开发是垂直的可以互补这样我们用户就可以快速地升级数据库内核版本同时保留我们提供的分布式弹性和高可用的特性。
路线图简洁地体现了我们对云化数据库的需求的理解通过开发和社区互补的工作实现对社区的增强同时保持社区的兼容实现生态统一最小化用户的使用和升级代价。
二X-Consensus 高可用集群版
下面介绍每一个阶段的主要特点。 我们第一期开源出来的项目称为高可用集群版顾名思义就是围绕高可用打造产品特性。
上图左边显示的是版本架构图这个架构中包括多个组件比如Leader、 Follower、Logger数据库节点其内核都是PG。CM集群管理组件负责系统和节点的启动、停止、集群操作等。
唯一核心的是称为X -Consensus的阿里自研的共识协议。在X-Consensus的支持下PolarDB实现了节点故障不能恢复的时候已提交数据不丢失并且保证对外一致性。
在实践层面上PolarDB仍然使用PG自带的Streaming Repliation而是通过X -Consensus共识协议保证节点间日志同步的位点的同步。这样做的好处是不改变内核的数据复制协议减少对内核的侵入性修改同时维护对工具生态的兼容。
这个选择反映了我们在开源项目中坚持的原则就是做社区的补充做的功能最好是垂直于社区的功能和发展共识协议的稳定性和正确性是其核心能力。我们使用的协议已经被使用在阿里集团内部业务成千上万的后台数据库经过多年的高压测试和实际负载的打磨相信其作为一个开源数据库协议被大家接受肯定也会成为这个方向的一个标杆产品后续这个协议将会作为独立开源产品被推出。
除了稳定性和正确性的保证本次开源项目还使用了该协议的多角色能力支持Leader、Follower和Logger。其中Logger没有数据库数据只保留一份日志参与选举但是不能被选举。Logger角色的引入将减少1/3的数据存储同时保留共识协议在下面一些的能力比如自动选主比如网络性能抖动时候对事务提交的影响。Logger可以参与选举就可以在自动选主时快速找出多数派当网络性能抖动时事务提交需要的日志同步可以在Logger节点和Follower节点间进行选择避免一些网络抖动的影响。
共识协议保证了快速和正确的选举数据库高可用的一个主要指标RTORecovery Time Objective反映的是从故障发生、用户服务中断到服务恢复的时间长度所以除了故障检测时间和选主时间外还包括升主时间和服务恢复时间二者和数据库的日志回放速度有关。
我们的测试发现当Leader经受非常大并发的时候Follower虽然实时地接收到了日志但是其日志回放是串行的所以Follower的同步状态经常落后Leader很长时间当这种压力持续的时候这个落后时间将持续增加甚至超过一个小时。可以想象如果Leader这个时候故障不能恢复那么Follower需要恢复一个小时时间才能完成升主并对外服务也就是说RTO可能会达到一个多小时以上这个是大部分在线数据库应用难以接受的。
所以根据这个需求我们的项目中实现了Follower的并行日志回放在保证回放结果正确一致外实现了Leader即使有很大的并发压力比如几十万TPMC的 TPCC负载Follower上的回放落后时间仍然维持在几秒甚至更小的时间范围之内。
所以这个版本我们的主要特性就是打造高可用的数据库服务包括共识协议的使用多复制角色的支持以及快速和并行的日志回放。
三HLC高扩展分布式版
下一个阶段我们开源的项目将会是一个Shared Nothing的分布式产品但仍然是基于第一期的高可用能力。这一期的核心是对PG内核的分布式扩展使得扩展后的系统能够最大限度地兼容单机SQL的能力包括DML、DDL等同时保持对外呈现单个数据库的ACID和MVCC的能力。
二者的目的就是保证分布式扩展后的这个系统对用户大部分应用仍然像单机PG那样兼容减少用户迁移和开发的工作量。 上图所示的架构中可以看到分布式Shared Nothing系统中出现更多的组件其中data node部分就是一期的高可用集群只是有多个这样的集群或称为基于X -Consensus复制组每个data node复制组中有Leader、Follower和Logger。通过X -Consensus共识协议保持数据一致性每一个复制组负责整个数据库的部分数据称为数据库分片。因为data node上实际上运行的独立的PG内核又称为数据库分片这些数据库分片其实就是多个数据库实例通过一个新的引入组件叫协调节点Coordinator nodes实现对外呈现单个数据库的能力。
也就是对用户来说看到的是一个数据库一个字典表和一套用户表但是在物理上每个数据库分片都存了用户表只是一部分数据。用户查询先路由到协调节点协调节点通过字典表和集群拓扑信息判断查询需要涉及的数据库分片并发送查询到相应节点获得各个节点的返回结果后协调节点还将负责将结果组合返回给用户。
除了查询和表逻辑对外呈现单个数据库特性外分布数据库的ACID和数据一致性也需要维护。为此我们引入另外两个组件一个是分布式事务管理TX Manager保证一个事务在多个数据库实例上执行的时候满足ACID。另外一个是混合逻辑时钟叫HOC其目的是保证所有事务有一个全局的排序从而实现分布式Shard的MVCC也就是实现分布式Shard的SnapShot。
相对于中心使用来说采用混合逻辑时钟的好处是混合时钟是分布式的没有中心在大规模集群情况下不会引入热点和瓶颈同时可以避免新的组件增加管理或者高可用的代价。
通过HLC对事务和操作进行时间意义上的全局排序不仅仅需要实现HLC的协议同时需要数据库内核的支持。这个支持我们在一期已经完成了是对PG SnapShot管理的增强作为替换原来的活跃事务列表为提交序列数或者叫CSN作为SnapShot这样分布式的HOC和单机PG的CSN机制整合实现了事务的全局排序从而为实现分布式MVCC提供这个基础。当所有的事务都按照时间排序时那原有的MVCC机制就可以正常地运行保证数据多版本支持读写操作的并行执行。
在分布式Shared Nothing下除了事务一致性外如何分布式地处理SQL计算也是一个非常重要的特性。就像刚才提到的我们首要的目标是最大限度地兼容单机的SQL能力和事务一致性一起保证用户应用可以快速在功能上适配分布式数据库系统比如对DDL的支持对简单DML的支持对带子查询的复杂DML的支持等等。
其次需要在查询性能上进行优化这中间的工作将非常地丰富比如发送查询到数据库分片节点的操作需要考虑是否整个或部分查询可以直接下推给某个或某些节点。查询计划在分布式下如何优化如何结合分布式和单机的优化器的能力如何在data node间交互如何结合MPP和SMP等都是我们将来所需要考虑的一些方向跟技术特性。
根据项目一期的基础data node已经具备高可用但是集群管理和分布式数据库的MetaData的管理都需要类似的高可用能力。我们需要一个基于X- Consensus的共识协议的分布式方案解决用户数据库协调逻辑集群管理和Meta管理的统一的高可用问题所以我们将会在这个版本里实现分布式的高可用。
总体上二期将推出一个具备完整SQL和数据一致能力的分布式Shared Nohting数据库其主要特性都是对现有单机PG的补充、增强和扩展这些能力的大部分将在第三期成为插件满足用户快速升级的需求。 四 Sharding 和 插件化版 第三期我们将在前面两期基础上持续地增强分布式能力、云化能力以及PG社区兼容能力上方的架构图反映了我们在第三期的主要思路。
首先DB Node作为核心组件提供单机数据库内核能力和分布式计算能力同时管理每个Shard和跨Shard的事务保持数据一致性DB Node自己通过X- Consensus共识协议复制数据到Follower维护节点级别的数据和逻辑冗余有助于故障Shard快速恢复。每个DB Node的功能将通过对PG社区内核支持加上分布式和高可用的插件的Patch实现这些功能。
在DB node上我们维护一个PolarDB服务层提供像集群管理各种运维操作负载路由以及中心时钟是一个Option的需求。相对独立的服务层将有助于用户应用的对接不受内核升级变化的影响服务层可以随环境变化针对不同云提供商和专有云来进行提供支持。
第三期主要的增强体现在以下几个方面。首先我们加强了Sharding提供了细粒度的Sharding能力细粒度Sharding主要加强了PG原生内核相对单机化的架构计算存储相对耦合不利于云化和分布式下弹性和扩展管理。通过细粒度Sharding使得用户表在存储层实现一定程度上的隔离支持在线的Shard迁移进一步提升分布式的能力和云化弹性能力。
同时通过统一化组件将协调节点和data node合二为一成为统一的DB Node和数据库相关的功能在一个组件里面提供使得云化部署和管理更加的简洁。最后通过分布式和Sharding能力的插件化保持对社区版本的兼容保证用户可以快速地升级。
至此Polar DB开源项目通过三步演进实现了对PG内核的分布式扩展保证分布式一致性同时兼容PG SQL能力和内核版本的升级具备云化的弹性和管理的简洁性。当然后续仍然有很大的优化空间和很多特性会持续推出比如分布式计算的持续优化、混合负载、HTTP等。
五路线图小结
最后用下图来小结我们路线图的目标和希望达成的方向。 我们期望开源PolarDB是一个高扩展分布式、细粒度、弹性、基于共享协议的高可用以及易于兼容社区的插件化每一个目标都反映了我们对云化数据库基础需求的理解。
三、开放问题
最后有三个相对开放的问题。 第一个问题是关于分布式和集中式数据库的市场的考虑从个人角度来看传统数据库以集中式为主市场也是如此将来在很长时间内集中式仍然会是主体。分布式在完善功能、构建生态上会不断地进步可以占据一定的市场份额。如果分布式能够兼容集中式的模式那么分布式产品既可以当做集中式来使用还可以按需扩展成分布式那么更多市场份额就可以期待这也是我们为什么选择把开源产品做成分布式主要的原因。
第二个问题是关于分布式和计算存储分离的关系个人理解二者是不冲突的是垂直的关系。分布系统是可以使用集中式的存储甚至更加广义地讲很多云设施可以当成集中式来使用比如云的块存储对象存储等等。分布式可以通过自身的扩展性更加有效地利用这些云存储的带宽和IOPS所以我们的分布式开源产品将来也会做针对存储计算分离或者是利用云存储这样的架构的优化跟提升。
第三个问题是关于扩展分布式数据库生态我们既然已经有了分布式数据库它天然就具备一致性扩展性和分布式计算等能力。那么我们是否可以通过新的数据访问接口和引入新的用户定义计算功能来扩展它所能支持的服务能力比如将它扩展成其他服务的存储系统扩展成其他服务的计算执行系统这些都是非常值得我们去思考的但是前提条件是我们先打造出一个完整、功能完善、稳定的开源分布式数据库这样在此基础上我们就可以做更多更加有意思的多生态的工作。
原文链接
本文为阿里云原创内容未经允许不得转载。
