一代系统：数据库中间件
● 二代系统：NoSQL 数据库
● 三代系统(2013)：
○ Google Spanner 及其类似的 NewSQL (TiDB 3.0, CockroachDB)
○ AWS Aurora 及其类似架构的云数据库
● 新一代趋势：HTAP 数据库（以 TiDB 4.0 为代表）
两种实现模式：
● 业务层手动分库分表（手动）
● 通过中间件指定 Sharding Key 的模
式水平分表（半自动）
常见分片Key选择: user id、城市、时间
常见分片规则：哈希分片、范围分片
数据库中间件的优点：
● 架构相对简单
● 对底层的关系型数据库改动不大，运维经验可以复用
缺点：
● 只适用于简单业务，同时对业务有侵入性，需要改造
● 很难支持跨分片的高性能复杂查询
● 分布式事务性能损失
○ 扩展问题：为什么会有性能牺牲？
● 水平扩展能力差，只能按照选定的分片规则横向扩展
● 大型集群运维困难
○ 表结构变更（DDL）操作困难，容易出现失误
○ 只能按照分片进行维护（备份、恢复等操作）
● 放弃高级 SQL 能力，追求强水平扩展能力（反过来意味着业务兼容的成本高）
○ 放弃复杂 SQL 查询
○ 放弃分布式事务（ACID）
● 通常的数据访问模型：
○ 键值对 (Key-Value)
○ 文档型 (Document)
● 代表系统：
○ MongoDB
○ CouchBase
○ Cassandra
○ HBase
● 在互联网行业比较活跃：2006 ~ 2012
NoSQL系统的优点：
● 水平扩展能力强
● 针对特殊类型数据效果好，可以作为关系型数据库的很好补充
● 对于一致性要求不强的场景，可能会有更好的性能
缺点：
● 由于不支持 SQL 业务需要进行较大的改造
● 普遍无法支持事务，强一致场景比较难实现
● 复杂查询受限
1.2.1 典型系统分析：MongoDB
● 文档型数据库
● 仍然是通过选择 Sharing Key 的方式进行分
片
○ Range 或 Hash 分片
● 优点：
○ Scheme-less，对文档型数据比较友好
● 缺点：
○ 跨分片聚合能力差
○ Rebalance 过程中会占用大量带宽
○ 无跨分片事务
1.3 第三代分布式数据库 NewSQL
两种流派
○ 以 Google Spanner 为代表的 Shared Nothing 架构
○ 以 AWS Aurora 为代表的 Shared Everything 架构
1.3.1 Shared Nothing 流派
● 特点：
○ 无限的弹性水平扩展
○ 强 SQL 支持（几乎不需要妥协，无需指定分片策略，系统自动扩展）
○ 和单机数据库一样的事务支持
○ 跨数据中心故障自恢复级别的高可用能力
● 代表产品
○ Google Spanner
○ TiDB 3.0 及之前版本
○ CockroachDB
● 优点：
○ 无限水平扩展，没有容量上限， 对海量数据场景友好
○ 对金融级别的一致性 ACID 事务支持，业务改动代价小
○ 故障自恢复的高可用能力，运维省事
○ SQL 能力强，和单机数据库的体验基本一致
■ 例如：TiDB 支持 MySQL 的绝大多数语法和网络协议 (覆盖度超过 92%)
○ 无限扩展的吞吐能力（和业务负载有关）
● 缺点：
○ 并非 100% 兼容传统数据库的语法(不支持存储过程)
○ 对于一些极端场景（秒杀），延迟不如单机数据库（跨机，跨地域的分布式事务必然带来更高延
迟）
■ 例子：小事务平均 latency： 2ms（单机） vs 5ms （分布式）
1.3.2 Shared Everything 流派
代表产品：AWS Aurora、阿里云 PolarDB
Cloud-Native
● 通常由公有云提供
○ 为什么？
存储计算分离
● 无状态 SQL 计算节点
○ 计算节点通常直接复用
MySQL，但是不存储数据
● 远程存储（数据文件层）
优点：
● 易用，100% 兼容 MySQL，业务兼容性好（最大优势）
● 对一致性要求不高的场景，读可以水平扩展（但是有上限）
缺点：
● 本质上还是单机数据库，如果要支持大数据量，仍然需要分库分表
● 内存和容量不匹配，在单表数据量大后，性能抖动严重
● 跨机的事务一致性问题（存在同步延迟）
● 分析能力受限于单点，几乎没有分布式 OLAP 能力
1.4 分布式 HTAP 数据库
● HTAP 的定义：Hybrid Transactional/Analytical Processing，混合事务分析处理
● 分布式 HTAP 的标准
○ 业务透明的无限水平扩展能力
○ 分布式事务的支持
○ 多数据中心故障自恢复的高可用能力
○ 提供高性能的分析能力
■ 提供列式存储能力
○ 在混合负载下，实时 OLAP 分析不影响 OLTP 事务
● 目前业界仅有 TiDB 4.0 能达到上述的要求
○ TiDB + TiFlash (TiDB 的列存扩展)
数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
● 为什么能实现 OLAP 和 OLTP 的彻底隔离，互不影响？
○ 存储和计算彻底分离
○ 列式存储（适用于 OLAP）以副本扩展的形式存在
○ 通过 Multi Raft 架构进行日志级别的复制同步，业务层完全无感知
● 扩展性依托 TiDB 的分布式架构，能做到水平扩展
○ 数据同步不会成为瓶颈
■ 面向实时分析设计，不需要额外的技术栈从数据库同步到实时数仓