随着使用增长和功能堆积，应用开始生成更多数据，通常按小时计。这对业务是健康信号。但在架构上，它亮起红旗：数据库开始显示压力。
数据库位于几乎每个系统的核心。读取、写入和更新通过它漏斗。然而，与无状态服务不同，数据库以难以水平扩展著称。CPU 和内存可以升级，但在某个点，单个实例，无论多强大，成为瓶颈。响应时间退化，查询可能超时。副本落后。突然，在 10,000 用户工作的在 1000 万用户崩溃。
这就是分片进入画面的地方。
分片将大数据库分割成更小的、独立的块，称为分片。每个分片处理数据的子集，允许流量和存储在多台机器上扩展而不是堆积在一台上。
但分片是主要转变，有真实后果。应用逻辑通常需要适应。查询模式改变，连接变得更难。事务跨越物理边界。管理路由、重新平衡和故障转移有开销。
本文查看数据库分片的基础。我们涵盖细节如为什么重要、如何工作，以及携带什么权衡。我们将遍历常见分片策略和实际工程考虑。
为什么需要分片
- 单机瓶颈：单个实例无法处理海量数据
- 性能退化：查询变慢，超时增加
- 扩展困难：数据库难以水平扩展
- 副本落后：读写差距拉大
分片如何工作
分片将数据分割成独立块，每个分片：
- 处理数据子集
- 独立运行
- 可独立扩展
常见分片策略
1. 基于范围分片
- 按键值范围分配数据
- 适合范围查询
- 可能导致热点
2. 哈希分片
- 使用哈希函数分配数据
- 数据分布均匀
- 范围查询困难
3. 目录分片
- 使用查找表映射键到分片
- 灵活性高
- 单点故障风险
工程考虑
路由
- 如何确定数据在哪个分片
- 需要路由层或客户端逻辑
重新平衡
- 数据迁移复杂
- 需要最小化停机时间
故障转移
- 单分片故障不影响整体
- 需要复制和监控
跨分片操作
- 连接困难
- 事务复杂
- 尽量避免跨分片查询
权衡
优势
- 水平扩展能力
- 性能提升
- 存储容量增加
挑战
- 应用逻辑复杂化
- 运维开销增加
- 跨分片查询困难
- 重新平衡复杂
本文为学习目的的个人翻译，译文仅供参考。
原文链接：A Guide to Database Sharding: Key Strategies。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。