5G风起，未来数据库有哪些关键词？（上）

在自己工作的领域中，发现快乐是我坚持做技术的动力。而技术域其实就是一个画圆的过程，当你发现你的圈圈画得越大，需要求知的东西也就越多。每天必须保持一种持续学习，和与技术死磕的精神才能促使我们不断前行。我们不断前行，时代也在不断变化和发展。本文由变化看发展，从移动通讯发展的历程同步透视数据库能力的变迁，进而预测5G时代将会给数据库带来的重大变革。

1G 时代下的数据库 关系型数据库来满足基本需求

首先，从通信时代的总要变化谈起：从 1G 到 5G，手机见证了人类通信的飞速发展。从军用到民用，从大哥大到智能机，总有一款手机能勾往日的回忆。

1938 年，美国贝尔实验室为美国军方制成了世界上第一部“移动电话”，即无线便携式报话机，使用时必须有一人背负信号箱，光是信号箱就是二三十斤，1G 所通信所使用的正是模拟技术。1973 年摩托罗拉公司的马丁·库帕发明了世界上第一部民用手机，1983 年正式推向市场。1993 年大陆第一部手机摩托罗拉 3200，被尊称为“大哥大”，宣告了我国正式进入 1G 时代，拥有一部“大哥大”是身份的象征，也是那个年代人们的梦想。

关系型数据库起源自 1970 年代，其最基本的功能无非就两个：一个是先把数据存下来，另外就是满足用户对数据的计算需求。数据是根基，如果连数据都完整的存不下来，或者保存不好，后续任何事情都无法进行展开，所以这点很重要。有了数据，用户就可以进行一些 query 操作了。

不管是聚合、连表还是分组，在数据库早期发展阶段都能满足需求，当时优秀的商业数据库产品主要是 Oracle，DB2。

2G 时代下的数据库 开源数据库产品初露锋芒

1G 有着很多的缺陷，可能经常会出现串号、盗号等现象。1994 年，就在我爸吵吵嚷嚷地要买“大哥大”的时候，A 网和 B 网正式关闭，紧接着 2G 时代来临了。1995 年，新的通讯技术成熟，国内也正式进入了 2G 通信时代，主宰 1G 时代的摩托罗拉走下神坛，取而代之的是垄断一时的诺基亚。在这之后的那些年，诺基亚带给我们了无数经典手机。我记得我当时用的是诺基亚 7610。

当时，Berkeley DB、MySQL、PostgreSQL 等数据库陆续发布，开源数据库产品初露锋芒。这些数据库不断提升单机实例性能，可以很好地支撑业务发展，应对各类业务的变化。拿目前独占开源数据库榜首的 MySQL 举例来说，它的数据库架构就很丰富。有基于主从架构的 MHA，双主+Keepalived。

我们先来看下各个数据库的发布时间，然后简单介绍。

1. 基于主从架构的 MHA

MHA 的目的在于维持 MySQL Replication 中 master 库的高可用性，其最大特点是可以修复多个 slave 之间的差异日志，最终使所有 slave 保持数据一致，然后从中选择一个充当新的 master，并将其他 slave 指向它。当 master 出现故障时，可以通过对比 slave 之间 I/O thread 读取主库 binlog 的 position 号，选取最接近的 slave 作为备选主库（备胎）。其他的从库可以通过与备选主库对比生成差异的中继日志。在备选主库上应用从原来 master 保存的 binlog，同时将备选主库提升为 master。最后在其他 slave 上应用相应的差异中继日志并从新的 master 开始复制。

2. 基于主从架构的双主+Keepalived

中小型规模的时候，采用这种架构是最省事的。两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个 VLAN 中，在 master 节点发生故障后，利用 keepalived/heartbeat 的高可用机制实现快速切换到 slave 节点。

3. 基于 Galera 协议的 MySQL 高可用集群架构

Galera 产品是以 Galera Cluster 方式为 MySQL 提供高可用集群解决方案的。Galera Cluster 就是集成了 Galera 插件的 MySQL 集群。Galera replication 是 Codership 提供的 MySQL 数据同步方案，具有高可用性，方便扩展，并且可以实现多个 MySQL 节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。

4. 官方大力推进的 InnoDB Cluster 集群架构

MySQL 官方在 5.7.17 版本正式推出组复制（MySQL Group Replication，简称 MGR）。master1，master2，master3，所有成员独立完成各自的事务。当客户端先发起一个更新事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去，复制到其他成员。如果冲突检测成功，组内决定该事务可以提交，其他成员可以应用，否则就回滚。最终，这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。

3G 时代下的数据库 非关系型数据库应对数据暴增

1. 3G 时代数据暴增

