22 | Spanner（一）：“重写”Bigtable和Megastore
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Spanner: Google全球分布式数据库的设计与实现 Spanner是一篇介绍Google全球分布式数据库的论文，通过重新设计Bigtable和Megastore来解决它们的不足之处。文章详细解释了Spanner的整体架构设计，包括“宇宙”和“Zone”的概念，以及Spanserver和Location Proxy等组件的作用。Spanner的设计思路是通过动态调度数据来满足用户的需求，从而解决了Megastore在全球部署和网络延迟方面的挑战。文章还介绍了Spanner的数据模型和数据调度策略，以及Spanserver的架构和实现细节。通过Paxos算法实现数据同步复制，Spanner实现了数据调度，将数据记录调度到不同的数据中心，从而提升读写性能。 Spanner的整体架构将多个Zone里的分布式数据库组合在一起，每个数据中心拥有完全相同的副本，而Spanner的每个Zone里的数据可能是完全不同的。Spanner会根据应用设置的延时策略，将不同的数据调度到不同的数据中心，使得应用开发人员只需明确自己的应用需求，而不需要关心底层数据的分布。在单个Zone内，Spanner拥有Zonemaster、Spanserver和Location Proxy三种不同类型的服务器，它们可以对应到Bigtable里的Master、Tablet Server以及METADATA数据表。而多个Zone之上，Spanner会通过Universemaster来作为控制台，并提供Zone的各种信息方便debug，以及通过Placement Driver进行实际的数据分布和调度。 在Spanserver的实现里，Spanner采用了传统关系型数据库会使用的B树，以及单行数据整个作为一个值的模型。在数据的同步复制层面，Spanner将一个Tablet作为一个单元，使用Paxos算法在Tablet这个单位上进行数据同步复制。在数据调度层面，Spanner选择了把数据分成一小片一小片的目录，在不同的Paxos组里调度目录。而在数据模型层面，Spanner基本继承了Megastore的选择，同时有助于Spanner去调度数据，把经常要共同访问的数据放在相同的地区或Zone里面。 总的来说，Spanner的设计思想和技术特点为读者提供了深入了解全球分布式数据库的机会，对于理解分布式系统和数据库技术具有很高的参考价值。Spanner作
《大数据经典论文解读》，新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
EveryDayIsNew越往后越难懂，貌似留言也少了，老师也不回答了2021-11-26522
在路上徐老师好，读完spanner论文，我想megastore写操作慢，spanner替换bigtable有六个原因： 1.megastore第4.5节提到Replication Server的一个作用是最小化bigtable写操作带来的广域网通信次数，这说bigtable的一次写操作需要和客户端的通信多次。 2.Replication Server是无状态服务，它和bigtable在一个数据中心，但是和具体的tabletServer很可能不在一台服务器上，比起spanner这增加了写操作需要的中转和通信。 3.megastore写每个数据中心都要通过chubby查找tabletServer的位置，spanner确定写哪个tablet是发生在写每个数据中心之前，只需要查一次。 4.megastore为了提供本地读的特性，要求写操作必须通知到所有的副本，而不仅仅是多数副本，这让写操作变得更慢。 5.megastore paxos在并发提议的时候，后一个提议会退回到两阶段请求，spanner paxos采用有租期的Leader，并发提议会排队，不用退回两阶段请求，这在高延时的网络中很有用。 6.spanner需要提供全局事务，bigtable内部实现的锁，比如保证单行原子性修改的逻辑，是多余的。 不知道徐老师的答案是什么样的？2021-12-023- 在路上徐老师好，这节课对比Megastore和Spanner的部分我不太理解。在 Megastore 里，每个数据中心，都是一个 Paxos 集群里的一个副本，而且是一个完全副本。这样，在每一次的数据写入时，我们都需要有网络请求到所有的数据中心。 第一、Megastore论文第2.2.3节提到一个EntityGroup写入部分地区，一个地区有3个或5个副本，原文这样描述，To minimize latency, applications try to keep data near users and replicas near each other. They assign each entity group to the region or continent from which it is accessed most. Within that region they assign a triplet or quintuplet of replicas to datacenters with isolated failure domains. 第二、Magastore论文第4.4.3节提到副本有三种，full replica, witness replica, read-only replica。为什么所有副本一定是完全副本呢，可以用其他两种啊。2021-12-013
- 在路上徐老师好，读完论文的第1-2部分，我有两个问题。第一、Figure 2把tablet和replica画在了不同层级，这两个不是一个东西吗？ 第二、single paxos state machine和pipelined paxos是怎么样的paxos？我自己的理解是single paxos是指一个提议完成后，才能开始下一个提议，single paxos对应mutiple paxos，它允许多个提议并发，并且使用单调递增的编号，megastore写操作看起来就是用了mutiple paxos。pipelined paxos是在上一个提议还没有完成的情况下，下一个提议在Leader上排队，而不是像megastore一样退回到两阶段。2021-12-022
沉淀的梦想Spanner 是如何采用 B 树存储数据的呢？是像 MySQL 一样先找到根节点的 Tablet，然后不断地向下查找，直到找到叶子节点访问数据？感觉分布式环境下，这样效率是不是会有点低？ 还是说采用了某种 B 树变种？2023-01-02归属地：浙江2
核桃spanner架构的出现，首先就是提出了一个更高维度的类似全局管理者的概念，论文里面叫zone，也有一些架构设计实现叫resource manger,这个架构的出现，其实就类似分公司和集团总部的关系那样。 然后就是优化了抽象了调度模块出来，spanner的调度模块实现，和k8s的调度机制其实很类似的了，云原生领域，k8s集群调度服务到某个节点前，有两次选择，第一次是排除不适合的节点，第二次是在适合的节点挑选相对适合的。这里应该两者的思想和实现是类似的了。同时因为这些调度的策略不会经常太频繁改变，也不太会很多并发，因此可以考虑类似静态缓存数据那样保存起来。 当然除了调度以外，这里关于数据迁移的模块，这里涉及到的rebalance的概念，也就是数据重平衡，在glusterfs的实现里面，数据调度有两种，一种是数据移走，一种是数据不挪走，但是元数据改变。新节点下的更新指向原数据节点的信息，这样也算一种rebalance策略。因此在迁移调度过程中，这里为了保证数据读写平稳过渡，就可以借鉴这种思想去过渡了。2022-02-26
piboye有对标spanner 的开源实现了吗？2022-01-173- Helios如果广州、新加坡、西雅图的三副本，用户在西雅图写入master，是不是要等到复制到广州新加坡才算结束呢。2022-01-051
- Helioszone和数据中心的关系有点不理解，按照解释应该是一个数据中心可以有多个zone，一个zone中包含多个Spanserver，Spanserver有包含多个tablet。 但是“论文里的图2”确是按照数据中心维度的，也就意味着不同的zone之间也要进行数据同步么2021-12-29
