第七章 - 分布式数据库

数据库中间层

1. 架构
   1. 数据库组：N 台数据库机器组成主备集群
   2. 元数据服务器：维护 dbgroup 拆分规则并用于 dbgroup 选主
2. 扩容：MySQL Sharding 集群一般按照用户 id 进行哈希分区
   1. 面临的问题
      1. 集群容量不够（容量问题）
      2. 单个用户的数据量太大（热点问题）
   2. 通常使用双倍扩容方案，扩容时需要停写，大致流程为
      1. 等待主库数据同步到从库
      2. 停写，主从数据完全同步后接触主备关系
      3. 修改中间层映射规则，模 N 变成模 2N
      4. 开启写服务，原来的主备作为新的主，为他们增加新备
   3. 双倍扩容方案的优缺点
      1. 优点
         1. 对应用层透明
         2. 实现简单
      2. 缺点
         1. 数据库复制：主库压力较大时，主备复制延迟较大，主备切换可能会导致丢数据，需要人工接入
         2. 扩容问题：只能成倍扩容，并且容易出错
         3. 动态数据迁移问题：如果某个数据库组（分片）压力过大，需要迁移数据，需要总控节点协调，及其他节点配合，很难自动化

Microsoft SQL Azure

1. 数据模型：将数据划分为多个分区，限制事务只能在一个分区内执行来规避分布式事务
   1. 一个逻辑数据库称为一个表格组（table group），可以有主键，也可以没有
   2. 划分主键不需要是每个表格的聚集索引
   3. 表格组中所有划分主键相同的行集合称为行组（row group），只支持行组内的事务
   4. 如果表格组有主键，则支持自动水平拆分表格组
   5. 问题：
      1. 阻塞及性能
      2. 限制用户使用模式
      3. 只读事务可以跨多个 row group，但是事务隔离级别只能做到 RC
2. 物理模型：表格组按照主键列有序分成多个数据分区（partition），分区之间互相不重叠
   1. 分区是复制、迁移、负载均衡的基本单位
   2. 分区的副本打散到不同的机架
   3. 每个分区有 1 主 2 从，3 个副本
   4. 主副本处理所有查询，更新以操作日志的方式同步到从副本
   5. 分区划分是动态的，可能动态合并或分裂
3. 架构
4. 复制与一致性
   1. Quorum Commit 复制协议，NWR
   2. 主副本与从副本之间传递逻辑操作日志，而不是磁盘物理页的 redo/undo log
5. 容错：由全怒分区管理器统一调度，故障时每次选择一个分区执行重新配置
   1. 从副本故障：选择一台负载较轻的服务器，然后从主副本拷贝数据来增加副本
   2. 主副本故障：选择一个备副本作为新主副本，然后增加一个新从副本
6. 云 SQL Server 与单机 SQL Server 的区别
   1. 不支持的操作：如 USE，因为不同的逻辑库可能存在不同的物理机
   2. 观念转变：请求的三态

Google Spanner

1. Spanner 的表是层次化的，最底层是目录表(Directory Table)，其他表创建时可以用INTERLEAVE IN PARENT 表示层次关系
   1. Spanner Directory 相当于 Megastore Entity Group
   2. Spanner 将同一个 Directory 存放在一起，优先将同一个 Directory 副本放在一台机器上
2. 概念
   1. Universe 一个 Spanner 部署实例称为一个 Universe，全世界 3 个（开发、测试、线上），支持多数据中心部署、支持多业务共享同一个 Universe
   2. Zones 每个 Zone 属于一个数据中心，一个数据中心可以拥有多个 Zone
3. 架构
4. 多集群复制