这一章在做什么

读之前：先预测

第 6 章把同一份数据复制到多台机器上，解决的是容错和读的扩展；这一章换一个方向，把数据切开，每台机器只管一部分，解决的是数据量和写入量。两者通常一起用，但这一章先把复制放到一边。后面几章都会回到这里：第 8 章的分布式事务，起因是一次写要跨好几个分片；第 10 章的共识，是协调服务记录「分片在哪台机器」的底子；第 11 章的批处理按键把数据分给各个任务，用的也是哈希分片。

1. 按键的范围分片和按键的哈希分片，各自放弃了什么？§3.1§3.2
2. 为什么预先切出比机器多得多的分片，就能让加机器时只搬一小部分数据？这个数一开始定错了怎么办？§3.2
3. 哈希已经把键分匀了，为什么还会有热点？§3.3
4. 二级索引为什么不能顺着主键的分片走？本地索引和全局索引，各把代价放在读上还是写上？§5.1§5.2

这一章的骨架

全章按「切、搬、找」走：§1、§2 先问值不值得切，按租户切有什么好处；§3 是重心，讲按什么切、切不匀怎么办、加减机器时怎么搬；§4 讲请求怎么找到机器；§5 把二级索引放进来。容易乱的是 §3.2：一节里连讲四种做法（取模、固定分片数、哈希范围、一致性哈希），后一种在补前一种的短处。读的时候给每一种记下「加一台机器时搬的是什么」。

边读边填：每行一个问题，读到答案就写一两句。只存在你这台设备的浏览器里，别人看不到。

分节地图

全章约 7900 词（不算图注），是全书较短的一章，建议分三次读。第二次是重心，§3.2 一节就占了五分之一；第三次的两个话题彼此独立，可以分开读。

1. 第一次坐下§0–§3.1 · 约 2700 词 · 为什么分、按租户分、按键的范围分
2. A distributed database typically distributes…约 500 词开篇复制和分片有什么不同、怎么组合；方框里是分片在各个系统里的不同叫法。
3. Pros and Cons of Sharding约 500 词分片的利与弊为什么要分片，为什么作者劝你能不分就不分。分区键在这里第一次出场。
4. Sharding for Multitenancy约 600 词为多租户分片每个客户一个分片的七条好处和三个难处。列表长，挑你关心的细读。
5. Sharding of Key-Value Data约 300 词键值数据的分片目标是分得匀、能再平衡；倾斜、热点、热键三个词在这里定义。
6. Sharding by Key Range约 800 词按键的范围分片边界怎么定、范围查询的好处、时间戳当键的热点，以及分片怎么拆。
7. 第二次坐下§3.2–§3.4 · 约 2600 词 · 按哈希分、加机器怎么搬、热点和再平衡
8. Sharding by Hash of Key约 1700 词按键的哈希分片全章最长：取模、固定分片数、哈希范围、一致性哈希，一种补一种的短处。
9. Skewed Workloads and Relieving Hot Spots约 500 词负载倾斜与缓解热点哈希分匀了键，为什么还会有热点；拆热键的办法和它的代价。
10. Operations: Automatic Versus Manual Rebalancing约 400 词运维：自动还是手动再平衡自动再平衡省事，但和自动故障检测叠在一起时可能越帮越忙。
11. 第三次坐下§4–§6 · 约 2600 词 · 请求路由和二级索引，加小结
12. Request Routing约 800 词请求路由三种把请求送到对的机器的办法，以及谁来维护「分片在哪」这张表。
13. Sharding and Secondary Indexes约 200 词分片与二级索引二级索引为什么和分片对不上。
14. Local Secondary Indexes约 500 词本地二级索引每个分片只管自己的记录：写简单，读要问遍所有分片。
15. Global Secondary Indexes约 500 词全局二级索引索引按被索引的值另外分片：查一个条件快，写和多条件查询变难。
16. Summary约 500 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

按键的范围切，还是按键的哈希切

分片要做到两件事：每条记录只属于一个分片；各个分片分到的数据和请求大致一样多。决定一条记录进哪个分片的那个键，叫分区键（partition key）。

第一种切法按键的范围：把键排好序，切成几段连续的区间，每个分片管一段。边界不必等距，要跟着数据的实际分布定，可以由管理员手工指定，也可以让数据库在分片太大时自动一分为二。好处是相邻的键在同一个分片里，按范围查只碰一两个分片。麻烦在写入的键总落在同一头的时候：拿下单时间做键，「现在」那一段所在的分片接下全部新写入，其余分片闲着。

第二种切法先对键算哈希，再按哈希值分。好的哈希函数把挨在一起的键打散到整个取值空间，写入就匀了；代价是键的顺序没了，按键查一个范围要问遍所有分片。折中的办法是键由两部分组成，只拿第一部分当分区键：同一个分区键下的记录还在一个分片里，按第二部分排好序，照样能做范围查询。

键分匀了，负载不一定匀。一个特别热的键（一场热门演出开票时的库存）不管用哪种切法，都只落在一个分片上。这类倾斜要靠别的手段：把热键单独放一个分片，或者在应用里把一个键拆成很多个。

加一台机器，要搬多少数据

最直接的想法是 hash(key) % N，N 是机器数。问题出在 N 变的时候：除数一换，几乎每个键算出来的余数都变了。从 4 台加到 5 台，只有哈希值除以 20 余 0 到 3 的键留在原地，其余全要搬家，而新机器其实只需要接手五分之一。

