Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Google Cloud Spanner的实践经验

Google Cloud Spanner的实践经验

作者头像
ThoughtWorks
发布于 2022-08-26 06:20:11
发布于 2022-08-26 06:20:11
1.7K0
举报
文章被收录于专栏:ThoughtWorksThoughtWorks

Cloud Spanner是Google Megastore系统的继承者,Spanner表现出远超前辈的能力。Spanner首次是在Google内部数据中心中出现,而在2017年才对外发布测试版并加入了SQL能力。如今已经在Google云平台上架并拥有大量各个行业的用户。Cloud Spanner数据库是全球范围分布式关系型/事务数据库,并且Google承诺Cloud Spanner拥有高吞吐量、低延迟和99.999%的高可用性。

接触Cloud Spanner

第一次接触到Google Cloud Spanner是因为客户对于新技术的追求与尝试,将我们基本完成的APIs从原先的Google Cloud Sql迁移到Cloud Spanner数据库上。在做这个决定的时候,客户考虑到当时公司用户数量处于激增的阶段,业务也在不断进行更改,所以需要对表结构也进行更改来满足业务的需求。于是便决定使用Google Cloud Spanner来保证数据的ACID(原子性、一致性、隔离性和持久性)的前提下仍然可以对数据库进行水平拓展和分布式操作。

选择Cloud Spanner

和主流的云服务关系数据库相比,例如AWS的Aurora、GCP的Cloud SQL和Azure的SQLDB,这些数据库并没有实现在多节点上进行扩展的功能,只能在单个节点上进行垂直扩容(增加RAM或CPU数量)。

如果想要实现水平扩容,可以使用NoSQL数据库,例如HBaseMongoDB、DynamoDB或BigTable。但是这些数据库很难做到事务的特性,并且不能支持关系型数据库所支持的功能,例如连表等。并且因为NoSQL的查询语句和关系型数据库的语句区别很大,会导致应用中大量的查询语句和表结构需要重写。

而Cloud Spanner区别于这些数据库服务,是一种独特的数据库。它将事务,SQL查询和关系结构与NoSQL数据库的可伸缩性相结合。因此Cloud Spanner同时具备SQL和NoSQL数据库结构的优点。在最初的时候,Cloud Spanner是被设计为NoSQL的键值对的方式存储,但随着其对关系模型的需求被添加后,Cloud Spanner逐渐打破了NoSQL和SQL数据库之间的壁垒。

特性

作为分布式数据库

每一个Spanner的实例都是在不同数量的节点上运行的,每一个节点都是由Google云平台服务去自动管理的。因此,Cloud Spanner拥有很高的可扩展性,并且可根据请求负载和数据的大小进行自动分片(splits),为系统提供了更多的弹性空间。

作为关系型数据库

Cloud Spanner支持关系型数据库所有的功能,但Cloud Spanner不完全是关系型数据库,尽管Spanner的数据模型与任何其他关系数据库的数据模型基本相似,有预定义的数据元组,可以存储在关系(表)中并进行查询,但它缺乏约束。

Cloud Spanner拥有主键概念,并且必须为每个表定义主键,而且该主键是强制唯一性的。然而它没有foreign key的概念,取而代之的是interleave。在关系型数据库中,我们期望数据的强完整性,以确保能满足预定义的约束。Cloud Spanner在该方面的能力有所限制。

事务支持(ACID)

Cloud Spanner在事务上提供了最严格的并发控制,实现全球事务对外强一致性。在外部一致性的保证下,即使Cloud Spanner的实例位于多个数据中心上运行,事务也能在高性能和高可用性的前提下按顺序执行。Cloud Spanner能够实现外部一致性得益于TrueTime的功能特性。TureTime是Google为所有Google服务提供的高可用分布式的时钟。该时钟为应用提供单调递增的时间戳。Cloud Spanner 使用 TrueTime 的这一特性为事务分配时间戳。具体而言,每个事务都分配有一个时间戳,它为Cloud Spanner提供事务发生的时间。

其他特性

