2017云栖大会POLARDB专场，阿里云资深技术专家林晓斌带来最流行的高性能关系型数据库是如何在云端打造的演讲。本文主要从数据库云服务目标开始说起，又介绍了经典模式痛点，接着提出了下一代数据库需要解决的问题和方案，最后做了简要总结。
以下是精彩内容整理：
数据库云服务的目标
做云数据库的目标，让DBA创造更大的价值，不仅阿里巴巴自己的DBA，还有客户的DBA，以及没有DBA的公司，担负DBA责任的开发人员，让这些人能够更加省心，这是我们做云数据库的目标。
基于这个目标有五个指标，包括可用性、可靠性、安全性、可扩展性和可诊断性。
按重要性来说，要从安全性说起。安全包含了两点，一是数据本身的安全，一是对于数据泄露的安全。在安全上我们做了很多工作，比如现在允许用户通过配置，让数据落地后是加密的，也就是说你不用担心数据被拷走的问题。我们还有这样的设置，现在阿里云的业务人员无法访问数据库，让用户在前台授权才可以做到，通过这种方式提升它的安全性。
在可靠性上常做备份恢复到任意时间点的功能。用户出现误删数据库，或者把表改错了，我们会提供恢复到任意时间点的功能。
常见扩展性其实很好理解，就是通过图表。当我们自己在内部维护，刚开始近千个实例，后来发现实例数和DBA的数目呈比例了，阿里云有10万多个实例，但没有1万多个DBA，只有四五个。中间有一段镇痛，怎么让实例数增长的情况下，运维人员不要线性的增加，可诊断性也是体现云服务是不是成熟的标志。
经典模式
公有云上大量的实例都是双节点结构。从2015年开始，我们就默认改为semisync，甚至很多公司，包括一些友商默认还是用异步模式。如果把它设成最安全的模式就会比较吃亏，用户要找两个云厂商做测试。在阿里云，数据的准确性、可靠性是第一位的，所以在2015年后，我们把默认改为双节点，保证数据不丢。
都有哪些痛点呢？比如分钟级扩容，包括电商也会碰到这样的问题，很多小的电商在云上做，用户不用告诉我们的。去年“双11”的时候，我们运维团队的要求是“双11”那天要做到零干预，前几年已经做到零故障了。有一个公有云的用户，也是一个电商网站，他没有告诉我们，等到他们说准备半年的挂了，他们买了两个很小的实例，“双11”之前也没有压测，那一天压力一上来马上打爆，临时加机器已经来不及了，数据量又大，我们从2个节点扩到8个节点，花了20个小时的时间把扩容做起来，最终帮助他们把东西卖出去。分钟级扩容，后面慢慢是一个刚需。
超大容量，迁移数据第一步就是备份。一旦发起备份，看上去备份在内库备，意味着这时候是隐含的单点系统，主库不敢挂。我们的需求是备份肯定要做，但是要让备份最快的做，而且最好做的不影响其它。成本来说也是用户的痛点。
下一代数据库需要解决的问题
从研发的角度以及数据库本身发展角度来说，还需要解决哪些问题？比如：
- 硬件红利，其实数据库这几年来，尤其是MySQL在过去20几年来的发展，它还是没有真正把硬件红利榨干。好像一些新的数据库，NewSQL数据库，把小量企业变成大批量企业，读也是这样。很多硬件已经不再是RDS瓶颈了，这时候数据库应该考虑反过来，尽量多的把随机写变成数据写，还有备份要吃带宽，备份是整个拷走。整个设计理念就是按照机械硬盘在做，虽然慢慢在改进，但改进量还不够多。
我们数据库怎么用好现在的硬件红利？最近推出的POLARDB，数据系统是从网络取过来的，数据从网络取过来不从本地拷反而慢，怎么做到性能翻倍呢？POLARDB底层存储已经做到网络上读取的性能，目前已经达到和本地一样快，而且还有空间，以后就会超过。它是一个网络集群，它的LBS和带宽不再受限了，信息越多越细节，对终端用户的体验就越好。有更多的信息可以参考，用户的体验就更好，我们怎么通过硬件红利体现数据库的能力更加扩大，再让用户利用数据体现到他们的产品，让终端用户提升用户体验，这是我们需要解决的问题。
- HTAP，现在我们说的MySQL一般是做事务，甚至比较长的一段时间，MySQL做什么最好是当天利用，越简单应用，越不容易出BUG。越简单，意味着需要别的能力时，就需要拿别的系统补充。把MySQL当KV用当然可以，我现在要一个复杂的交易，需要找另外一个系统过来做，这个系统专门做交易，接下来要做数据分析，又拉一个系统过来做，结果发现一份数据要从好多地方开始大量的数据同步，以前做数据同步还可以，现在都是分钟级别了，这是一个矛盾，越来越大。数据越来越大，一个要分析的快，一个是数据量变大，拷起来快。最好能把系统放在一起，哪里写就在哪里读，这样就很好了。
- 智能服务，阿里很多基础运维DBA越来越少了，以前DBA要搬机器，现在已经没有这个需求了，后来要经验丰富，意味着不容易在云上扩展。其实很难要求一个创业公司里有一个经验丰富的数据库专家，我们怎么让用户拥有数据库专家，如果只有一个客户，支撑起来比较容易，当我们有10万个客户时，需要考虑怎么让一个智能系统帮助我们服务。
解决方案
POLARDB
怎么解决痛点呢？POLARDB基本的想法是这样的，数据和存储分离，计算和存储分离。图上一个节点，主库、读库、远程访问数据，解决分钟级扩容。以前我们怕别人拷数据，现在不用怕了，找一个机器把进程开起来就可以了。本地磁盘大小和备份时间的限制容量，以前一个数据有三份拷贝，备份都是分片备的，不会对系统造成很大的冲击。
HybridDB
现在数据量的问题解决了，就是拷贝，如果只有POLARDB一个单点，分析这个问题还是没有解决，它还是偏向事务的系统。我们有HybirdDB，数据可以直接在这里读取，算完给用户。列后引擎可以认为用户独立入口，当用户来使用时只看到这个点，语句可能不一样。分析类语句有定制语法，兼容hadoop的语句。
CloudDBA
由于磁盘老化，做DBA用户和你说语句慢了，我们看看语句是不是错了，表结构对不对，需要查很久才能怀疑到硬件坏了。另外就是网络，网络有很多层，我们会花好多时间在这个事情上。链路上做了全链路监控，从客户端到服务端，每个节点都采集，先写后读，他认为这个事情是并行的，是两个语句写下去的，用户根本查不出来的。现场ID不一样，说明是从不同现场发下来的。以审计日志为基础，我们现在做的POLARDB，已经开始做公测，后面用户可以自己在入口上升系统。我们把问题暴露出来，并不是所有问题用户都需要关注，有了完整系统之后，希望把系统的能力覆盖给客户。
总结
我们想让所有公司DBA卸掉繁重机械的工作，以前是搬机器装实例，大家已经过了这个时代了。下一步要做什么事情？扩容、缩容，大促容灾等体系设计，这些不是体现DBA的价值的，真正体现DBA价值的能力是他们对公司业务的了解，DBA风头最盛的是Oracle时代，因为Oracle很稳定，他们做业务的架构师。希望阿里云数据库让我们自己做到Oracle那样的能力，让DBA业务人员可以摆脱低端的工作，了解公司业务，成为业务架构师，创造更大的价值。
