云时代数据库的核心特色

 

 

oracle  》  mysql  》 noSql （mondb redis） 》 NewSql （tidb）

 

引言

最近几年，随着云计算相关技术的发展，各类不一样类型的云层出不穷，服务愈来愈多不一样类型的企业业务，传统企业也渐渐开始探索上云的道路。在云上，做为业务最核心的数据库，相比以前的传统方案会有哪些变化呢？在正式聊云时代的数据库特色以前，咱们须要了解一下目前云时代架构发生的变化。

畅想一下，将来的服务都跑在云端，任何的服务资源均可以像水电煤同样按需选购。从 IaaS 层的容器/虚拟机，到 PaaS 层的数据库，缓存和计算单元，再到 SaaS 层的不一样类型的应用，咱们只须要根据自身业务特色进行资源选配，不再用担忧应用服务支撑不住高速的业务增加，由于在云上一切都是弹性伸缩的。有了可靠的基础软件架构，咱们就能够把更多精力放到新业务的探索，新模式的创新，就有可能产生更多不同的新场景，从而催生更强大能力的云端服务，这是一件多么 cool 的事情。

固然，理想要一步一步实现，将来的基础软件栈到底会怎样呢？社区在这方面正在进行积极地探索，其中最有表明性的就是基于容器（以 Docker 为表明）的虚拟化技术和微服务（Microservice）。

在云时代，一切都应该是可伸缩的，使用 k8s（Kubernetes）在保证资源平衡的前提下，经过 Docker 部署咱们依托于容器的微服务模块，咱们不用关心服务到底跑在哪里，只须要关心咱们须要多少服务资源。Docker 提供了极大的便利性，一次构建，处处运行，咱们能够很好地解决开发、测试和上线的环境一致性问题。（若是不能很好地保证测试和实际上线环境的一致性，则颇有可能须要花费远超过开发的时间去发现和修复问题。）k8s 更是在 Docker 构建的基础上增长了更多的云特性，包括 Docker 的升级，高可用和弹性伸缩等等。 关于 Docker/k8s 相关的讨论已经不少了，由于时间关系，关于具体的细节就再也不展开。咱们只须要了解，有了它，能够很轻松地解决服务的安装和部署。

下面再聊聊微服务，微服务将一个服务拆分红相对独立的更小的子服务单元，不一样的子服务单元之间经过统一的接口（HTTP/RPC 等）进行数据交互。

相比于传统的解决方案，这种架构有不少的优势。

• 更好的开发效率和可维护性。微服务将一个单独的服务进行更细力度的拆分，每个子服务单元专一于更小的功能模块，能够更好地根据业务创建对应的数据模型，下降复杂度，使得开发变得更轻松，维护和部署变得更加友好.
• 更好的可扩展性。每一个不一样的子服务单元相互独立，彼此之间没有任何依赖，因此能够根据业务的具体须要，灵活地部署多个子服务单元进行水平扩展。
• 更强的容错性。当其中一个子服务出现故障的时候，能够经过辅助的负载均衡工具，自动路由到其余的子服务，不会影响总体服务的可用性.

固然，微服务也不是一个银弹，相对来讲，这种方案会使总体系统的设计更加复杂，同时也加大了网络的延迟，对整个系统测试的复杂度也会更高。

Docker 提供的隔离型和可移植性，与微服务是一种自然的契合，微服务将整个软件进行拆分和解耦，而经过 Docker/k8s 能够很天然地作到独立的部署，高可用和容错性，彷佛一切均可以完美地运转起来。可是真的是这样么？咱们是否是忽略了什么？

是的，咱们在讨论前面的问题的时候忽略了一个很重要的东西：状态。

