GOOGLE分布式数据库技术演进研究--从Bigtable、Dremel到Spanner（三）

最新推荐文章于 2024-03-28 14:31:26 发布

u013427959

最新推荐文章于 2024-03-28 14:31:26 发布

阅读量3.2k

点赞数

分类专栏：大数据分布式数据库数据库文章标签：大数据 Bigtable dremel spanner 分布式数据库

本文链接：https://blog.csdn.net/x802796/article/details/18861465

版权

本文探讨了谷歌分布式数据库的发展，从Bigtable到Spanner的演进。Spanner作为Bigtable的进化版，解决了扩展性和事务一致性的挑战。它引入了独立时间戳、Paxos状态机等机制，支持半关系模型和全球分布式架构，旨在提供高一致性、可扩展性的数据库服务。文章详细介绍了Spanner的数据模型、系统架构、查询机制以及关键技术创新，如TrueTime时间同步技术。

摘要由CSDN通过智能技术生成

4 Spanner

4.1背景

在google的BIGTABLE论文中，提到过Bigtable后续计划支持多Master的方向，由于BIGTABLE的架构中，只有一个Master服务器，因此一个Bigtable分布式数据库的扩展能力，始终是由一定的限制，数据量增加后，势必需要就会出现瓶颈，如何提升数据库的数据管理能力，解决数据规模不断增加后带来的问题。同时Bigtable丢失传统RDMS系统的一些特点，比如多数据表之间的事务一致性，这些都是数据库必须也是应该具背的特性。是否能够满足分布式数据库的数据分布、负载和吞吐量的同时，还具备关系数据库特性，这不就是分布式数据库的智高无上的理想吗？但分布式数据库CAP理论告诉我们，分布式数据库一致性，可用性、分区容忍性此特性必然只能取其二，是不可能同时具备，这个魔咒能够被打破吗？

阿迪有一句名言“Nothing is impossible”势必需要引入一种新的机制,聪明的Google人找到并解决方案，并在技术上得以实现，Spanner就是在这个场景下面诞生。

4.2 Spanner的数据模型

4.2.1 带独立时间戳映射结构

Spanner有一种负责专门管理数据的spanserver，spanserver也是基于bigtable的tablet结构，每个spanserver由上百个或者上千个tablet构成，Spanserver类似于Bigtable中tablet服务器，是管理数据的核心组件，spanserver的Tablet存在下面映射(key:string, timestamp:int64) –> string，这种映射与Bigtable采用的Key-Value结构第一眼看去貌似一样，但仔细看确有很大差别，时间字段不在是Key一个组成部分，而是把时间戳单独了出来作为一个独立项，构成了一个多版本的数据库，独立时间戳意味着时间在Spanner中会扮演重要角色。

4.2.2 spanserver的软件层次

一个tablet由数据和状态部分构成，存放在一种称作Colossus的文件系统中，该文件系统为GFS后继的文件系统，为了支持数据同步复制，在spanserver上部署有一个paxos状态机, paxos状态机用于实现一系列被一致性复制的映射。一个数据有多个数据副本，多个数据副本所在的paxos状态机组织成一个paxos 分组，用于控制副本一致性。对于主副本，spanserver会增加锁表来保证并发性控制，对于在一个跨越多个Paxos分组的事务，需要在Paxos更上层的确定出主副本机制，以保证跨Paxos分组的事务性。整个结构如图4-1所示，在图中可以看出，由于涉及同步的复制范围不同，需要参与协商Leader的范围就会发生变化，但不管如何变化，始终是可以根据上升的原则，通过协商机制，实现更大范围的事务控制。