云数据库前沿---华为云数据库技术和行业应用

文章转载自华为云数据库论坛

黄伟（华为云数据库资深架构师）：感谢主持人，感谢各位来宾，技术方面的内容一般是稍显枯燥的。在正式开始之前，我先做一个小调查，今天来的人有多少是做技术方面工作的请举一下手。看起来还是有一些的，能够愉快的聊下去。

云这两年是比较火的，实际情况是怎样的呢，我们圈里人都很熟了，但是在业内怎么样？我先分享一部分数据，当然云上的数据是比较难获取的，实际上我今天跟大家分享的是一些大企业的数据，更准确的说是世界500强中的中国企业还有中国的民企100强，它可以给我们一点点参考。500强中中国企业业务上云的大约占了一半，其中大陆的企业比例稍高，港台的企业比例就比较少了。在世界500强的中国企业中按照领域来分的话，可以明显的观察到金融这个行业，这个可能来自于金融这一块需金融风控和大数据分析，需要用云计算来分析它的业务。我们知道中国的500强大部分都是央企和国企，在民企这块大约20%的上云比例。

另外一个是IDC行业投资趋势的分析，16年大约有7%，18年大概11%，这个是公有云，但是如果把公有云和私有云合起来，在2021年大概会占到38%，因为我们知道在整个IT的投资中，大头是运维和人员的投资，所以这个份额还是比较大的，这一页告诉我们我们国内的企业步子迈得比较快，央企的步子还更大一些，同时也告诉我们这个领域里还大有可为。

云数据库只是业务上云的一部分，对于我们的企业来说或者对于我们的业务来说，需要数据库和业务一起上，有三种模式：第一种是把云当做普通的VM来用，买块云硬盘挂起来，安装数据库软件和业务软件，这个模式现在用得比绍少，但是还有人用，它也有一些好处，第一个使用习惯，第二个是应用不用修改，第三个它确实运用到云化的基础设施的便利，下了单就可以拿得到，云上的可靠性一般会比我们自己搭建的要好一些；第二种是现在比较多的，应用不做，或者几乎不做改造，把数据搬到云上，也就是数据库这部分不需要自己搭建，直接用云数据库服务，这种它的好处是按需付费的，也不用单独考虑license，另外修改规格/扩容也很方便，还可以提供跨AZ/Region的容灾，问题是如果刚刚用上可能不放心，就像最开始第一个人把自己的钱存到银行里去，会担心他会不会跑路；第三种是面向云设计，这个更多的来自于互联网企业，它要极大的扩展性，极高的性能，这种情况下应用本身要做改造，它的可靠性是可以定制的，也就是我想要多大的可靠性几乎都可以做到，它的缺点重构需要代价，需要钱，还需要时间，还需要足够的技术能力。

我们今天的主题是云数据库，云数据库的方案也做一个简单的总结，也有三种模式，第一种就是传统的，就是把MySQL、PG、SQL Server等传统数据库直接搬到云上去，传统数据库的可靠性方案在云上都可以用，大家都比较熟悉；第二种是前几年比较流行，这两年可能慢慢不那么流行，但还是在用，就是所谓的集成式，一个数据库联邦，就是通过一些数据库中间件，把数据库整合起来，可以把数据分片，不同的数据存在不同的shard中，这样它对外呈现出来是一个“大”的数据库，从规模和性能可以做到很高。比如说我们做游戏行业，有不同的大区，或者由类似4S店这样不同的地区自然分割，利用多个分片来提升性能，解决规模问题；第三种就是分层解耦式，面向云的基础设施来构建，同时保持SQL的兼容。怎么保持兼容，就是SQL引擎那一部分保持，存储引擎利用我们云上的特点:弹性/可靠性建一个分布式系统出来，所以这个规模、性能可以做到极高。

前面我们讲的是有点大比较虚的东西，后面会讲得细一点。

刚才提到的数据库，所谓的云数据库，云在哪里？第一个是服务化，在座的各位假如说让你去做一个云上的数据库，第一反应要做什么？这是直观的反映：我要给用户一个界面，可以是SDK或者Console，客户可以申请要一个什么样的数据库，接下来管理面就申请资源，拿到计算/存储/网络的一些资源，拿到这些资源之后安装数据库的实例，安装完实例做一些参数配置，之后把实例的信息，包括资源、容灾备份、HA、审计等信息保存起来，就可以告诉用户说在哪里有一个什么样的数据库你可以用了，然后客户就可以按照返回的这个数据库的地址/端口去使用数据库。直观的这一部是比较容易去理解的，在线下也都是要做的，往往比较容易忽视云化的优势，觉得好象数据库的云化也没什么意思，也是这个鬼样子，接下来我们往下看。

下面这个是客户可以看到的，应用和引擎中间可能会有一个代理来做切换，后面会有一个HA，在主异常的时候做一个倒换；如果涉及到线下的数据库还包括数据迁移，后面会有备份、审计、运维、日志管理等，这是我们比较容易理解的，想象中好象也没有什么，但是类似于冰山模型，看得到的往往不是全部。下面我们把这部分稍稍打开，看看云化做了什么，或者说我们在云上为这个数据库做了些什么其他的东西。