从整个技术发展的角度来看，微服务是一个很是有意义的探索。每一个人都指望着每一个微服务的子服务都是无状态的，这样我能够自由地启停和伸缩，没有任何的心智负担，可是现实的业务状况是什么样的呢？好比一个电商网站，用户正在下单购买一件商品，此时平台是经过订单子服务的 A 应用来提供服务的，忽然，由于机器故障，订单子服务的 A 应用不可用了，改由订单子服务的 B 应用提供服务，那么它是必需要知道刚才用户的订单信息的，不然正在访问本身订单页面的用户会发现本身的订单信息忽然不见了。虽然咱们尽可能想把子服务设计成无状态的，可是不少时候状态都是不可避免的，咱们不得不经过存储层保存状态，业界最主要的仍是各类数据库，包括 RDBMS 和 NoSQL，好比使用 MySQL、MongoDB、HBase、Cassandra 等，特别是有些场景还要考虑数据一致性问题的时候，更加剧了对存储层的依赖。

因而可知，云计算时代系统的架构发生了巨大的变化，这一方面为用户提供了更优秀的特性，另外一方面也对云计算的组件提出了更高的要求。数据库做为云计算最基础的组件之一，也须要适应这种架构的变化。（这里咱们主要关注 SQL 数据库，云时代的数据库如下简称云数据库。）

那么云数据库主要有一些什么样的特色呢？我认为主要有如下几点。

弹性伸缩

传统的数据库方案，常见的会选用 Oracle，MySQL，PostgreSQL。在云时代，数据量的规模有爆发性的增加，传统的数据库很容易遇到单机的存储瓶颈，不得不选用一些集群方案，常见的好比 Oracle RAC、 MySQL Sharding 等，而这些集群方案或多或少都有一些不使人满意的地方。

好比说，Oracle RAC 经过共享存储的硬件方案解决集群问题，这种方式基本上只能经过停机换用更大的共享内存硬件来解决扩容问题，RAC 节点过多会带来更多的并发问题，一样也会带来更高的成本。

以 MySQL Sharding 为表明的数据分片方案，不少时候不得不提早对数据量进行规划，把扩容做为很重要的一个计划来作，从 DBA 到运维到测试到开发人员，很早以前就要作相关的准备工做，真正扩容的时候，为了保证数据安全，常常会选择停服务来保证没有新的数据写入，新的分片数据同步后还要作数据的一致性校验。固然业界大公司有足够雄厚的技术实力，能够采用更复杂的方案，将扩容停机时间尽可能缩短（可是很难缩减到 0），可是对于大部分中小互联网公司和传统企业，依然没法避免较长时间的停服务。

在云时代，理想中全部的资源都是根据用户业务需求按需分配的，服务器资源，应用容器资源，固然也包括数据库资源。添加或者减小新的数据库资源，彻底就像平常吃饭那样稀疏日常，甚至用户基本感知不到。好比做为一个电商用户，在双 11 促销活动以前，能够经过增长数据库节点的方式，扩大更多的资源池，用来部署相应的容器服务，当活动结束以后，再将多余的资源移除去支持其余的服务，这样能够极大地提升资源的利用率，一样能够弹性地支撑各类峰值业务。

高可用

传统的 MySQL 方案，数据复制的时候默认采用异步的方式，对于一个写入的请求，主库写入成功后就会返回成功信息给客户端，可是这个时候数据可能尚未同步给从库，一旦主库这个时候挂掉了，启动从库的时候就会有丢失数据的风险。固然，也有人会选择半同步的复制方式，这种方式在正常状况下是同步的，可是在遇到数据压力比较大的时候，依然会退化为异步的方式，因此本质上来讲，一样有丢失数据的风险。其余也有一些多主的同步方案，好比在应用层作数据同步，可是这种方式一是须要应用层的配合，二是在对网络超时的处理很是复杂，增长心智负担。

