装不下或忙不过来：把数据和工作分开
当单机在容量、吞吐量或可靠性上不再满足需求时，可以考虑把数据与任务分配到多台机器。分片把不同部分分开存放；副本把同一份数据复制到多个位置，它们解决的问题并不完全相同。
分布之后还要处理机器故障、网络延迟、数据一致性和权限。引入更多机器会增加能力，也增加运行与维护成本。
按地区拆分订单是分片；为了机器故障后还能读取，把订单保留多份是副本。
带走这一点 · 先明确单机遇到的限制，再讨论是否需要分布式。
一起干活：拆任务、局部处理、汇总
如果任务能被拆开，多台机器可以分别处理一部分，再汇总结果。这样的思想可以用于计算总和、计数、搜索和批量转换。
加速不会自动等于机器数量。任务分发、传输、合并都需要时间，还有无法并行的部分和负载不均衡。小任务甚至可能比单机更慢。
八个人统计八箱票据，最后仍需要核对与汇总。只有一张票据时，叫齐八个人的成本反而更高。
带走这一点 · 评估并行方案时，同时考虑可拆分工作和协调开销。
机器越多，就一定越快吗？
改变任务规模和机器数量，观察一个含固定串行工作与协调成本的计算模型。
估算单位时间: 3.0 + 17.0 + 0.0. 分工带来收益，但加速不等于机器数量。
时间是教学公式的结果，不是云服务报价、真实基准或性能保证。
搜索为什么快：很多工作提前做了
搜索服务通常提前抓取或接收内容，进行处理并建立索引。你输入关键词时，它主要查询已有的索引，再结合排序等机制返回结果，而不是临时逐个访问整个互联网。
分布式架构可以帮助处理规模和请求量，但速度也受索引、缓存、算法、硬件与网络影响。不能用“机器变多”解释所有性能提升。
在书里找“数据库”，先查索引再去对应页，通常比每次从第一页读到最后更有效。
带走这一点 · 如果数据重复被查询，先想能否提前整理或缓存，而不只是增加机器。
用户行为分析：从事件到问题
点击、打开、完成任务等动作可以记录成事件，包含时间、事件类型和必要上下文。将事件按明确口径聚合，才能得到可以解释的统计。
“点击了按钮”不等于“功能成功”，统计也要注意重复事件、时间范围、缺失数据和采集范围。只记录服务目的需要的数据，并说明采集方式。
想知道清单是否有用，可以观察“成功添加任务的人数”和“完成任务的人数”。单看页面打开次数，回答不了这个问题。
带走这一点 · 先提出要回答的问题，再决定记录什么事件。
普通项目什么时候需要关心规模
先让一个真实需求可用，再观察数据量、请求量、延迟和资源使用。根据证据，可以逐步改善查询、索引、缓存或部署方式，不必开局就引入复杂集群。
云资源可以按需使用，但费用、运维和失败处理仍然存在。分布式不是项目成熟的徽章，能够用适合的复杂度稳定解决问题更重要。
只有几十条记录的个人清单，先保证刷新不丢数据；当多人同时使用真的出现瓶颈时，再检查对应层。
带走这一点 · 把复杂度花在已确认的问题上。
把一个很小的任务从 1 台机器分到 8 台，为什么可能反而变慢？
先选一个答案，再看解释。
有人要求把小清单改成分布式系统。先写一段让 AI 评估必要性的需求。
先自己想，再按需打开提示。越往后，描述越完整，验收也越明确。
带着本章的背景去问 AI。拓展是选学，不影响继续阅读。
用多人整理书库解释分片、副本与汇总。
参考答案，可以改成你的版本
我正在从零学习计算机与 AI 编程。本章学过： 大数据：认识分布式存储、并行计算和协调开销；理解搜索通常依赖提前建立的索引；把用户行为分析还原成事件与统计 用多人整理书库解释分片、副本与汇总。 请先确认我的理解，一次解释一个小问题，用具体例子并说明比喻的局限。讲完问一道情境题，根据我的回答继续。区分事实、推测和不确定内容；推荐可操作的验证方式。如果涉及具体工具，先确认版本，不要编造功能和资料。
完成这一章
标记各节已读，完成原理实验和情境题后，即可记录本章完成。随时可以直接阅读下一章。
继续查阅原始资料
正文是入门解释；下面的官方资料供你继续核对和深入。
Google Research · MapReduce