Skip to main content

Scaling Database 数据库拆分

1. Database Sharding​

aka. Partition.

  • 按照一定的规则，将数据拆分开存储在不同的实体机器上
  • 防止 single point failure
  • 分摊 read and write traffic

1.1 Vertical Sharding 纵向拆分​

  • 例如 User Table里有如下数据
    • email
    • username
    • password
    • nickname
    • avatar
  • 我们知道 email, username, password 不会经常变动。而 nickname, avatar 相对来说变动频率较高
  • 可以将它们拆分为两个表 User Table, UserProfile Table
    • UserProfile 中用一个 user_id的 foreign key 指向 User
    • 分别放在两台机器上
    • 如果 UserProfile Table 挂了，不会影响 user 正常登录

Vertical Sharding 的缺点是什么? 不能解决什么问题?

  • colmuns 无法再拆分
  • 数据量非常巨大

1.2 Horizontal Sharding 横向拆分​

  • 假如使用 不一致 Hashing
    • %n 是一种最简单的 Hash 算法。
    • 该方法在 n 变成 n + 1 的时候，每个 key % n 和 % (n + 1) 的结果基本上都不一致。
    • 缺点1: 数据分布不均匀。
    • 缺点2: 迁移压力很大，当进行扩容时，需要将所有数据重新分布，并从老机器中迁移数据。
  • Consistent Hashing 一致性哈希
    • SQL, NoSQL 都可以使用
    • 很多 DataBase 有 Auto-scaling 的功能
  • 更多阅读 Consistent Hashing

2. Database Replica 数据库备份​

  • 方法: 一式三份
  • 一台机器挂了可以用其他两台机器恢复
  • 分摊读请求

2.1 Backup vs Replica​

  • Backup
    • 一般是周期性的，比如每天晚上进行一次备份
    • 当数据丢失时，通常只能回复到之前的某个时间点
    • Backup 不用作在线的数据服务，不分摊 read traffic
  • Replica
    • 实时的，在数据写入时就可以复制多份
    • 当数据丢失时，可以马上通过其他的复制品恢复
    • Replica 用作在线的数据服务，分摊 read traffic

2.2 MySQL Replica​

  • 以 MySQL 为代表的 SQL DataBase，通常有 Master Slave 的 Replica 方法
    • Master for write, Slave for read
    • Slave 从 Master 中同步数据
  • 原理 Write Ahead Log
    • SQL DataBase 的任何操作，都会以 Log 的形式做一份记录
    • 比如数据 A 在 B 时刻从 C 改到了 D
    • Slave 被激活后， Master 每次的操作都会通知 Slave 来读取 Log
    • 因此 Slave 上的数据有延迟
  • Master 挂了怎么办?
    • 将一台 Slave 升级(promote) 为 Master，接受 Read + Write
    • 可能会造成一定程度的数据丢失和不一致

2.3 NoSQL Replica​

  • 以 Cassandra 为代表的 NoSQL DataBase 通常将数据顺时针存储在 Consistent hashing 环上的三个 virtual nodes中