在云时代，由于全部的数据库资源都是分布式存储的，每一个数据库节点出现问题都是很正常的事情，因此就必须有一种能够实现数据一致性的数据复制方式来保证服务的高可用，业界给出的答案就是：Paxos/Raft（关于 Paxos 和 Raft 的实现细节咱们不在这里展开）。PingCAP 在作的 TiDB 就是选择了 Raft 协议，Raft 协议看起来更像是一个多副本的自适应的主从复制协议，对于每次写请求，Raft 都会保证大多数写成功才会返回客户端，即便 Raft Group的Leader 挂掉了，在一个有限的时间范围内，会很快地选出一个新的 Leader 出来，继续提供服务。一样，对于一个 3 副本的 Raft Group，只要 2 个写入成功，就能够保证成功，而大多数状况下，最早写入成功的每每是与 Leader 网络状况最好的那个副本，因此这种 Majority 写的方式，能够很天然地选择速度最快的副本进行数据同步复制。另外，Raft 协议自己支持 Config Change，增长一个新的节点，能够很容易地作副本数据分布的变动，而不须要中止任何服务。

一样，在云时代，数据库的 DDL 操做也会是一个很是有趣的事情。以一个常见的 Add Column 操做为例，在表规模已经很大的状况下，在传统的实现方案中，比较有参考意义的是，经过一些工具，建立相似表级别的触发器，将原表的数据同步到一个新的临时表中，当数据追平的时候，再进行一个锁表操做，将临时表命名为原表，这样一个 Add Column 操做就完成了。可是在云时代，分布式的数据存储方式决定了这种方案很难实现，由于每一个数据库节点很难保证 Schema 状态变动的一致性，并且当数据规模增加到几十亿，几百亿甚至更多的时候，很短的阻塞时间都有可能会致使很大的负载压力变化，因此 DDL 操做必须是保证无阻塞的在线操做。值得欣慰的是，Google 的 F1 给咱们提供了很好的实现参考，TiDB 便是根据 F1 的启发进行的研发，感兴趣的同窗能够看下相关的内容。

易用透明

咱们能够将云数据库想象成一个提供无限大容量的数据库，传统数据库遇到单机数据存储瓶颈的问题将不复存在。已有的程序基本上不怎么须要修改已有的代码，就能够很天然地接入到云数据库中来得到无限 Scale 的能力。增减数据库节点，或者节点的故障恢复，对于应用层来讲彻底透明。另外，云数据库的监控、运维、部署、备份等等操做均可以在云端经过高效的自动化工具来自动完成，极大地下降了运维成本。

多租户

云数据库自己应该是能够弹性伸缩的，因此很天然的，从资源利用率的角度来考虑，多个不一样用户的数据库服务底层会跑在一个共享的云数据库中。所以多租户技术会成为云数据库的标配。可是这里面就有一个不得不面对的问题，如何作到不一样用户的隔离性？用户数据隔离是相对比较容易的，好比仍是以电商用户（这里说的是电商企业，不是顾客客户）为例，每一个用户都有一个惟一的 ID，这样在云数据库的底层存储中，能够保证每一个用户数据都带有本身 ID 前缀，用户登录进来的时候能够根据这个前缀规则，获取他对应的数据，同时他看不到其余用户的数据。

在一个真实的多租户环境下面，纯粹的数据隔离每每是不够的，你还须要作到资源公平性的隔离。好比有的用户写一个 SQL，这个 SQL 没有作优化，主要作的事情是一个全表描扫，这个表的数据量特别特别大，这样他会吃掉不少的 CPU、Memory、IO 等资源，致使其余用户很轻量级的 SQL 操做均可能会变得很慢，影响到其余用户实际的体验。那么针对这种状况怎么作隔离？与此相似的还有，网络带宽怎么作隔离？你们都是跑在一个云数据库上面的，若是一个用户存放的数据特别大，他把带宽都吃掉了，别人就显得很是慢了。

还有一种状况，若是我自己做为一个租户，内部又怎么作隔离，你们知道 MySQL 能够建不少 Database，不一样的 Database 给不一样的团队来用，那么他们之间内部隔离又怎么作，这个问题就进一步更加复杂了。

目前来说没有特别好的方法，在一个分布式的环境下面去作很好的隔离，有两个方向能够考虑：

