据我所知，分片(例如MongoDB)和分布式文件系统(例如HBase或HyperTable中的HDFS)是数据库用于扩展的不同机制，但我想知道它们如何比较?
传统的分片包括将表分解成一小部分，并在单独机器上的单独数据库中运行每个部分(或"shard")。由于分片大小很大，这种机制容易因热点和不平等增长而导致不平衡，Foursquare事件就是证明。此外，由于每个分片在单独的机器上运行，如果其中一台机器出现故障，这些系统可能会遇到可用性问题。为了缓解这个问题，大多数分片系统(包括MongoDB)都实现了副本组。每台机器都替换为一组三台机器，采用主设备加两台从设备的配置。这样，如果一台机器出现故障，就有两个剩余的副本来提供数据。这种设计存在几个问题:首先，如果复制组中的一个复制失败，并且该组只剩下两个成员，那么要将复制计数恢复到三个，就需要克隆这两台机器中的一台上的数据。由于整个集群中只有两台机器可以用于重新创建副本，因此在进行重新复制时，这两台机器中的一台将受到巨大的拖累，从而导致相关分片出现严重的性能问题(在千兆链路上复制1TB需要两个小时)。第二个问题是，当其中一个副本出现故障时，需要用新机器替换。即使整个集群有足够的备用容量来解决复制问题，这些备用容量也不能用于纠正这种情况。解决这个问题的唯一办法就是更换机器。当集群规模增长到数百或数千台机器时，从操作的角度来看，这变得非常具有挑战性。
Bigtable+GFS设计解决了这些问题。首先，表数据被分解成更细粒度的"片"。Bigtable集群中的典型机器通常有500多个平板电脑。如果出现不平衡，解决这个问题只需将少量平板电脑从一台机器迁移到另一台机器。如果TabletServer出现故障，因为数据集被分解并以如此细的粒度进行复制，可能会有数百台机器参与恢复过程，这将分配恢复负担并加快恢复时间。此外，由于数据没有绑定到特定的一台或多台机器，因此集群中所有机器上的空闲容量都可以应用于故障。不需要更换机器，因为整个集群的任何空闲容量都可以用来纠正复制不平衡。
- 道格·贾德Hypertable Inc. CEO