google 用什么数据库-google earth 数据

Cloud Spanner 是 Google Megastore 系统的继任者，Spanner 展示了远超其前辈的能力。 Spanner 最早出现在谷歌内部数据中心，直到 2017 年才发布了 beta 版本并增加了 SQL 能力。 现已上线谷歌云平台，在各行业拥有大量用户。 Cloud Spanner 数据库是一个全球分布的关系型/事务型数据库，Google 承诺 Cloud Spanner 具有高吞吐量、低延迟和 99.999% 的高可用性。

联系 Cloud Spanner

第一次接触Google Cloud Spanner是因为客户对新技术的追求和实验，我们把我们基本完成的API从原来的Google Cloud Sql迁移到了Cloud Spanner数据库。 客户在做这个决定时，考虑到公司的用户量正处于快速增长阶段，业务不断变化，需要改变表结构来适应业务的需要。 所以我决定使用Google Cloud Spanner来保证数据的ACID（原子性、一致性、隔离性和持久性），数据库仍然可以水平扩展和分布式。

选择 Cloud Spanner

与主流云服务关系型数据库，如AWS的Aurora、GCP的Cloud SQL、Azure的SQLDB等相比，这些数据库不具备多节点扩展能力，只能在单节点垂直扩展（增加RAM或数量）中央处理器）。

如果要实现水平扩展，可以使用NoSQL数据库，如HBase、MongoDB、DynamoDB或BigTable。 但是这些数据库很难实现事务的特性，不能支持关系数据库所支持的功能，比如连接表。 并且由于NoSQL查询语句与关系数据库语句有很大的不同，应用中的大量查询语句和表结构将需要重写。

与这些数据库服务不同，Cloud Spanner 是一个独特的数据库。 它将事务、SQL 查询和关系结构与 NoSQL 数据库的可扩展性相结合。 因此，Cloud Spanner 兼具 SQL 和 NoSQL 数据库结构的优点。 Cloud Spanner一开始是为存储NoSQL键值对而设计的，但随着它对关系模型需求的加入，Cloud Spanner逐渐打破了NoSQL和SQL数据库之间的壁垒。

特征

作为分布式数据库

每个 Spanner 实例都运行在不同数量的节点上，每个节点都由 Google Cloud Platform 服务自动管理。 因此，Cloud Spanner 具有很高的可扩展性，可以根据请求负载和数据大小自动拆分（split），为系统提供更多的弹性空间。

关系型数据库

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

Cloud Spanner有主键的概念，必须为每个表定义一个主键google 用什么数据库，并且主键必须是唯一的。 但是，它没有外键的概念，而是交错的。 在关系数据库中，我们期望强大的数据完整性来确保满足预定义的约束。 Cloud Spanner 在这方面的能力有限。

事务支持 (ACID)

Cloud Spanner对事务提供最严格的并发控制，实现全局事务的外部强一致性。 在外部一致性的保证下，即使 Cloud Spanner 实例运行在多个数据中心，也可以在高性能和高可用的前提下顺序执行事务。 借助 TrueTime 的特性，Cloud Spanner 可以实现外部一致性。 TrueTime 是谷歌为所有谷歌服务提供的高可用分布式时钟。 该时钟为应用程序提供单调递增的时间戳。 Cloud Spanner 使用 TrueTime 的这个特性来为事务分配时间戳。 具体来说，每个事务都分配有一个时间戳，它为 Cloud Spanner 提供事务发生的时间。 [1]

其他特性

Cloud Spanner 还有许多其他特性google 用什么数据库，包括单区域和多区域配置、多语言支持等。 [2]

数据结构

Cloud Spanner 的数据模型与传统的 RDBMS 基本相同。 两者都由行、列和值组成，并包含主键。 Cloud Spanner 中的数据是强类型的，每张表都需要定义一个schema，每一列的数据都需要指定一个数据类型[3]。

