欢迎您访问365答案网,请分享给你的朋友!
生活常识 学习资料

Bigtable:为何需要Bigtable而不是MySQL集群

时间:2023-04-18

自己通过阅读了解论文和极客时间相关讲解,并通过自己已有的框架知识,总结该文章,阅读需要有一定的Hbase,Zookeeper基础知识。

为何需要Bigtable而不是MySQL集群

对于将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 这个高可用的分布式锁服务解决一致性的挑战

Copyright © 2016-2020 www.365daan.com All Rights Reserved. 365答案网 版权所有 备案号:

部分内容来自互联网,版权归原作者所有,如有冒犯请联系我们,我们将在三个工作时内妥善处理。