对用户的应用来说，可能需要一个云上/云下的协同，所以我们需要给他一个弹性IP，在外网可以访问，在内部也可以访问。用户业务和DB之间有一个proxy，这个Proxy可以做得很简单，比如做一个IP的切换，也可以做得复杂，做一些安全、审计、清洗类的加固。下面是比较关键的，相比较云下来说差异很大的地方，当我们在云下的时候，当我们涉及到CPU、内存或者存储不够了要扩展，或者当这个游戏过了最好的阶段，我需要把这个配置降下来的时候，这个时候非常的麻烦，但是在云上来说可以支持所谓的弹性伸缩，这种弹性伸缩往往是可以业务无损或者近似无损，也就是说当我需要由2U8G变成8U32G，或者容量由100G变成500G，这个时候的业务是没有损伤或者几乎无损伤，它可以直接的带着业务来做这个弹性伸缩。

接下来我们再看看存储，在线下我们也可能选择买几个硬盘做raid，但这种成本会比较高，可靠性实际上也没那么高。在云上因为云上的云盘一般都是3副本，并且是多AZ的，这样的话它高达7个9的数据存储可靠性，在这种情况下相比较我们在线下的硬盘，大概每年有1-2%的失效，可靠性有数个数量级的提升。在这种情况下，我们几乎不用考虑数据本身会丢失，因为多副本的情况下，硬盘故障了，云基础设施可以重新找一块硬盘来代替它，这些都是自动完成的。在云上我们仍然需要备份，备份的主要目的可能就变了，不是说我这个数据所在硬盘坏掉，而是说因为应用，或者因为一时疏忽，在这种情况下我们需要把过去的数据再找回来，这个时候一般的云供应商都可以提供长达一个月以上的连续备份，并且是任意时刻，可以回到过去备份周期内任意一个你所需要的时间点的数据。对于初创企业或者传统企业来说，DBA或者开发人员在数据库方面可能没有那么牛，在网上我们经常看到别人问到底应该用PG好还是用MySQL，到底这个参数要怎么配。在云上一般这个问题会简单，因为云的供应商一般会给大家提供一个默认的参数模板，默认的较优配置；同时线下数据的迁移会变得更简单，云供应商一般会提供一个迁移工具，把两边连上，可视化的，而且对业务的损伤非常小的迁移到云上。这里还有一个在线下炒得很厉害，在云上也变得很简单，就是主备模型下，可靠性怎么保证？异常时，两边都认为自己死了，或者两边都认为自己还活着，导致业务损伤，在云上一般可以使用所谓的跨3 AZ的强一致性协议来保证活着的确实是活着的。

到这里实际上我们还没有涉及到DB引擎本身，或者说云化本身就可以给我们提供足够好的东西，这也就是为什么很多的初创公司最先采用云上的服务。

我们说的冰山之下就是数据库引擎，数据真正被管理和处理是由引擎来做的。引擎多数的云运营商会提供两大类：一类是原生的引擎，因为毕竟云对一部分人来说还是一个很新的东西，一部分人基于安全或者习惯的原理，还是会用他熟悉的那个，就像银行刚刚开业的时候，有很多人说我还是把钱放在罐子里安全一些。还有一些商业的数据库比如SQL Server不开源，就要用到微软原生的。第二类是所谓的优化引擎，刚才我们提到云上的基础设施和线下搭建的还是有很大的差异，多数的云的供应商会提供一个更好的云上的DB引擎供选择。当然这是供应商的角度来说，从用户的角度可能两种都好，根据自己的情况来选。优化引擎一般提供更好的性能或者更好的可靠性，或者完全面向云的设计。

现在我来介绍一下这部分的内容，我还是以MySQL生态为例，先介绍小的优化，小的优化是说不做大的改变但是我让云上的性能比自己安装的要好，并且要好很多，比如说MySQL现在很多人喜欢5.6，5.7出来了，它有一些地方和5.6不一样，用户不敢用。但是5.7中有一些好东西，比如说日志的并行重放，所以我们可以把这部分先挪过来，它的改动比较小，是可控的。再比如Percona是一个知名的性能优化的MySQL版本，一个线程服务多个链接，原生的MySQL默认是一个链接起一个线程，这样子很多宝贵的资源就放在连接上，而没有放在它应该做的事务处理上。

做了这些小优化后，从我们自己测的情况看，在32个连接数下HWSQL会好一些，但是没那么好；随着连接数越来越大，比如一个最好例子，到了八千多个的时候，HWSQL的性能大约是MySQL的十倍以上。看右边，主备的场景，红色的是HWSQL，蓝色的线是原生的MySQ。在主库是同样性能的情况下，备库的事务的执行数，红色的这部分和蓝色的这部分不知道差了多少倍了，结果就是备库原生MySQL的压力比较大，七千个TPS的时候，这部分会离主库越来越远，HWSQL基本上变化很小。这个图变化的含义是什么？MySQL5.6原生没法把主库的TPS跑到七千以上，只能降下来，从而让备库能够跟得上，但是HWSQL能够跟得上。

