商用数据库上云的方式与存在的问题

​熙熙攘攘的春节假期完完全全的结束了，因为儿子今年高考，所以春节只是窝在深圳。春节期间应儿子的要求去看了一场电影-《流浪地球》，电视也没啥可看的，只有一个更新速度像便秘的《三体》还值得一看。两部片子看着看着就看岔了情节了，地球人驾驶着地球，跨越2500年时空去三体人的老家蹭太阳，而宇宙的那一端，三体人跨过茫茫宇宙要来抢劫地球，不知道那拨人出现了技术误判。

我每天写点东西，都是最近在思考的东西，春节假期放空自己，思考的问题不多，可写的题材也不多。正好春节假期的最后几天在编写一篇调研报告的提纲，还算思考了一些技术问题，实际上在春节前我也写过这方面的题材，那就是国产商用数据库上云的问题，今天就从另外一个角度聊聊这个话题吧。

数据库上云的方式一般数据库服务器云纳管、云主机部署、RDS服务、容器云这四种方式。云纳管仅仅是一种最低程度的云管，实际上数据库和云还是完全分离的。今天我们先来看看其他三种方式。

云主机部署数据库是最早出现的数据库上云的方式，利用云平台的ECS与云主机模板，以及云平台的资源编排能力，可以实现数据库在云上的快速部署与快速变更。数据库的部署可以做成云主机模板，以小时级的速度交付使用。这对于以往以周为单位的交付效率来说，已经是革命性提高了。不过这种部署模式存在很多问题，首先是交付与运维还是脱离的，数据库运维的模式还是传统的模式，自动化程度不高；其次是部署在云主机上的数据库性能还是有些问题的，大型数据库往往还需要外接集中式存储来解决IO性能的问题；第三是稍微关键一些的数据库往往会受到云资源超配的干扰，需要通过独立的安置组来做资源隔离，避免其他云组件对数据库的性能影响；最后一点是交付效率还存在提升的需求。

RDS是数据库上云目前最主要的方式之一，也是针对云主机部署的一种改良。RDS一般以裸金属的方式部署，在一台服务器上部署多个数据库实例，通过资源管理的模式来限制其资源使用。RDS部署的数据库以服务器的本地盘为存储介质，可以使用SATA HDD、SAS HDD、SATA SSD、NVME SSD等多种形式的存储介质，有些云厂商还提供高性能云存储作为存储介质。这种采用裸金属部署的模式，数据库在性能方面损耗较少，因此在同样的数据库上，RDS的性能往往优于云主机部署的数据库。不过受限于单机容量，RDS的规模是受到PC服务器的物理限制的，CPU，内存，存储容量的扩展都存在一定的限制，CPU、内存的限制在其他模式的部署中也是如此，不过数据库的容量受限是个比较麻烦的事情。不过裸金属云也有一些突破容量限制的解决方案，比如通过INTEL的RSD可以动态分配磁盘等资源给某台服务器，实现分钟级的资源调度，阿里的神龙就是一个类似的裸金属云解决方案。RDS除了存储容量的限制外，资源隔离方面也不是完美的，多个数据库服务使用同一个OS，相互之间还是会有一定的干扰，因此有时候会出现一些莫名其妙的性能问题。

RDS数据库的高可用、备份等可以使用数据库原生的模式，比如通过MHA、MGR等构建主从环境，或者利用云平台的底层存储快照、副本复制等技术来实现数据库复制，也可以通过云平台底层的CDP/CDM技术实现可持续的数据保护，不过这些方式的实现成本都比较高，大多数用户还是通过传统的数据库主从复制来获得高可用能力。

第四种上云模式是近些年比较流行的容器云，在容器中跑数据库目前已经挺普遍了，一些企业已经构建起了DEVOPS的工具链，不仅仅可以快速交付数据库，还可以快速交付整个应用。数据库的容器云一般来说部署的数据库规模都较小，支撑一个不太复杂的业务。如果一个企业有数百个规模类似，业务负载也差不多的数据库，或者一些大型业务可以拆分为数十个这样类似的数据库，那么容器云可以节约大量的部署、运维的成本。

大家要注意的是，里面我提到了一个“规模类似”，为什么要提这个词呢，因为如果多个数据库可以使用相同的容器镜像来部署，那么容器云的成本是最低的，如果库都要构建数十个独立的镜像，那么其成本就不低了。另外一个要注意的问题是要有高水平的operator来支撑容器云，如果一个应用拆分为数十个数据库，每个数据库都还需要DBA来做精细的运维，那么还不如把这几十个数据库合并为一个大型数据库，每个小库作为这个数据库的一个库或者一个SCHEMA。容器云的大量小型数据库应该是90%以上甚至99%以上的运维是通过过operator自动化运维的，这样才能真正的节约运维成本。我以前帮助用户优化过容器中的数据库，因为他们的镜像是从网上下载的，根本没有根据他们的应用的要求重新构建，因此当数据库出问题的时候，很多指标都采集不到，分析问题十分不便，这样的容器中运行的大型数据库，一旦出现一些问题，那么定位起来就好似大海捞针一样。

今天时间关系，就先写了这个问题的上半部分吧，今天实际上只是讨论了数据库上云的几种方式。关于商用数据库上云的方式以及存在的问题的讨论本来是本文要讨论的重点，我们放在明天的下集里在讨论吧。最后给广大读者拜个晚年。​