第一种是最简单也是有效的方法，制定一些规则，把某些用户特别大的数据库表迁移到独享的服务器节点上面，这样就不会影响其余用户的服务，可是这里面就涉及到定制化的事情了，自己理念其实与云数据库并不相符。

第二种就是依靠统计信息，作资源隔离和调度，可是这里面对技术的要求就比较高了。由于云数据库是分布式的，因此通常的统计都要横跨不少的机器，由于网络缘由，不可能作到彻底准确的统计，全部统计都是有延迟的。好比说对于某个用户，如今统计到的流量是 1 个 G，他可能忽然就有一次峰值的网络访问，可能下一次统计消耗的流量是 5 个 G（这里面只是举例说明问题），若是你给他流量限制是 1 个 G，中间统计的间隔是多少比较合适，若是间隔比较小，那么这个对整个系统的压力就比较大，可能影响正常的用户 SQL 访问，另外自己这个流量限制的系统也是很复杂的系统。

调度算法一直是整个分布式系统领域很困难的一个问题，如何作到隔离性和公平调度也是将来云数据库很是有挑战的一个事情。

低成本

低成本应该是云时代基础设施最明显的特色。首先，云数据库的高可用和容错能力，使得咱们再也不须要昂贵的硬件设备，只须要普通的 X86 服务器就能够提供服务。而后，受益于 Docker 的虚拟化技术，使得不一样类型的应用容器能够跑在同一个物理机上，这样能够极大地提升资源的利用率。其次，多租户的支持，使得不一样的用户能够共用一套底层的数据库存储系统，在数据库层面再一次提升了资源的利用效率。再次，云数据库的自动化运维工具，下降了整个核心数据库的运维成本。最后，云数据库资源是按需分配的，用户彻底能够根据自身的业务特色，选购合适的服务资源。

高吞吐

云数据库虽然能够作到弹性扩容，可是自己是分布式存储的，虽然能够经过 Batch Write、Pipeline 和 Router Cache 等方式加快访问 SQL 请求的数据，可是相对传统单机的数据库来讲，在数据访问链路上至少也要多走一次网络，因此大部分并发量不大的小数据量请求，都会比单机延迟要高一些。也就是说，当没有足够高的并发 SQL 访问的话，其实不能彻底体现云数据库的性能优点，因此这也是咱们在选用云数据库的时候须要认识到的问题，云数据库更多的是追求高吞吐，而不是低延迟。当并发大到必定规模，云数据库高吞吐特性就显现出来了，即便在很高的并发下，依然能够维持至关稳定的延迟，而不会像单机数据库那样，延迟线性增加。固然，延迟的问题，在合理的架构设计方案下，能够经过缓存的方式获得极大的缓解。

数据安全

云数据库的物理服务器分布在多个机房，这就为跨数据库中心的数据安全提供了最基础的硬件支持。谈到金融业务，你们耳熟能详的可能就是两地三中心，好比北京有两个机房，上海有一个。将来一切服务都跑在云上，金融类的业务固然也不例外。相比其余业务，金融类业务对数据安全要求就要高得多。固然，每一个公司内部都有核心的业务，因此若是上云的话，也会有一样的强烈须要。这样，对云数据库来讲，数据的一致性、分布式事务、跨数据中心的数据安全等更高端的需求有可能会日益强烈。常见的数据备份也有可能会被其余新的模式所取代或者弱化，好比基于 Paxos/Raft 的多副本方案，自己就保证了会有多份备份。

自动负载平衡

对于云数据库来讲，负载平衡是一个很重要的问题，它直接决定了整个云数据库系统性能的好坏，若是一个数据库节点的数据访问过热的话，就须要考虑把数据迁移到其余的数据库节点来分担负载，否则就很容易出现性能瓶颈。整个负载平衡是一个动态的过程，调度算法须要保证资源配比的最大平衡，还有保证数据迁移的过程对系统总体的负载影响最小。这在将来也是云数据库须要解决的一个核心问题。