CREATE TABLE customers(
    customer_id   INT64  NOT NULL,
    first_name    STRING(16),
    last_name     STRING(16)
)PRIMARY KEY (customer_id)

其中，主键（PRIMARY KEY）定义在表模式之外。

数据的分布是通过主键实现的。 因此，在选择主键时，需要尽可能避免Cloud Spanner服务的热点（Hotspots）。 时间戳或自增序列号会导致热点。 Cloud Spanner 建议使用随机（用户名等）信息或 UUID 作为主键。

交错表

在 Cloud Spanner 中，无法定义两个表之间的外键（FOREIGN KEY）关系。 但是 Cloud Spanner 引入了一个类似的概念——交错表。

CREATE TABLE accounts(
    customer_id     INT64  NOT NULL,
    account_id      INT64  NOT NULL,
    created_at      TIMESTAMP NOT NULL
)PRIMARY KEY (customer_id, account_id),
INTERLEAVE IN PARENT customers ON DELETE CASCADE;

上面的模式表示为客户表创建帐户子表或“交错”表。 注意事项：

交错表的主要目的是加快某些查询操作的速度，尤其是涉及 JOIN 的查询操作。 因为交错表直接改变了数据在云端的布局方式，保证了在执行JOIN操作时不会访问到集群的每个节点（Nodes）。

二级指标

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

CREATE UNIQUE INDEX customer_index_name ON customers(first_name);

UNIQUE INDEX 关键字表示索引将强制字段在插入时是唯一的。 在极少数情况下，Cloud Spanner 可能会自动选择增加查询延迟的索引。 在这种情况下，您可以使用 FORCE_INDEX 关键字为查询操作提供指定的索引。

SELECT * FROM customers@{FORCE_INDEX=customer_index_name}

数据库碎片（split）

在表之间，Cloud Spanner 最多支持七级父子关系，即可以将七个逻辑上独立的表的行物理存储在一起。 当相关表数据不断增长，达到单个Cloud Spanner服务器的资源极限时，Cloud Spanner作为分布式数据库，将数据划分为“拆分”块，每个块可以独立移动，分配到不同的物理多个服务器在不同的位置。

拆分由一系列具有开始和结束键的连续行组成，称为“拆分边界”。 Cloud Spanner 会根据大小和/或负载自动添加和删除分片边界，这样做会改变数据库中分片的数量。

基于负载分片

当数据库中某个表的 10 行数据比表中所有其他行的读取频率更高时，Cloud Spanner 将为这 10 行中的每一行添加分片边界，以便每一行由不同的服务器读取。 处理，以免这10行数据的读写操作只消耗单台服务器的资源（避免热点）。

更新表结构

Cloud Spanner 支持对现有数据库模式进行以下更新操作：

未来的趋势

基于Cloud Spanner独特的结构，可以保证客户从小用户群和业务量起步时，不必过分担心未来数据量和业务量增加后需要迁移或重写数据库. Cloud Spanner在保证关系型数据库管理系统特性的前提下，还提供了数据库的超强扩展性，可以在一定情况下更新已有表的结构。

因此，无论应用程序的大小，Cloud Spanner 都会是一个不错的选择，它可以为应用程序提供包括事务支持、高可用性保证、只读副本和易于扩展的功能。

根据《Google Cloud Spanner 经济分析》一文，Cloud Spanner 的总成本比本地数据库服务低 78%，比其他云平台数据库服务低 37%。 这是因为 Cloud Spanner 确保了数据库的高可用性，而不需要用户为额外的复制服务付费。 并且由于 Cloud Spanner 支持用户在不停机的情况下水平或垂直扩展数据库（Cloud Spanner 自动管理数据切片和数据复制）或更新表结构，例如添加索引。

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

参考外部一致性：#external_consistencyCloud Spanner 所有功能：#section-8Cloud Spanner 数据类型：提交时间戳：

文/Thoughtworks 刘金玉