大数据经典论文——Bigtable
作者：互联网
第一章 前言
前面介绍的GFS 和 MapReduce 通过非常简单的设计，帮助我们解决了海量数据的存储、顺序写入，以及分布式批量处理的问题。
不过我们也要看到，GFS 和 MapReduce 的局限性也很大。
在 GFS 里，数据写入只对顺序写入有比较弱的一致性保障。而对于数据读取，虽然 GFS 支持随机读取，但是考虑到当时 Google 用的是孱弱的 5400 转的机械硬盘，实际上是支撑不了真正的高并发地读取的。
而 MapReduce，它也是一个批量处理数据的框架，吞吐量（throughput）确实很大，但是延时（latency）和额外开销（overhead）也不小。
所以，即使有了 GFS 和 MapReduce，我们仍然有一个非常重要的需求没有在大型的分布式系统上得到满足，那就是可以高并发、保障一致性，并且支持随机读写数据的系统。而这个系统，就是接下来我们会深入讲解的 Bigtable。
本文主要通过下面三个问题，来深入理解Bigtable。
- Bigtable 想要解决什么问题？我们不能用 MySQL 这样的关系型数据库，搭建一个集群来解决吗？
- Bigtable 的架构是怎么样的？它是怎么来解决可用性、一致性以及容易运维这三个目标的？
- Bigtable 的底层数据结构是怎么样的？它是通过什么样的方式在机械硬盘上做到高并发地随机读写呢？
第二章 Bigtable的设计目标
Bigtable想要解决的问题是系统的可伸缩性和可运营性。
Bigtable最基础的目标自然是应对业务需求的，能够支撑百万级别随机读写 IOPS（input/Output Operations Per Second，即每秒进行读写(I/O)操作的次数），并且伸缩到上千台服务器的一个数据库。但是光能撑起 IOPS 还不够。在这个数据量下，整个系统的“可伸缩性”和“可运维性”就变得非常重要。
这里的伸缩性，包括两点：
- 第一个，是可以随时加减服务器，并且对添加减少服务器数量的限制要小，能够做到忙的时候加几台服务器，过几个小时峰值过去了，就可以把服务器降下来。
- 第二个，是数据的分片会自动根据负载调整。某一个分片写入的数据多了，能够自动拆成多个分片来平衡负载。而如果负载大了，添加了服务器之后，也能很快平衡数据，让各个节点均匀承担压力。
而可运维性，则除了上面的两点之外，小部分节点的故障，不应该影响整个集群的运行，我们的运维人员也不用急匆匆地立刻去恢复。集群自身也要有很强的容错能力，能够把对应的请求和服务，调度到其他节点去。
至于为什么不能使用MySQL来搭建集群？
MySQL如果要扩展成分布式的，需要分库分表，这需要一开始就对如何切分数据做好精心设计，一旦稍有不慎，设计上出现了数据倾斜，就很容易造成服务器忙得忙死，闲得闲死的现象。并且即使你已经考虑得非常仔细了，随着业务本身的变化，比如要搞个双十一，也会把你一朝打回原形。
以 MySQL 用户表分表作为例子，分到 4 台机器上，用了用户出生的月份“模”上个 4。这个时候，很幸运，一年是有 12 个月，正好可以均匀分布到 4 台不同的机器上。但是当我们进行扩容，变成 8 台机器之后，问题就出现了。我们会发现，服务器 A 分到了 1 月和 9 月生日的用户，而服务器 B 只分到了 6 月生日的用户。在扩容之后，服务器 A 无论是数据量，还是日常读写的负载，都比服务器 B 要高上一倍。而我们只能按照服务器 A 的负载要求来采购硬件，这也就意味着，服务器 B 的硬件性能很多都被浪费了。
而且，不但用月份不行，用年份和日也不行。比如公司是 2018 年成立，2019 年和 2020 年快速成长，每年订单数涨 10 倍，如果你用年份来进行订单的分片，那么服务器之间的负载就要差上十倍。而用日的话，双十一这样的大促也会让你猝不及防。
第三章 Bigtable的整体架构
标签：负载,GFS,读写,论文,经典,服务器,数据,Bigtable 来源： https://www.cnblogs.com/wkfvawl/p/15481281.html