Cloud Spanner还有很多其他的特性,包括单区域和多区域配置、多语言支持等。

数据结构

Cloud Spanner和传统RDBMS的数据模型基本一致,都是由行、列和值组成,并且含有主键。Cloud Spanner中的数据是强类型,每个表需要定义一个架构,并且每一列的数据都需要制定数据类型。

其中,主键(PRIMARY KEY)被定义在表架构外。

数据的分布是通过主键实现的,因此在选择主键的时候需要尽量防止Cloud Spanner服务的热点(Hotspots),时间戳或者自增的序列数字都会造成热点问题出现,Cloud Spanner推荐使用随机(用户名等)的信息或者UUIDs作为主键。

交错表(Interleaved tables)

在Cloud Spanner中,是没有办法去定义两表之间外键(FOREIGN KEY)关系的。但是Cloud Spanner引入了一个类似的概念--交错表。

以上架构中表示为customers表创建accounts子表或“交错”表。其中需要注意的事项:

  • customer_id是子表accounts的主键之一,也是父表的customers的主键。在accounts声明为customers子表时,该主键是必须添加的,并且要保证命名、类型、限制等都必须一致。
  • 当插入子表时需要确保父表有对应的行(即以相同父表主键开头的行)。
  • 删除父表行需要满足其中两点之一:
    • 在子表中没有对应的行。
    • 声明ON DELETE CASCADE
  • ON DELETE CASCADE 声明表示,当父表中的某一行被删除时,子表中对应的行也会被自动删除。如果没有该声明,或声明为ON DELETE NO ACTION,则必须先删除子行,才能删除父行。
  • 交错行首先按父表的行进行排序,然后在父表共享主键的基础上,对子表进行再排序。
  • 在对数据库进行分片操作的时候,只要父表行以及子表行的大小在8GB以内,并且在子表行中没有热点,则每个父表以及子表的数据的存放区域关系会一同保留下来。

交错表的主要目的是为了加快某些查询操作,尤其是包含JOIN的操作。因为交错表直接改变了数据在云上的布局方式,确保在执行JOIN操作的时候不会访问集群的每个节点(Nodes)。

二级索引(Secondary indexes)

在Cloud Spanner中,主键会被自动设置为表的索引,Cloud Spanner也同时支持将其他非主键字段设置为二级索引。

其中UNIQUE INDEX关键字表示,该索引会强制该字段在插入时需要不重复。并且在极少情况下,Cloud Spanner可能会自动选择让查询延迟增加的索引,此时可以使用FORCE_INDEX关键字提供指定索引进行查询操作。

数据库分片(split)

在表之间,Cloud Spanner支持最多7层的父子关系,也就是可以将7个逻辑独立的表的行物理地存储在一起。当相关表数据不断增长,达到单个Cloud Spanner服务器的资源限制时,作为分布式数据库的Cloud Spanner会将数据划分为各个“split”区块,每个分片都可以被独立移动并分配给不同物理位置的多个服务器

分片包含一系列连续的行,这些行的开始和结束键称为“分片边界”(split boundaries)。Cloud Spanner 会根据大小和/或负载自动添加和移除分片边界,这样做会改变数据库中的分片数量。

基于负载进行分片

当数据库中的一个表上的10行数据的读取频率高于表中所有其他的行,Cloud Spanner就会为这10行中的每一行添加分片边界,以便于每一行是由不同的服务器处理,以此来避免这10行数据的读写操作只消耗单台服务器的资源(避免热点)。

表结构的更新

Cloud spanner支持对现有的数据库架构执行以下更新操作:

  • 新建表。新表格中的列可以为 NOT NULL。
  • 删除一个表,前提是该表内没有交错其他表,并且没有二级索引。
  • 将一个非主键列添加到任何表,新的非主键列不能为 NOT NULL。
  • 将 NOT NULL 添加到非主键列,不包括 ARRAY 列。
  • 从非主键列中移除 NOT NULL。
  • 从任何表中删除非主键列,前提是二级索引未在使用该列。
  • 将 STRING 列更改为 BYTES 列,或将 BYTES 列更改为 STRING 列。
  • 增加或减少 STRING 或 BYTES 类型的长度限制,前提是它不是由一个或多个子表继承的主键列。
  • 在值和主键列中启用或停用提交时间戳。
  • 添加或移除任何二级索引。