2G 定义为文字通讯，从 1G 跨入 2G 则是从模拟调制进入数字调制，相比较而言，2G 移动通讯具备高度的保密性，系统的容量也在增加。同时从这一刻的开始，手机也能上网了。虽然当时只能浏览一些文本或者互相传送 txt 文件等，但我们可以畅快淋漓地随时随地看小说了，带来的满足感还是有的。但日益增长的图片和视频传输的需要，使得人们对于数据传输速度的要求日趋高涨，2G 时代的网速显然不能支撑满足这一需求。随之 3G 图片时代应运而生。互联网超强的热度席卷了全球，触屏手机出现，变得娱乐方式多样化，人们对移动网络的需求也在不断加大。

由于采用更宽的频带，传输的稳定性也大大提高。速度的大幅提升和稳定性的提高，使大数据的传送更为普遍，移动通讯有更多样化的应用。3G 可以被视为开启行动通信新纪元的重要关键，于是看新闻、刷微博、下载图片、在线听音乐等等都渐渐成为人们的娱乐日常。

2009 年 3G 时代到来，同年 MongoDB 发布，NoSQL 这个名词也正式出现在我们的视野中。虽然传统的单机关系型数据库底层架构很丰富，但随着移动互联热度的风靡全球，数据量呈现爆发性增长，传统的关系型数据库越来越难以满足用户不同的需求。即便是最基本的数据能存下的问题，当时都不能保证了。

2. NoSQL 数据库：应对数据暴增的变革性解决方案

数据暴增，难道就没有解决办法嘛？当然有的！针对关系型数据库存不下数据的问题，有两个核心解决点：

• 第一，我们可以沿着单机关系型数据库的基础之上做一些Proxy。

• 第二，把数据存储在多个集群中，然后查询时再把数据汇总在一起。

但是我们发现有了 Proxy 之后，业务要考虑 sharding key 的使用问题，针对业务扩容上会很受限，跨库跨表的操作很难实现，跨库 join 和跨库一致性很难得到支持。具体来说就是前端会把所有的应用逻辑，嵌入到中间件中。那么把所有的业务逻辑，全部放到一个中间件里，一定会制约业务的吞吐量和弹性扩张的能力。具体如下图所示。

所以越来越多的企业或者互联网公司，开始采用微服务的技术了。把紧耦合到中间件中的应用，拆散到各个中间里面，来提供分布式的服务。微服务架构的核心都是一个可以弹性扩展不断伸缩的框架。比如业务中有登陆的子系统，财务的子系统。每一组子系统可以做成一组独立的服务。每一组独立的服务，我们上层可以使用容器技术，把应用逻辑写到一个个容器里面。当发现子系统压力过高或者计算能力不够的时候，我们只需要考虑增加容器，来提高应用的扩展能力和吞吐量。具体如下图所示。

我们回归到数据库本身，传统的关系型数据库既然应对数据暴增没有很好的解决办法，那我们就来看看通过底层非关系型的 NoSQL。

我们考虑用利用更简单的存储模型，放弃 SQL，放弃事务，来获取一个更容易实现的扩展系统。HBase 是其中的典型代表。HBase 是 Hadoop 生态中的重要产品，Google BigTable 的开源实现。HBase 本身并不存储数据，数据还是以文件的形式存储在 HDFS 上，重度依赖 HDFS，并不支持 ACID 跨行事务。

3. MongoDB：首个支持跨文档事务的 NoSQL 数据库

说到这里就不得不好好聊聊 MongoDB 了。MongoDB4.0 开始支持跨文档事务，这就也意味着 MongoDB 是首个支持跨文档事务的 NoSQL 数据库，将文档模型的速度，灵活性和功能与 ACID 保证相结合。现在使用 MongoDB 解决各种用户案例变得更加容易。更值得一提的是从 MongoDB4.2 版本开始支持分布式事务了。原来在 4.0 版本中的事务存在最大修改 16MB、事务执行时间不能过长的限制都已经解决了。分布式事务的支持也意味用户修改分片 key 的内容成为可能，因为修改分片 key 的内容，可能会导致 key 要迁移到其他 shard，而在 4.2 之前，无法保证这个迁移动作的原子性，而借助分布式事务，这个问题也就迎刃而解了。

（1）MongoDB 的复制级架构

三副本架构是最基础的复制集的架构，一主两备模式。主节点接受外界的读写请求，向备节点进行数据同步。当主节点宕掉，会自动切换到备节点，不影响线上业务，防止单点故障。

（2）MongoDB 的分片架构

分片是一种在多台机器上分配数据的方法。MongoDB 使用分片架构有助于您去管理非常大数量的数据集和高吞吐量操作的集群。大数据量和高吞吐量的业务情况对单台服务器来讲是具备很大的挑战性的。例如，高查询率可能耗尽服务器的 CPU 容量。工作集大小超过系统内存，那么压力则会给到磁盘上，这对 IO 来讲不是我们所希望看到的。MongoDB 支持通过分片进行水平缩放。