构建和运维基础设施组件的要求在许多方面是不同于消费者服务的。一个根本的区别是，基础设施组件有多个客户，而他们通常有很多不同的需求。

Bigtable是一个大型结构化数据分布式存储系统，一些面向消费者的服务数据直接通过它服务用户请求。这样的服务需要很低的延迟和较高的可靠性。其他团队则把 Bigtable 作为离线分析的数据存储使用（例如，MapReduce）。这些团队往往更关注吞吐量而非可靠性。这两个情况的风险容忍度相当不同。

能够同时满足两种情况的要求的一种方法就是将所有基础设施服务做得极为可靠。但在实际情况中，这些基础设施服务往往需要占用大量资源，超高可靠性的代价通常是非常昂贵的。为了更好地了解不同类型用户的不同需求，我们可以分析每个用户对自己Bigtable 请求队列的期望。

低延迟的用户希望 Bigtable的请求队列（几乎总是）为空，这样系统可以立刻处理每个出现的请求。（事实上，效率低下的排队过程往往是导致较高的长尾延迟的原因。）而离线分析的用户更感兴趣的是系统的吞吐量，因此用户希望请求队列永远不为空。为了优化吞吐量，Bigtable 系统应该避免处于空闲状态。

这样看来，对于这些用户而言，成功和失败是相反的。低延迟用户的成功是关注离线分析的用户的失败。

一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。

在 Bigtable的例子中，我们可以构建两个集群∶低延迟集群和高吞吐量集群。低延迟集群是为那些需要延迟较低和可靠性较高的服务而设计的。为了确保队列长度最小和满足更严格的客户端隔离要求，Bigtable 系统可以配备更多的冗余资源。另一方面，高吞吐量集群的配置冗余度较低，利用率较高。在实践中，高吞吐量集群只有低延迟集群成本的10%~50%。由于Bigtable是广泛部署的系统，这种成本上的降低非常显著。

:)