分片与DFS

Question

据我所知，分片(例如在MongoDB中)和分布式文件系统(例如在HBase或HyperTable中的HDFS )是数据库用于横向扩展的不同机制，然而我想知道它们如何比较？

Answer 1

传统的分片包括将表分成几个小块，并在单独机器上的单独数据库中运行每个块(或“分片”)。由于分片大小较大，这种机制很容易由于热点和不均匀增长而导致不平衡，Foursquare incident就证明了这一点。此外，由于每个分片都在单独的机器上运行，因此如果其中一台机器宕机，这些系统可能会遇到可用性问题。为了缓解这个问题，包括MongoDB在内的大多数分片系统都实现了复制组。每台机器由一组三台机器替换，其中一台机器采用主从配置，另加两台从配置。这样，如果一台机器宕机，还有两个副本可以为数据提供服务。这种设计有几个问题:首先，如果复制组中的一个副本失败，并且该组只剩下两个成员，为了将复制计数恢复到三个，需要克隆这两台机器中的一台上的数据。由于整个群集中只有两台机器可用于重新创建副本，因此在进行重新复制时，这两台机器中的一台上将会出现巨大的拖拽，从而在相关碎片上造成严重的性能问题(通过千兆位链路拷贝1TB将占用两个小时的时间)。第二个问题是，当其中一个副本宕机时，需要用一台新机器替换它。即使群集中有足够的空闲容量来解决复制问题，这些空闲容量也不能用于纠正这种情况。解决这个问题的唯一方法就是更换机器。随着集群规模增长到数百或数千台机器，从操作的角度来看，这变得非常具有挑战性。

Bigtable+GFS设计解决了这些问题。首先，表数据被分解成更细粒度的“写字板”。Bigtable集群中的典型机器通常都有500+平板电脑。如果出现不平衡，只需将少量平板电脑从一台计算机迁移到另一台计算机即可解决。如果TabletServer宕机，因为数据集被分解并以如此精细的粒度进行复制，可能会有数百台机器参与恢复过程，这将分散恢复负担并加快恢复时间。此外，由于数据没有绑定到特定的一台或多台机器，因此集群中所有机器上的空闲容量都可以应用于故障。不需要更换机器，因为整个集群中的任何备用容量都可用于纠正复制不平衡。

Hypertable Inc.首席执行官道格·贾德