小结

从目前已有的 SQL 数据库实现方案来看，NewSQL 应该是最贴近于云数据库理念的实现。NewSQL 自己具备 SQL、ACID 和 Scale 的能力，自然就具有了云数据库的一些特色。可是，从 NewSQL 到云数据库，依然有不少须要挑战的难题，好比多租户、性能等。

上面提到的一些云数据库的特色，也是 PingCAP 目前在着力实现的部分，TiDB 做为国内第一个 NewSQL 的开源项目，在与社区的共同努力下，咱们在上月底刚刚发布了 Beta 版本，欢迎各位上 GitHub 了解咱们。

随着整个社区技术水平的发展和云时代新的业务需求的驱动，除了 PingCAP 的 TiDB，相信会有更多的团队在这方面进行探索， 期待早日看到云数据库成熟的那一天。

Q&A

问：因为客户数据环境复杂多样，在迁移到云端的时候怎么怎么作规划，以便后期统一运维管理？或者说，怎么把用户 SQL Server 或者 MongoDB 逐渐迁移到 TiDB 之类的分布式数据库？ 崔秋：由于每一个业务场景都不太相同，因此在选用云端服务的时候，首先要了解自身业务和云服务具体的优缺点。 若是你的业务自己比较简单，好比你以前用的 MongoDB，如今不少云服务厂商都会提供云端的 MongoDB 服务。这个时候你就要根据业务特色来作判断，若是 MongoDB 自己容量不大，远期的业务数据不会增加过快的话，这个时候其实你能够直接使用 MongoDB 的服务的。可是若是你自己的数据量比较大，或者数据增加比较快的话，就可能要考虑数据的扩容问题，MongoDB 在这方面作的不是太好。 你能够考虑 SQL 数据库的集群方案。好比 TiDB，它自己是支持弹性扩容，高并发高吞吐和跨数据库中心数据安全的，另外有一点明显的好处是 TiDB 兼容 MySQL 协议，因此若是你的应用程序是使用 MySQL，就基本上能够无缝地迁移到 TiDB，这方面是很是方便的。后续咱们会提供经常使用的数据库迁移工具，帮用户把数据从 MongoDB/SQL Server 等平滑迁移到 TiDB 上面。 仍是那个原则，不要为了上云而上云，必定要了解清楚本身的业务特色，云数据库会帮助你提供不少特性，若是真的很适用你的业务的话，就能够考虑。

问：但从产品的角度来看，云厂商提供的 RDS 产品是 Copy 客户数据库的思路，或者说是为了支持不一样的数据库而支持。请问这种局面之后会有什么改变吗？ 崔秋：如今确实蛮多云数据库服务其实就是在传统的 RDS 上面包了一层自动化的监控，运维和部署工具，就卖给用户提供服务了，可是实际上自己解决的仅仅是自动化管控的问题，云服务提供的数据库特性仍是单机的 RDS，或者 RDS Sharing 的特性。若是自己底层的数据库知足不了你的需求的话，云服务也是知足不了的。 若是你须要不停服务的弹性扩容，单机的 RDS 服务确定是搞不定的，RDS Sharing 也很难帮助你作到，这就对底层的数据库有了更高的要求，固然这方面是 TiDB 的强项了。 如今不少云上的 RDS 产品还远远没有达到理想中的云数据库的要求，不过随着社区的发展和业务需求的推进，我我的以为，这方面最近几年会有更多的变化。若是对于这方面感兴趣的话，能够关注下 TiDB。

问：从 Oracle 分流数据到 TiDB、Oracle 增量修改、Update 的记录，如何同步到 TiDB？有没有工具推荐，好比相似 Ogg？ 崔秋：目前 TiDB 尚未相应的工具。若是真的须要在线从 Oracle 这边分流的话，能够考虑使用 Oracle 的触发器，将数据的变化记录下来，而后转化为 SQL，同步到 TiDB，固然这须要必定开发的工做量。