未来的趋势

基于Cloud Spanner独特的结构,它能确保客户在以较小的用户群和业务量为起点时,不必过多担心在未来数据量和业务量增长后需要对数据库进行迁移或重新编写的问题。Cloud Spanner在保证关系型数据库管理系统的特性前提下,同时提供数据库的超强延展性,并且可以在特定情况下对已存在的表的表结构进行结构更新。

因此,无论应用程序规模如何,Cloud Spanner都会是不错的选择,它能为应用提供包括事务支持、高可用性保证、只读副本以及轻松可伸缩性。

在《Google Cloud Spanner经济性分析》的文章中介绍到,Cloud Spanner的总花费比本地数据库服务花费低78%,比其他云平台数据库服务价格低37%。这得益于Cloud Spanner不需要用户为额外副本服务支出费用,就能确保数据库的高可用性。并且因为Cloud Spanner支持用户在不停机的情况下对数据库进行水平或垂直的缩放(由Cloud Spanner自动管理数据切片和数据复制)或对表结构进行更新例如添加索引等操作。

同时说明Cloud Spanner在使用经济上也提供了比自己维护的数据库服务更低的成本。

参考

  1. 外部一致性:https://cloud.google.com/spanner/docs/true-time-external-consistency#external_consistency
  2. Cloud Spanner所有特性:https://cloud.google.com/spanner#section-8
  3. Cloud Spanner数据类型:https://cloud.google.com/spanner/docs/data-types
  4. 提交时间戳:https://cloud.google.com/spanner/docs/commit-timestamp

