Design Facebook timeline
时间线我们需要考虑几年前甚至几十年前的事情。在高层我们需要扫描，聚集，和排名posts，分享，照片，签到来让最重要的事情浮出表面。
时间很紧，重要优先级终结技术风险是保持这个系统尽可能简单依赖于内部已经被证明的技术。决定建立在四个核心技术上：
- MySQL/InnoDB用于存储和复制
- Multifeed(增加News Feed的技术)用于排名
- Thrift用户communication
- memcached用于缓存 我们选择很好被理解的技术这样可以更好预测capacity needs依赖于存在的监控和操作的工具集
Denormalizing the data
去正则化数据
当开始时间线，存在的数据是高度正则化的，要求很多到数据库的来回。因为这个，依赖缓存来保持一切够快。当数据不在缓存里，也不可能clustered在磁盘上，会导致很多潜在的很慢，随机的磁盘读取。来支持时间线的排名模型，希望保持所有数据都在缓存中，包括不被展示的低值数据。
需要一个巨大的去正则化过程来保证所有需要的数据用于排名可被提供在少量的IO有效的数据库请求中。
一旦去正则化，数据库的每行包含行动数据和足够的排名数据这样它可以被选中或被取消没有额外的数据获取。排序数据通过(user,time)在磁盘中，InnoDB做了巨大的工作从磁盘中流读取数据用一个主要键值范围的查询。
去正则化过程的一些特定的挑战包括：
- 旧系统的成打的各种数据格式在这么多年内不断演变。一个实习生定义了自定义语言来简明地表达我们的数据格式转换规则，写了一个编译器把这变成可运行的PHP。三个“考古学家”写了转换规则。
- 不是最近的activity-data被移到了缓慢的网络存储中。建立一个只读版本的MySQL，部署成千上万的服务器来运用最大IO压力，复制这个数据在数个星期。
- 大量的join查询做了成千上万的随机IO。合并join表格到a tier of falsh-only数据库。传统的PHP可以进行数据库查询一次只有一个服务器，写了一个并行查询代理允许我们查询整个join tier并行地。
- 未来-证明数据策略。我们采取了一个数据模型和MultiFeed兼容的。这是更加弹性提供了更多数据的语义上下文，增加了好处允许更多代码重用。
时间线聚集
建立时间线聚集在数据库之上。开始作为Multifeed的修正的版本，现在运行在每个数据库盒子上，允许我们最大化磁盘不用发送数据到网络不会被显示在页面上。