网站权重怎么查询,前端和后端哪个好学,免费seo排名软件,Wordpress火车头采集标题前乱码摘要#xff1a; 4月17日#xff08;巴黎时间#xff09;阿里云POLARDB走出国门#xff0c;亮相ICDE2018#xff0c;并同步举办阿里云自有的POLARDB技术专场。在会上#xff0c;阿里云进行了学术成果展示#xff0c;从而推动Cloud Native DataBase成为行业标准。4月17日…摘要 4月17日巴黎时间阿里云POLARDB走出国门亮相ICDE2018并同步举办阿里云自有的POLARDB技术专场。在会上阿里云进行了学术成果展示从而推动Cloud Native DataBase成为行业标准。
4月17日巴黎时间阿里云POLARDB走出国门亮相ICDE2018并同步举办阿里云自有的POLARDB技术专场。在会上阿里云进行了学术成果展示从而推动Cloud Native DataBase成为行业标准。以下为阿里云资深技术专家蔡松露演讲实录现在我给大家介绍一下我们的云原生数据库-POLARDB。大家可能要问到底什么是“云原生数据库”云原生数据库的标准是什么我们是如何定义的以及为何如此定义现在我们先把这些问题放一边我们稍后回答。现在我们看一下一个云原生的数据库大概是什么样子门槛是什么特性是什么首先云原生数据库必须有优越的性能有百万级别的QPS其次必须有超大规模的存储可达到100TB的存储空间在云上0宕机能力也是非常重要的最后一个也是最重要的云是一个生态系统数据库必须兼容开源生态。云原生数据库就像一辆跑车一辆跑车可能有很多特性比如外观、速度但是一个有这样外观和速度的车不一定是跑车。所以回到我们的问题云原生数据库的标准是什么在回答这个问题之前我们看一下数据库的发展历史。我从4个维度来看一下数据库的发展历史首先从数据规模上来看我们生活在一个数据大爆炸的时代其次某些数据库理论发生了演变尤其是CAP理论我们在算法理论上也有所突破第三用户和应用场景也在发生变化第四基础设施也在从传统IDC迁移到云上。为什么会有数据大爆炸呢数据是如何爆炸的呢这是我引用的互联网女王米克尔的报告你可以看到互联网历史可以整体分为三个阶段第一阶段我们称之为PC互联网数据主要由PC产生第二个阶段可以称之为移动互联网数据主要由智能手机产生第三个阶段是IoT从现在开始几乎所有的数据由物联网设备产生可能是你的手表、冰箱、家里的电灯和汽车可能是任何设备。随着数据大爆炸也带了很多挑战大规模的数据意味着用于存储和分析数据的成本也大幅上升搬运和分析数据也变得困难总之数据很难被利用。最近这些年分布式系统的一些理论也有了重大变化CAP就是其中之一CAP理论在2000年引入在这个理论中C代表一致性A代表可用性P代表分区容错性这个理论的核心观点是在P发生时C和A不可能同时被满足CAP是一个伟大的理论但是对CAP理论也存在很多误解其中一个误解就是C和A是互斥的所以有些系统选择放弃其中一个来满足另一个比如很多NoSQL数据库但是实际上C和A的关系不是0和1的关系而是100%和99%的关系。现在我们也可以把P问题建模成A问题P问题主要由网卡、交换机、错误的路由配置等故障引起我们考虑一下这样一个例子一个节点因为网卡错误而被网络分区到这个节点的请求会失败如果我们能够将这个节点自动剔除那么请求会重试并且会被发送到一个健康的节点事实上当一个节点宕机的时候我们也采用同样的处理方式所以基本上P和A问题在某些情况下可以看做是一类问题。我们如何把失败的节点自动剔除并且能够同时保障数据一致性呢我们可以用PAXOS算法来达到这个目的PAXOS能够保证一致性而且PAXOS只需要过半数的操作成功即可所以当有网络分区、宕机、慢节点出现时我们可以容忍这些问题节点并做到自动剔除。如果超过半数节点被分成了若干个分区这时我们选择一致性牺牲可用性但是在现实世界中这种情况极少发生所以在大多数情况下我们可以通过将P问题建模成A问题来同时保证完整的C和A。20年前只有政府和一些巨头公司会选择数据库现在从巨头到小微企业所有的业务都会跑在数据库上而且对数据库的需求也在发生变化。首先数据库必须灵活有时我们需要做一个市场活动比如黑色星期五我们不知道当天的真实流量有时会有突发的热点信息这时流量会有一个飙涨并且是不可预测的我们希望数据库能够灵活地进行扩展其次随着全球化的发展贸易也越来越透明很多用户的业务规模比较小意味着利润也很少他们需要更经济的解决方案目前的客户要求也比较严格并且对延迟很敏感数据库延迟越低带给客户的损失会越小最后数据库必须对每一个潜在的问题做到反应迅速并能从问题状态中快速恢复过来。总之目前对数据库的潜在需求是弹性、低成本、高性能、业务永续。现在所有的一切都是时刻在线的在云时代以前数据散落在IDC中现在数据都位于数据湖中数据会在线产生并且同时被应用到训练模型中所以这些数据是在线产生、在线分析并在线应用我们的生活现在也是时刻在线的比如衣食住行、工作、社交、娱乐等都是可以在线解决的你可以用一部手机足不出户就能活下来现在你的客户也是时刻在线的他们遍布世界各地无论白天还是黑夜一直在线。在目前的中国70%的新型企业都因数据挑战而对业务产生了影响他们面临的问题主要有高成本他们负担不起商业license和专业的工程师他们有很强的发展的意愿但是数据能力不够强对他们来说数据备份、数据挖掘和问题排查都是非常困难的事情他们的数据目前像孤岛一样散落分隔在多个地方数据无法做到在线并被浪费但是数据在持续增长爆炸这些数据很难被存储、转移、分析并使用根据上述演变趋势和接踵而来的数据挑战我们认为一个云原生的数据库应该符合以下标准。首先一个云原生数据库不仅是一个TP数据库也是一个AP数据库TP和AP融合在一起我们称之为HTAP我们从这种架构中获益良多其次云原生数据库必须是serverless的有了serverless我们可以大幅削减成本最后云原生数据库必须是智能的就像一个顾问可以承担很多诊断和管理工作通过这些工作我们可以提升用户体验并让用户不必再关心这些枯燥棘手的事情。接下来我们详细阐述一下。在HTAP中TP和AP共享一份存储对于分析来说不存在任何数据延迟由于不需要数据同步我们也不必把数据从主节点同步到一个只读节点这时数据是实时的对于时延要求比较苛刻的应用来说非常有益当TP和AP共享一个存储之后至少会省去1个副本的成本对于计算层AP和TP通过容器来进行隔离所以AP对TP没有任何影响而且有了这层隔离之后TP和AP可以轻松做到分别扩展。有了serverless产品规格或版本升级时可以做到0成本计算节点会跑在一个轻量的容器中客户端会话的生命周期比较短所以当我们进行滚动升级时客户端几乎感知不到任何变化有了serverless可以轻松做到按需使用按存储付费计算成本也很低并且你可以为不同的业务模型指定不同的存储策略对于忙的业务可以使用更多的内存和SSD对于闲置的业务可以把数据放到HDD盘上这样可以大幅缩减成本。提到智能智能顾问会分析实例产生的如CPU/存储/内存使用率和水位线等数据给你一个SQL或索引优化建议在外人看来智能顾问就像是一个DBA并把用户也武装成一个专业的DBA当数据链路上有问题发生时由于数据链路又长又复杂所以我们不清楚问题到底出在哪里当我们有一个监控和诊断系统后我们可以轻松地去诊断整个链路并迅速给出根本原因智能顾问也能负责其他如成本控制、安全、审计等职能。在上述若干标准和门槛的指导下我们打造了一个全新的云原生数据库-POLARDB我会从架构、产品设计、未来工作等几个方面全方位阐述一下POLARDB。这是一个POLARDB的架构大图上层是计算层下层的存储层存储和计算分离他们中间通过RDMA高速网络相连接所有的逻辑都运行在用户态绕过了linux内核在用户路径上我们实现了0拷贝我们同时实现了一个RAFT的变种ParellelRaft它支持乱序提交比传统的Raft速度要快很多我们同时使用了大量新硬件既可以提升性能又能降低成本POLARDB也是面向下一代硬件而设计。对于计算节点只有一个写入口R/W节点负责所有类型的请求包括读和写请求其他节点都是只读节点只能处理读请求对于存储节点我们通过ParellelRaft算法来实现三副本一致性写。我们为何要做存储计算分离呢首先我们可以为存储和计算阶段选取不同类型的硬件对于计算层我们主要关注CPU和内存性能对于存储层我们主要关注低成本的存储实现这样存储和计算节点都能做到定制化和针对性优化分离之后计算节点是无状态的变得易于迁移和failover存储的复制和HA也可以得到针对性的提升存储现在可以方便地池化以块为单位进行管理所以不再会有碎片问题、不均衡问题并且易于扩展在这种架构下也很容易实现serverless当你的业务比较空闲时你甚至可以不需要任何计算节点。在POLARDB中任何逻辑都跑在用户态一个请求从数据库引擎发出然后PFS会把它映射成一组IO请求然后PolarSwitch会把这些请求通过RDMA发送到存储层然后ParellelRaft leader处理这些请求并通过SPDK持久化到磁盘上同时再通过RDMA同步两份数据到两个followers在整个路径上没有系统调用也就没有上下文切换同时也没有多余的数据拷贝没有上下文切换加0拷贝使得POLARDB成为一个极快的数据库。这是POALRDB文件系统-PFS的详细说明PFS具有POSIX API对数据库引擎侵入性很低PFS是一个静态库并被链接到数据库进程中PFS是一个分布式文件系统文件系统的元数据通过PAXOS算法进行同步所以PFS允许并行读写为了访问加速在数据库进程中有元数据的缓存缓存通过版本控制来进行失效操作为了便于大家理解PFS这是PFS和传统文件系统的一个类比。我们使用ParellelRaft来同步三份数据ParellelRaft是Raft的变种之一Raft不允许乱序提交和日志空洞这些限制让Raft性能比较低、吞吐比较小在ParellelRaft中我们允许乱序提交、确认、和应用事务的语义和串行化由数据库引擎层来负责对于空洞我们有一整套完整的catch-up机制这是一个非常复杂的过程在VLDB 2018的论文中我们有详细论述这篇论文刚被接收。在POLARDB中我们使用了一些新硬件并最大化利用这些硬件的能力除了RDMA我们还在研究open-channel来最大化SSD的价值我们也在通过3D XPoint技术在加速存储层。这是POLARDB和RDS的对比压测结果我们使用sysbench来进行压测紫色的柱子代表POLARDB粉色的代表RDS通过这些数字可以看出在使用相同资源的情况下POLARDB的平均读性能是RDS的6倍平均写性能是RDS的3倍所以这个提升是巨大的。我们接下来看一下POLARDB的产品特点性能上很容易扩展到100W QPS并且延迟小于2ms存储最大支持100TB弹性上可以很方便做横向和纵向扩展并且在规格升级时0宕机无干扰对于兼容性会100%兼容MySQL在可用性上当有错误发生时我们会选择一致性牺牲可用性所以目前我们承诺3个9的可用性在数据可靠性上我们承诺5个9。在POLARDB中读和写被分离到不同的节点上只有一个写节点写节点可以处理读写请求可以有多个只读节点写QPS最多可达13W读QPS可以很方便地扩展到几百万。对于可扩展性所有节点都可以做纵向扩展只读节点可以做横向扩展实例的存储可以做纵向扩展存储集群可以做横向扩展当读写节点和只读节点之间做failover时可以做到0宕机。对于数据迁移你可以通过加载一个OSS类似AWS S3上的备份来启动你的数据库也可以通过将POLARDB当成RDS的slave来从RDS实时复制数据也可以利用DTSdata transfer service数据传输服务来从RDS和其他数据库迁移到POLARDB。对于数据可靠性我们可以做到1个region内可用区内多个可用区之间的failover你可以在其他可用区启动一个standby实例并且使用redolog来进行复制也可以在多个region之间failover我们通常使用binlog进行复制对于备份我们可以秒级打出一个snapshot然后传输到OSS上。下面是POLARDB的一些未来工作目前POLARDB还只是个婴儿我们仍然有大量工作需要去做在引擎层我们将会支持多写目前POLARDB是一个共享磁盘的架构未来会是一个共享所有资源的架构比如在计算层我们会引入一个集中化Cache的角色来提升我们的查询性能我们也在移植更多的数据库到POLARDB比如更多的MySQL版本、PostgreSQL、DocumentDB等。在存储层我们会使用3D XPoint技术来提升IO性能我们也会通过open-channel技术在提升SSD性能将来我们也会将更多引擎层的逻辑进行下推尽量减少更多的IO让计算层更加简单。关于学术我们的基本思想是学术要在工程落地工程要有学术产出没有单纯的工程或者学术。我们团队已经向Sigmod和VLDB提交了数篇论文最近这些论文将会出版大家会看到更多的关于POLARDB和它的分布式存储的详细的信息我们也正在欧洲进行招聘我们在巴黎和德国都设有办公室。原文链接干货好文请关注扫描以下二维码