本文版权属Thoughtworks公司所有,如需转载请在后台留言联系。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-07-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 ThoughtWorks洞见 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Google去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感
之前看过 《大规模分布式存储系统:原理解析与架构实战》 ,这个系统设计还是挺有意思的,里面提及了Google的一整套系统都有论文,而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了,这段时间就陆陆续续的看完了这三篇Paper,可怜我的渣渣英语,所以看得比较慢。
owent
2023/03/17
1.9K0
Google去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感
【译】如何通过 Google Spanner 实现万亿级数据存储与5个九的高可用性
原始链接 https://blog.bytebytego.com/p/how-google-spanner-powers-trillions[1] 作者 ByteByteGo[2]
萝卜要努力
2025/03/07
1290
【译】如何通过 Google Spanner 实现万亿级数据存储与5个九的高可用性
分析 Google Cloud Spanner 的架构
在2005、2006年期间,谷歌内部大规模使用了 MySQL 数据库。其中Google Adwords (谷歌广告部门)使用了 90 多个 MySQL Shards(分片)集群方案存储数据,是谷歌内部使用 MySQL 数据库的最大的部门之一。由于系统维护的原因,谷歌广告部门重新规划了 MySQL 集群,整个过程花了 2 年时间。因为谷歌知道它们的数据增长的非常快,再使用 MySQL 这类数据库到未来的某个时刻会非常痛苦。这就是 Spanner 的诞生原因。
哒呵呵
2020/02/19
3.7K0
分析 Google Cloud Spanner 的架构
Google Spanner原理:地球上最大的单一数据库
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级,
大数据文摘
2018/05/21
12.4K0
探索云原生分布式 Data Warebase
2002 年我加入 Microsoft SQL Server 引擎团队。那时的数据库市场相对简单,主要有三个厂商:Oracle、IBM(DB2)和 Microsoft(SQL Server)。数据库行业似乎已经相当成熟,发展趋于稳定,新的产品 / 厂家看起来不再有机会。我曾一度思考过继续做数据库是不是一个正确的职业选择。与数据库行业的成熟稳定相比,互联网业务蓬勃发展,对数据库能力和性能的要求与日俱增,一场解决水平扩展的战争悄然开始。
ProtonBase
2024/03/05
5040
海量数据业务有哪些优化手段?
互联网时代,亿级用户各种网络行为产生大量数据,如何解决海量数据存储?如何高性能读写?解决思路有哪些,本文列举了常用的解决方案:
微观技术
2021/04/19
1.6K0
海量数据业务有哪些优化手段?
新数仓系列:HBase关键能力和特性梳理
最近看一本书,铃木敏文的《零售的哲学》,里面提到一个很有意思的观点,711核心使命是提供便利,围绕便利场景,提供一系列食品、ATM服务等,而不是和超市去PK货物品种。 联想到常见的NOSQL数据库和传统关系型数据的区别也有点类似;传统关系型数据库发展了几十年,就像超市一样,功能非常多,非常完善,也是进入到各个行业中去。NOSQL从一出生就是带着解决关系数据中的某些场景的不突出/不擅长的使命。 另外一些新数据库又思考着突破NoSQL的场景的限制,想着同时解决OTLP/OLAP,也有诞生了NewSQL或者HTA
大数据和云计算技术
2018/03/08
1.1K0
大数据技术之HBase的入门简介
要想明白为什么产生 HBase,就需要先了解一下 Hadoop 存在的限制?Hadoop 可以通过 HDFS 来存储结构化、半结构甚至非结构化的数据,它是传统数据库的补充,是海量数据存储的最佳方法,它针对大文件的存储,批量访问和流式访问都做了优化,同时也通过多副本解决了容灾问题。
张哥编程
2024/12/13
1630
大数据技术之HBase的入门简介
浅析Hbase
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
week
2019/12/11
5110
SQL or NoSQL?
关注「前端向后」微信公众号,你将收获一系列「用心原创」的高质量技术文章,主题包括但不限于前端、Node.js以及服务端技术
ayqy贾杰
2020/03/26
1.4K0
SQL or NoSQL?
开源NewSQL – CockroachDB在百度内部的应用与实践
内容来源:2017 年 11 月 18 日,百度数据库架构师严龙在“第七届数据技术嘉年华”进行《百度NewSQL-CockroachDB》演讲分享。IT 大咖说(微信id:itdakashuo)作为独家视频合作方,经主办方、演讲者以及微信公众号——CockroachDB(微信id:CockroachDB)审阅授权发布。 阅读字数:3621 | 10分钟阅读 摘要 本次交流主要包括开源 NewSQL 数据库 Cockroach DB 关键技术分析以及 Cockroach DB 在百度内部的应用和实践。 嘉宾
IT大咖说
2018/06/04
2.1K0
谷歌的 Spanner 数据库是如何一步步支持 SQL 语法的
Spanner 之前是一个键值数据库,与现在谈论的 Spanner 是完全不同的东西。在设计之初,Spanner 就支持事务、外部一致性和透明的故障转移。到后面,Spanner 开始支持带类型的数据库表结构和其它的一些关系型数据库功能,以及支持了 SQL 功能。而现在我们正在努力改进 SQL 语法的兼容性和关系型数据库功能。
哒呵呵
2020/08/05
1.3K0
谷歌的 Spanner 数据库是如何一步步支持 SQL 语法的
硬核干货 | 轻松驾驭EB级千万QPS集群,TDSQL元数据管控与集群调度的演进之路
日前,TDSQL新敏态引擎正式发布,支持无限扩展、在线变更,可以完美解决对于敏态业务发展过程中业务形态、业务量的不可预知性,高度适配金融敏态业务。 该引擎100%兼容MySQL,计算/存储资源均可独立全透明弹性扩缩容,实现了PB级存储的Online DDL;计算层每个节点均可读写,轻松支撑千万级QPS流量,可以有效应对业务的变化。针对海量数据存储的场景,实现最高20倍压缩率的超高压缩比存储能力,大幅节省资源成本。其独有的数据形态自动感知特性,使数据能根据业务负载情况实现自动迁移,打散热点,降低分布式事务
腾讯云数据库 TencentDB
2021/12/27
8030
HBase简介
要想明白为什么产生 HBase,就需要先了解一下 Hadoop 存在的限制?Hadoop 可以通过 HDFS 来存储结构化、半结构甚至非结构化的数据,它是传统数据库的补充,是海量数据存储的最佳方法,它针对大文件的存储,批量访问和流式访问都做了优化,同时也通过多副本解决了容灾问题。
每天进步一点点
2022/07/27
7840
HBase简介
Sql Or NoSql,看完这一篇你就懂了
你是否在为系统的数据库来一波大流量就几乎打满CPU,日常CPU居高不下烦恼?你是否在各种NoSql间纠结不定,到底该选用那种最好?今天的你就是昨天的我,这也是写这篇文章的初衷。
Java_老男孩
2019/08/28
7340
后Hadoop时代的大数据架构
提到大数据分析平台,不得不说Hadoop系统,Hadoop到现在也超过10年的历史了,很多东西发生了变化,版本也从0.x进化到目前的2.6版本。我把2012年后定义成后Hadoop平台时代,这不是说不用Hadoop,而是像NoSQL (Not Only SQL)那样,有其他的选型补充。 背景篇 Hadoop: 开源的数据分析平台,解决了大数据(大到一台计算机无法进行存储,一台计算机无法在要求的时间内进行处理)的可靠存储和处理。适合处理非结构化数据,包括HDFS,MapReduce基本组件。 HDFS:提供
腾讯大数据
2018/01/26
1.8K0
PingCAP刘奇:如何构建一个NewSQL数据库
大家好,我是PingCAP CEO刘奇。今天我将和大家分享一下如何构建一个NewSQL数据库。 首先,来介绍下我自己。和你们当中很多人一样,我是一名开源Hacker,一名架构工程师,并长期致力于创建新一代数据库。我曾投身于以下几个开源项目的工作,包括TiKV、TiDB 和Codis,这些项目都已在Github上发布。今天,我的演讲将涉及下列话题: 简要介绍NewSQL; 如何建立一个NewSQL数据库; 以及roadmap。 ▌为什么我们需要一个新的数据库? 在正式开始前,我先问一个
CSDN技术头条
2018/02/12
1.4K0
PingCAP刘奇:如何构建一个NewSQL数据库
带你遨游银河系的 10 种分布式数据库
关系型数据库指的是使用关系模型(二维表格模型)来组织数据的数据库,由二维表及其之间的联系所组成的一个数据组织。
Bug开发工程师
2021/07/01
3.1K0
带你遨游银河系的 10 种分布式数据库
后Hadoop时代的大数据架构
感谢董飞先生投稿,推荐关注其知乎专栏 【董老师在硅谷 http://zhuanlan.zhihu.com/#/donglaoshi】 提到大数据分析平台,不得不说Hadoop系统,Hadoop到现在也超过10年的历史了,很多东西发生了变化,版本也从0.x进化到目前的2.6版本。我把2012年后定义成后Hadoop平台时代,这不是说不用Hadoop,而是像NoSQL (Not Only SQL)那样,有其他的选型补充。我在知乎上也写过Hadoop的一些入门文章 如何学习Hadoop - 董飞的回答,为了给大家
大数据文摘
2018/05/22
9400
【聚焦】后Hadoop时代的大数据架构
提到大数据分析平台,不得不说Hadoop系统,Hadoop到现在也超过10年的历史了,很多东西发生了变化,版本也从0.x进化到目前的2.6版本。我把2012年后定义成后Hadoop平台时代,这不是说不用Hadoop,而是像NoSQL (Not Only SQL)那样,有其他的选型补充。我在知乎上也写过Hadoop的一些入门文章 如何学习Hadoop - 董飞的回答,为了给大家有个铺垫,简单讲一些相关开源组件。 背景篇 Hadoop: 开源的数据分析平台,解决了大数据(大到一台计算机无法进行存储,一台计算机无
小莹莹
2018/04/23
9790
【聚焦】后Hadoop时代的大数据架构
相关推荐
Google去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感
更多 >
LV.0
这个人很懒,什么都没有留下~
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档