讲了小改进，现在要讲一些所谓的大改进，还是以MySQL为例，但是对其他数据库基本上都是同样的。用户首先看到的是一个VM，下面挂着一块或者多块盘，刚才我们讲云化的东西也提到了，虽然我们在用户层面看不到，但是实际上云供应商为了更高的可靠性，也就是说用户每一个数据下来，在云盘上会放上一个三个不同的机架上的三个不同的服务器的三块不同的盘中去，这样的话任何一个结点或者任何一个机架，或者任何一个数据中心宕掉了，那么这个系统仍然是可用。在这种模式之下，MySQL的问题就来了，盘上有这么多数据，MySQL在磁盘上还会双写，写两份。这种情况下会给云上带来极大的负担，大量的数据加上双写，占用网络带宽，同时时延也会增加，整个事务的时延会增加，因为当我前端执行一个事务的时候，后端可能要7次磁盘操作，所以这个是极大的放大；另外一个就是成本上，好消息是这个成本是供应商承担的，跟消费者没关系。

接下来看看我们或者业界是怎么解决这个问题的，这个相比较原生MySQL是一个巨大的变化，类似于单体应用转换到微服务。第一个事情就是计算节点和存储节点分离，分离的结果就是大家可以各自做好各自的事情，计算结点可以独立的去扩展，存储结点也可以独立的扩展，并且存储结点可以和备份容灾做到一起。我们都知道存储也是要进行容灾，数据库也要做一份容灾，存储要做事务，数据库也要做事务，那大家何不合到一起做了，这样的话整个的开销是最小的。这样做了之后还有一个是log，我们要写下来的数据有这么多，其实因为它是单点，在它原生的设计逻辑里只有一个或者只有一台服务器，下面可能有一个或者几个组的盘，但是我们现在经过这种云化扩展之后，存储结点是放在不同的AC里的、不同的机架上的、不同的硬盘里。数据是足够可靠的，所以我们不需要这么多数据下来，只需要log就够了，也就是计算结点下到存储结点的数据只需要原来的七分之一就可以了，自然我们的网络带宽占用和时延都提升了，同时性能也可以极大的提升。

同时我们做可靠性的时候，有一些朋友可能熟悉两地三中心，就是隔很远至少要隔几百公里的两个地方各建一套数据库系统，这样保证地震、火灾、洪水不至于把数据库破坏了，但这样隔得太远性能又比较差，所以在主系统所在地域再建一个备，这样本地偶发故障下业务还可以继续运行。采用了分布式设计之后，可以支持多达15个读节点，在主节点异常时，任何一个读节点都可以升级为主，相当于N中心了。

在这样面向云的设计下，我们整个系统的性能相比于原来就有很大的提升，可以看看这个图，这是我们Taurus的一个测试结果，相比于MySQL有三到五倍的提升，在读这块大概有5倍的性能提升，在写这块大概有3倍的性能提升。面向云计算的设计也是我们现在版本发展的一个方向，我们希望通过这种方案能够体现我们的竞争力。

从我的理解上来讲，对一个业务来说，当我们数据库去做选择的时候，比如说MySQL和PG经常拿到一起说，数据库本身固然各自有好或者不好的地方，对于我们真正去做项目的时候，考虑的因素应该更多一些，举例来说我们考虑更多的，是我的团队成员他熟悉哪个，哪一块是我倾向的或者长期使用的，这种可能比同类型的数据库区分更重要一些。当然如果说是文档型的那肯定用MongoDB会好一些；如果是微软的这个生态，如果我就是绑定这个生态选择生态当然会更合适。在没有特别的情况下，其实我个人的建议是熟悉哪个就选择哪个。

最后做一个简单的小结，华为数据库服务的定位，华为以前是藏在后面的，现在终于走出来了。我们会做三件事情：第一件是数据库的服务化，提供一个好的运维，说白了就是华为帮助大家运维，做好数据库的体检，做好服务；第二件就是改进的引擎，大家喜欢有不同的选择，有些人觉得我就喜欢这个，就像每个人的手机品牌都不一样。改进在什么地方，针对云的基础设施来提高它的性能和可靠性；第三件是自研引擎，自研引擎的含义是基于云设计，极高的性能/极大的规模/极高的可靠性。我们怎么敢说我们要做自研引擎？其实华为在这方面做了很多工作，一方面我们在国内有自己的研究所，北京、杭州、深圳和西安，同时华为是国内比较早走出国门的企业，所谓的国际化企业，在硅谷、西雅图和多伦多都有有我们的研究所，我们希望通过我们的努力来服务于中国和全球的客户。

我的分享就这里，谢谢大家。