导语:
在自己工作的领域中, 发现快乐是我坚持做技术的动力. 而技术域其实就是一个画圆的过程, 当你发现你的圈圈画得越大, 需要求知的东西也就越多. 每天必须保持一种持续学习, 和与技术死磕的精神才能促使我们不断前行. 我们不断前行, 时代也在不断变化和发展. 本文由变化看发展, 从移动通讯发展的历程同步透视数据库能力的变迁, 进而预测 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 之前, 无法保证这个迁移动作的原子性, 而借助分布式事务, 这个问题也就迎刃而解了.
MongoDB 的复制级架构
三副本架构是最基础的复制集的架构, 一主两备模式. 主节点接受外界的读写请求, 向备节点进行数据同步. 当主节点宕掉, 会自动切换到备节点, 不影响线上业务, 防止单点故障.
MongoDB 的分片架构
分片是一种在多台机器上分配数据的方法. MongoDB 使用分片架构有助于您去管理非常大数量的数据集和高吞吐量操作的集群. 大数据量和高吞吐量的业务情况对单台服务器来讲是具备很大的挑战性的. 例如, 高查询率可能耗尽服务器的 CPU 容量. 工作集大小超过系统内存, 那么压力则会给到磁盘上, 这对 IO 来讲不是我们所希望看到的. MongoDB 支持通过分片进行水平缩放.
四, 4G 时代下的数据库: 分布式 + 关系型的 NewSQL
时间一晃到了 2013 年 12 月, 工信部在其官网上宣布向中国移动, 中国电信, 中国联通颁发 "LTE / 第四代数字蜂窝移动通信业务(TD-LTE)" 经营许可, 也就是 4G 牌照. 至此, 移动互联网进入了一个新的时代, 即 4G 视频时代. 如今 4G 已经像 "水电" 一样成为我们生活中不可缺少的基本资源. 而且 4G 信号的覆盖范围也非常广泛, 并且成为大多数人的标配, 微信, 微博, 小视频等手机应用成为生活中的必须, 经常看到很多人刷着抖音, 快手. 越来越多的人参与到拍小视频, 当主播这个行业当中来. 有句话 "南抖音北快手, 智障界的两泰斗", 流传比较广的, 可见 4G 不仅开启了一个全民娱乐的时代, 也引来了视频自媒体发展的红利时代. 我们现在根本无法想象离开手机的生活会是什么样.
对于数据库的发展来说, 我们之前也谈了关系型数据库的代表 MySQL, 非关系型数据库的代表 MongoDB, 接下来聊聊在 4G 时代的这个时间节点, NewSQL 这个名词出现在了我们的视野里面. 如果说 NoSQL 是一种变革, 那么 NewSQL 就是进击的巨人. 记得三国演义开篇说到 "论天下大势, 分久必合合久必分". 我们本文聊聊 "分久必合".
NewSQL 应是 RDBMS 中的数据模型 (关系型, 符合 ACID) 和 NoSQL 中的计算框架, 分布式存储, 开源特定的结合产物.
2012 年底到 2013 年初, Google 相继发表了 Spanner 和 F1 两套系统的论文, 让业界第一次看到了关系模型和 NoSQL 的扩展性在一个大规模生产系统上融合的可能性.
Google 的 Spanner + F1, 是第一个生产环境中大规模验证的 NewSQL 系统; Spanner 通过使用硬件设备 (GPS 时钟 + 原子钟) 巧妙地解决时钟同步的问题 -- 在分布式系统里, 时钟正是最让人头痛的问题. Spanner 的强大之处在于即使两个数据中心隔得非常远, 也能保证通过 TrueTime API 获取的时间误差在一个很小的范围内(10ms), 并且不需要通讯. Spanner 的底层仍然基于分布式文件系统, 不过论文里也说是可以未来优化的点. Google 的内部的数据库存储业务, 大多是 3~5 副本, 重要的数据需要 7 副本, 且这些副本遍布全球各大洲的数据中心, 由于普遍使用了 Paxos, 延迟是可以缩短到一个可以接受的范围(写入延迟 100ms 以上), 另外由 Paxos 带来的 Auto-Failover 能力, 更是让整个集群即使数据中心瘫痪, 业务层都是透明无感知的. F1 是构建在 Spanner 之上, 对外提供了 SQL 接口, F1 是一个分布式 MPP SQL 层, 其本身并不存储数据, 而是将客户端的 SQL 翻译成对 KV 的操作, 调用 Spanner 来完成请求.
NewSQL 中的典型代表就是 Google Spanner 和国内的 TiDB, 巨杉等.
结合 NewSQL 数据库的特点, 主要可以总结为新老技术的搭配. 新技术中最基本的是扩展能力, 包括存储和计算扩展; 除了扩展能力, 当然还有 HTAP 这种混合事务和分析场景, 适应更多应用数据需求. 老技术中主要就是高可用性, 在一个比较大的分布式集群中, 少量节点失效下, 数据库依然能够提供服务, 依然能够自我恢复, 依然可用; 事务 ACID 的支持, 处理 OLTP 的能力; 最后就是 SQL 完整支持, 业务采用 SQL 来对存储进行交互. 其特性如下图所示.
这里我们看看 TiDB 分布式数据库的样子, 如下图所示.
整体架构介绍: TiKV+PD 形成了 kv 的带事务的存储引擎.
TiKV: 主要存储数据, 把数据一片一片存储在集群中.
PD:(集群管理者)存储 Tikv 中的元信息. 每片数据所在位置和有哪些副本. PD 还要负责对 TiKV 节点进行负载均衡调度和管理.
TiDB: 无状态的计算层(随意扩展), 支持 MySQL 协议和 SQL 请求和 SQL 优化. 发送计算和获取数据的请求, 通过 MySQL 协议返回给客户端. TiDB 是存储引擎和业务端的桥梁枢纽.
六, 5G 风起, 数据库将会如何发展?
1. 数据库发展总结
来源: https://www.qcloud.com/developer/article/1496077