解决办法是把一层映射拆成两层：键 → 分片，分片 → 机器。一开始就切出比机器多得多的分片，比如 240 个分片放在 6 台机器上，每台 40 个。键进哪个分片由 hash % 240 决定，永远不变；加机器时，只是把一些分片整个搬到新机器，再改一下分配表。代价是分片数要一开始猜对：机器数不能超过分片数；数据涨了几十倍，每个分片也跟着胖了几十倍。

另一条路是让分片数跟着数据走：每个分片管一段连续的哈希值，太大了就拆。有的系统再进一步，让每台机器在哈希值空间里取好几个随机边界，新机器加入时从别人的范围里各切走一小段。这一类「分片数变了也只搬最少的键」的算法，统称一致性哈希（consistent hashing）；这里的「一致」和副本一致性没有关系。

请求怎么找到那台机器

知道了键属于哪个分片、分片在哪台机器上，请求还得真的送过去。有三个地方可以做这件事：让任意一台机器接请求，不归它管就转发；在前面放一层专门的路由；让客户端自己记着分配表，直接连对的机器。不管放在哪，都绕不开同一个难题：分配表会变（加机器、搬分片、机器宕掉），谁来决定它、改了以后怎么通知所有做路由的人、搬到一半时发往旧机器的请求怎么办。很多系统把这张表交给一个靠共识算法保证不出错的协调服务；也有系统让节点之间互相传话，把变化慢慢散布出去，代价是可能出现两边对同一个分片看法不一的情况。

二级索引：跟着数据分，还是自己另外分

订单按订单号分片，按订单号查很快：算一下就知道去哪个分片。可是「查杭州的所有订单」用的是城市，城市和订单号没有关系，一个城市的订单散在所有分片里。

一种做法是每个分片只给自己的订单建索引（本地索引）。写一条订单只动一个分片；查杭州就要把查询发给所有分片，再把结果合并，分片越多，一次查询要等的分片越多。另一种做法是把索引本身按城市分片（全局索引）：杭州的条目全在同一个索引分片上，查一个条件只问一处；但写一条订单要同时改数据所在的分片和索引所在的分片，两处怎么保持一致就成了问题。

这一章点名的系统

动手：模拟器

先猜：6000 个键、4 台机器，用 hash % 机器数，加到第 5 台要搬多少个键？换成固定 24 个分片呢？再想想：按范围分片、每台机器只取 1 段边界时，新机器能分到公平的一份吗？猜好了再点。

1. 选「hash % 机器数」，从 4 台加到 5 台，对比「这次搬了几个键」和「理想最少要搬」；再加到 6 台。然后减回 5 台：白搬的又有多少？
2. 换成「固定数量的分片」，24 个分片，从 4 台加到 5 台：搬走的是哪几个分片？新机器分到的为什么比「理想」略少？改成 8 个分片，一路加到 9 台会怎样？
3. 换成「按范围分片」，每台 1 段，连加几台，看新机器各分到多少、「最多 / 最少一台」差多少；改成每台 16 段、256 段再试（书里说的两个默认值）。为什么段多了就匀了？

词与短语

词条按在书里出现的顺序排，按节分组；读一节之前先把这一节的过一遍，读的时候就不用停。斜体小字是原句里连续的几个词，在电子书里搜它就能找到那一句。标着「每个字都认识」的，是字面意思会把你带偏的。行话（rebalancing、hot spot 这类）不在这里，在上面的术语表里。

§0 A distributed database typically distributes…

§1 Pros and Cons of Sharding

§2 Sharding for Multitenancy

§3 Sharding of Key-Value Data

§3.1 Sharding by Key Range

§3.2 Sharding by Hash of Key

§3.3 Skewed Workloads and Relieving Hot Spots

§3.4 Operations: Automatic Versus Manual Rebalancing

§4 Request Routing

§5 Sharding and Secondary Indexes

§5.1 Local Secondary Indexes

§5.2 Global Secondary Indexes

§6 Summary

读完：回到你的预测

判断题：换成你来选

场景都是本站编的。先选，再看解释；解释里写了对应的节号，拿不准就回原书看那一节。

和本站其他书对照

值得停下来的句子

sharding is a heavyweight solution that is mostly relevant at large scale.— §1。本站译：分片是一种重型方案，大多只在规模很大时才用得上。

这句话给全章定了调。后面讲的每一种切法、每一种搬法、每一种索引，都是在为分片带来的复杂付账：要选分区键，跨分片的写要分布式事务，二级索引要么读贵、要么写贵。作者紧接着提醒，如今一台机器能做的事很多。读后面的每一节时，可以回来问一句：这份复杂，是为多大的规模付的？

adding more shards lets you store more data, but it doesn’t increase your query throughput if every shard has to process every query anyway.— §5.1。本站译：多加分片能多存数据，但如果每个分片反正都要处理每一个查询，查询吞吐并不会提高。

分片能扩展的，只是「一个请求只碰一个分片」的那部分负载。一类查询如果要扇出到所有分片，它就没有被分摊，只是被重复了 N 遍。所以选分区键，其实是在决定哪些查询能随机器数扩展、哪些不能；全局索引就是为某一类查询另选一个分区键。

检查一下理解

用一句话说这一章（写给一个没读过的朋友）：

精彩回顾

一句话：分片要在「分得匀、搬得少、查得快」之间取舍，而一台机器扛得住时，最好的分片方案是不分。