为何需要Bigtable而不是MySQL集群自己通过阅读了解论文和极客时间相关讲解，并通过自己已有的框架知识，总结该文章，阅读需要有一定的Hbase,Zookeeper基础知识。
对于将MySQL扩展成分布式，我们无非是进行分库分表（但也失去了外键关联，事务等特性）.
垂直分库：将一张表根据不同的实体，拆分到不同的物理数据库中。
垂直分表：将一张表，根据ID分片，mod分片数，根据余数分配到不同的物理数据库中。
翻倍扩容
当业务扩大，用户量增多，服务器性能捉襟见肘时，我们需要进行扩容负载均衡，可能我们仅需要扩容两个，但不得不扩容四个。
如果扩容两个，也就是六个服务器原来的mod 4变为mod 6，这意味着个数据搬运，不只是搬到新增加的服务器上，而是有些数据还要在原有的 4 台服务器上互相搬运。而如果是翻倍扩容，mod 8，我们只需要搬运原来服务器一半的数据。但更加浪费的是，我们扩容可能是因为大促活动，只需要一小段时间，完成后我们还需要进行缩减。这也相当麻烦，我们需要再把两台服务器的数据复制到一台服务器上，才能完成缩容。
可以看出MySQL的伸缩并不是很容易，搬运过程占用大量的网络带宽和硬盘读写，很有可能会使得数据库暂停服务。
我们所希望的伸缩性是可以随意的增减服务器，且不会停机。
数据分区
MySQL 集群，需要我们对切分数据做好精心设计。
如：对于用户表。我们将数据分到 4 台机器上，使用出生的月份mod 4。这时候，一年有 12 个月，我们可以均匀分布到 4 台不同的机器上。但是当我们进行扩容，变成 8 台机器之后，我们会发现，服务器 A 分到了1 月和 9 月生日的用户，而服务器 B 只分到了 6 月生日的用户。在扩容之后，服务器 A 无论是数据量，还是日常读写的负载，都比服务器 B 要高上一倍。而我们只能按照服务器 A的负载要求来采购硬件，这也就意味着，服务器 B 的硬件性能很多都被浪费了。如果根据年，可能哪一年公司发展壮大，导致负载不均衡；如果根据日，面对大促日期，我们又无从应对。
我们所希望的是数据可以自己进行负载均衡，可以自适应。
可运维性
在MySQL集群中，我们对于每个服务器都会进行一个高可用的备份，但是当服务器出现故障时，我们仍旧需要立即修复，避免产生单点问题。
我们希望的可运维性是，如果有服务器故障，我们可以将其下线，用剩下的服务器仍旧可以完成工作。
综上，BigTable的目标是可伸缩性与可运维性。可伸缩性又分为随时的增减机器和负载均衡。
可以看到我们并不希望，一开始就已经做好决策，而是有着向后兼容，动态调整的特性。
针对这些问题，Hbase的做法是
第一点，是将整个系统的存储层，搭建在 GFS 上。通过单 Master 调度多 Tablets的方式，使得整个集群非常容易伸缩和维护。
第二点，是通过 MemTable+SSTable 的底层文件格式，解决高速随机读写数据的问题。
第三点，是通过 Chubby 这个高可用的分布式锁服务解决一致性的挑战