从Google Spanner漫谈分布式存储与数据库技术.docx

从GoogleSpanner漫谈分布式存储与数据库技术

第一篇：从GoogleSpanner漫谈分布式存储与数据库技术从GoogleSpanner漫谈分布式存储与数据库技术文/曹伟Spanner的设计反映了Google多年来在分布式存储系统领域上经验的积累和沉淀，它采用了Megastore的数据模型，Chubby的数据复制和一致性算法，而在数据的可扩展性上使用了BigTable中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner代表了分布式数据库领域的新趋势——NewSQL。Spanner是Google最近公开的新一代分布式数据库，它既具有NoSQL系统的可扩展性，也具有关系数据库的功能。例如，它支持类似SQL的查询语言、支持表连接、支持事务（包括分布式事务）。Spanner可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套Spanner集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google广告业务的后台（F1）已从MySQL分库分表方案迁移到了Spanner上。数据模型传统的RDBMS（例如MySQL）采用关系模型，有丰富的功能，支持SQL查询语句。而NoSQL数据库多是在key-value存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner继承了Megastore的设计，数据模型介于RDBMS和NoSQL之间，提供树形、层次化的数据库schema，一方面支持类SQL的查询语言，提供表连接等关系数据库的特性，功能上类似于RDBMS；另一方面整个数据库中的所有记录都存储在同一个key-value大表中，实现上类似于BigTable，具有NoSQL系统的可扩展性。在Spanner中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图1中创建的两个表——用户表（Users）和相册表（Albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一个用户）对应着相册表中的多条记录（多个相册）。此外，要求子节点的主键必须以父节点的主键作为前缀。例如，用户表的主键（用户ID）就是相册表主键（用户ID+相册ID）的前缀。图1schema示例，表之间的层次关系，记录排序后交错的存储显然所有表的主键都将根节点的主键作为前缀，Spanner将根节点表中的一条记录，和以其主键作为前缀的其他表中的所有记录的集合称作一个Directory。例如，一个用户的记录及该用户所有相册的记录组成了一个Directory。Directory是Spanner中对数据进行分区、复制和迁移的基本单位，应用可以指定一个Directory有多少个副本，分别存放在哪些机房中，例如把用户的Directory存放在这个用户所在地区附近的几个机房中。这样的数据模型具有以下好处。一个Directory中所有记录的主键都具有相同前缀。在存储到底层key-value大表时，会被分配到相邻的位置。如果数据量不是非常大，会位于同一个节点上，这不仅提高了数据访问的局部性，也保证了在一个Directory中发生的事务都是单机的。Directory还实现了从细粒度上对数据进行分区。整个数据库被划分为百万个甚至更多个Directory，每个Directory可以定义自己的复制策略。这种Directory-based的数据分区方式比MySQL分库分表时Table-based的粒度要细，而比Yahoo!的PNUTS系统中Row-based的粒度要粗。Directory提供了高效的表连接运算方式。在一个Directory中，多张表上的记录按主键排序，交错（interleaved）地存储在一起，因此进行表连接运算时无需排序即可在表间直接进行归并。复制和一致性Spanner使用Paxos协议在多个副本间同步redo日志，从而保证数据在多个副本上是一致的。Google的工程师钟情于Paxos协议，Chubby、Megastore和Spanner等一系列产品都是在Paxos协议的基础上实现一致性的。Paxos的基本协议很简单。协议中有三个角色：Proposer、Acceptor和Learner，Learner和Proposer分别是读者和写者，Acceptor相当于存储节点。整个协议描述的是，当系统中有多个Proposer和Acceptor时，每次Proposer写一个变量就会启动一轮决议过程（Paxosinstance），如图2所示。决议过程可以保证即使多个Proposer同时写，结果也不会在Acceptor节点上不一致。确切地说，一旦某个Proposer提交的值被大多数Acceptor接受，那么这个值