大数据经典论文解读
徐文浩
bothub 创始人
13843 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 59 讲
大数据经典论文解读
15
15
1.0x
00:00/00:00
登录|注册

08 | Bigtable(一):错失百亿的Friendster

你好,我是徐文浩。
过去两周,我们一起看完了 GFS 和 MapReduce 的论文。相信这个时候的你一定自信满满,有一种“我上我也行”的感觉。的确,GFS 和 MapReduce 通过非常简单的设计,帮助我们解决了海量数据的存储、顺序写入,以及分布式批量处理的问题。
不过我们也要看到,GFS 和 MapReduce 的局限性也很大。
在 GFS 里,数据写入只对顺序写入有比较弱的一致性保障。而对于数据读取,虽然 GFS 支持随机读取,但是考虑到当时 Google 用的是孱弱的 5400 转的机械硬盘,实际上是支撑不了真正的高并发地读取的。
而 MapReduce,它也是一个批量处理数据的框架,吞吐量(throughput)确实很大,但是延时(latency)和额外开销(overhead)也不小。
性能可以分成“吞吐率”和“响应时间”两个角度,我在之前的专栏中单独讲过这个主题
所以,即使有了 GFS 和 MapReduce,我们仍然有一个非常重要的需求没有在大型的分布式系统上得到满足,那就是可以高并发、保障一致性,并且支持随机读写数据的系统。而这个系统,就是接下来我们会深入讲解的 Bigtable。我会通过三讲,带你深入理解三个问题:
Bigtable 想要解决什么问题?我们不能用 MySQL 这样的关系型数据库,搭建一个集群来解决吗?
Bigtable 的架构是怎么样的?它是怎么来解决可用性、一致性以及容易运维这三个目标的?
Bigtable 的底层数据结构是怎么样的?它是通过什么样的方式在机械硬盘上做到高并发地随机读写呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Bigtable: 分布式系统中的数据库利器 本文深入探讨了分布式系统中的数据库挑战,并以Friendster社交网络为例,展示了传统数据库在处理大规模数据时的性能瓶颈。文章指出使用MySQL集群进行分库分表的扩容方式并非最佳解决方案,因为翻倍扩容会导致资源浪费,数据分区策略对应用不透明,以及故障恢复需要人工介入。相比之下,Bigtable作为一个高并发、保障一致性,并且支持随机读写数据的系统,解决了传统数据库无法解决的问题。 Bigtable的设计目标是实现自适应的数据分片和可运维性,使得系统能够自动应对服务器节点的故障,减少人工介入,从而提高系统的稳定性和可靠性。文章还介绍了Bigtable的设计思路和GFS以及MapReduce的相似之处,以及放弃了关系模型和跨行事务的重要性。Bigtable的设计思路使得工程师不需要学习新知识,只需熟悉分布式系统给到的接口,就能上手写大型系统。 在“大数据时代”,在需要上千台服务器的集群之下,Bigtable针对可伸缩性和可运维性的需求提供了解决方案,包括将整个系统的存储层搭建在GFS上、通过底层文件格式解决高速随机读写数据的问题,以及通过Chubby解决一致性的挑战。 总的来说,本文生动地阐述了Bigtable的重要性和必要性,为读者展现了其在分布式系统中的重要作用。Bigtable的设计目标是应对业务需求,支持百万级别随机读写IOPS,并且伸缩到上千台服务器的一个数据库,同时注重可伸缩性和可运维性。文章还提到了Bigtable的实现细节,为读者提供了深入了解Bigtable的机会。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大数据经典论文解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(7)

  • 最新
  • 精选
  • webmin
    今天的思考题我理解是要考查多读多写的设计,先分析一下场景,双向关注也是大V被关注多,而关注的人被关注人数也不会多,为了后面描述方便,在这里把大V简称为H,非大V简称为L。 对于H: 1. H发的贴读的人相对来说比较多; 2. H需要看到的人的也比较多; 居于上述两点, 1. H发的贴一天内的贴子用一行多列来记录,即日期+_+H_ID+_+W为Key,每一条内容为一列; 2. 关注H的人发的贴也是同一天的贴子写入H的读行,即日期+_+H_ID+_+R为Key,关注的人发的每一条内容为一列,当然如果关注的人中也有H那么这个H的写还是参照1,读这个H的贴子请看3; 3. 如果H关注的人中也有H,那么就去他关注的H的日期+_+H_ID+_+W行去读取贴子 对于L: 1. L发的贴读的人相对来说较少; 2. L需要看到的人的贴子相对较少; 居于上述两点, 1. L发的贴都写到关注他的人的各自每日读贴子行中,即如果有100个人关注了L,那么L如果发贴就向这100人分别写数据; 2. L读贴时如果检查L有关注H,那么对于H的贴子,就需要去H的日期+_+H_ID+_+W行去读贴子
    2021-10-06
    2
    8
  • 思考题 假设采用方案一:一种是用户发帖子的时候,系统往所有好友的时间线里写一条数据。 关键在于通过主键避免读写热点,并减少过多的随机读写。 主键差不多就是: 时间+用户+random(比如0-9) 写的时候一方面用户较多,能够将写入压力分散到各个用户。且按时间排,数据的冷热分布也较好处理。 而读的话,每个用户的读取其时间线也是可以做到将数据尽量聚集在特定的几个数据区域,避免频繁的随机读。但对于超级海王之类的用户就可能不友好了,那能怪谁呢。
    2021-10-06
    2
  • 王政
    关系表存储以用户唯一id为主键,双向好友的id列表的关系 内容表按照时间分片,存储以用户唯一id为主键,时间,事件内容的表 当用户查询自己的时间线时,先获取包括他自己在内的所有好友用户id,在时间最近的内容表内按照用户id筛选时间和内容(可以为用户id建索引),按照时间倒叙返回。 同时存在一个缓存系统,先查询最近的时间片,更早的时间内容通过一定的预读取缓存起来,只有用户发出查看更多等指令时才返回并更新缓存。
    2023-02-21归属地:贵州
    1
  • 核桃
    这一篇文章有几个有趣的地方. 1.首先是关于用户数据分区的问题,这一点在数据密集型系统设计那本书里面提到过,对于用户的消息,其实不是马上要看到的,例如A发了一条动态消息,但是其列表用户只是登录之后才需要看到,因此这里有一个延迟的。可以用一个缓存队列那些来解决。但是对于热门大V则不一样了,需要特殊处理。 2. 分区这里,其实现在业界的用户,一般都是用一个bigint的用户id来进行分区,理论上, 这样是可以相对均衡一点的,但是这样做,在以前的MySQl集群中,需要做一些rebalance操作,这个操作哪怕放到现在,都是一个噩梦般的操作,哪怕现在分布式对象存储系统minio那些,都是不支持集群扩缩容,宁可重新搭建一个新的系统,然后上层搭建一个元数据中心管理等方式来解决。因此如果业界有一个很好的Hash算法,或者说能代替现在的Hash的算法,那么未来无限扩容的集群才真正可以被解决,否则还是基于算力提升下的扩容罢了。
    2021-11-21
    1
  • 泊浮目
    内容表:发贴的人名字为k,内容为v。v里面携带了内容+时间戳。 当follower想看内容的时候,根据k去拉取,然后筛选时间、排序,拿到自己想要的内容。
    2021-10-10
  • 那时刻
    关于思考题。我的想法是,一个是用户关系表存储一个用户及其好友关系。比如Jose与 Fred以及Ben是好友, row key是用户名 Jose Fred Ben 另外一个是个人的事件表。row key是用户名以及时间,方便按照时间倒序查看 Fred#ts1 balabala... Fred#ts2 jiligala... Ben#ts3 balagala...
    2021-10-06
  • Monroe He
    Bigtable的row键是有序的,在生成row键的时候应该考虑将双向关注的用户尽量放在一起,可以考虑按照地区生成row键值,每个用户一条记录,将好友帖子存放在记录中,当好友row键值相邻时也有利于数据压缩
    2021-10-06
收起评论
显示
设置
留言
7
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部