从DynamoDB到Cloud Spanner

从使用 RDBMS 到采纳 NoSQL 的转变的背后，蕴藏着一种创新的权衡：放弃 RDBMS 之擅长，取而代之以 NoSQL 之创新；然而，太阳底下无新事。这种创新解决问题的同时也带来新的挑战。并且，这种创新的权衡似乎也在不停地找寻下一个平衡点或突破口。

例如，MySQL 数据库由于稳健的核心功能受到广泛的使用，但通常来说 MySQL 的单表的记录超过 5000 万行的时会出现性能上的瓶颈，这种情况下过去就有两种应对办法：“拆库拆表”；或者使用 NoSQL。其中，选用 NoSQl 的“童鞋”有选择文档型，也有选择键值型、宽列型等，这些 NoSQL 很好地解决了性能的横向扩展能力，但是又带来了一些新的问题。

最近刚好和一些朋友有聊到这些事情。这些朋友正在使用 DynamoDB 或者 Cassandra 数据库，如是就有了一些很有意思的讨论。

NoSQL 数据库基于内置的分片技术能够达到数据库的横向扩展，分片可以是基于范围的、哈希的、或者基于标签的等等。DynamoDB 和 Cassandra 有点像同门师兄弟，大概属于华山派的剑宗、气宗，他们使用和仅使用了基于哈希的分片，有一个学名叫做“Consistent Hash Sharding”，好处是片键的选择相对容易了，数据尽可能打散了，写入性能不错；但明眼人可能一下就会发现一个问题：基于哈希的分片是只能支持匹配查询的，不能够支持范围查询。没有了范围查询，可能很多业务上的需求满足起来就很费劲了。举个栗子，游戏的玩家信息存放在 DynamoDB 之中，其中包括玩家的年龄等；如果想查找出某个年龄段的玩家的信息都会很麻烦，很多时候干脆就把数据导出一份到其他数据库来做了。

NoSQL 数据库会使用到副本集、分布式一致性协议来实现数据的高可用性和故障的自动切换等。由于有多个副本，读取数据的时候有可能是从副本中读取的，再加上表和对应的索引之间可能的数据差距，会出现无法保证 RDBMS 中起码的“Read after Write”。这种情况下会对业务上的某些需求造成不小的实现难度。举个栗子，游戏玩家在战斗期间获得的点数这个场景是需要强一致性读的。

NoSQL 数据库对事务的支持始终会是一个挑战；通常来说 NoSQL 数据库支持单行的事务能够一定程度满足业务的需要，但是如果需要支持稍微复杂一些的事务，就需要在应用代码部分来实现。举个栗子，DynamoDB 中保存了玩家的游戏充值的点数，在充值或使用游戏充值会增加或减少点数，如何保证当前只有一个回话在操作某一个玩家的点数时，就需要在应用代码部分增加行的版本或时间戳的信息，在最后修改点数时候检查版本或时间戳信息，确保没有其他回话在修改同一玩家的点数。这样子做起来还是有一些繁琐，性能也容易出现问题。

当讨论到上面这些的话题时，接下来问题来啦，有没有什么更好的创新来解决上面的问题？也就是需要一个既支撑性能横向扩展，又兼顾对“强读”和事务的支持的数据库的服务。

Cloud Spanner 正是这样一种技术创新。它是如何解决上面的问题呢？Cloud Spanner 大概类似于天龙八部里面的“小无相功”，不着形相，既可以是 RDBMS，又可以是 NoSQL；为什么呢？首先，Cloud Spanner 实现了存储和计算资源的分离，这使得其更容易去融合 RDBMS 和 NoSQL 的特点，例如，计算上融合 RDBMS 的 SQL、事务等，存储上融合 NoSQL 的横向扩展能力；其次，Cloud Spanner 是云原生数据库，这就意味着它不仅仅是一个数据库软件，它是一个集成了计算、存储、网络、安全、前端、管理控制等为一体的数据库云服务，这使得其更容易地达到特性的工程实现和整合。这也正是云原生数据库的魅力所在！

补充说明 Cloud Spanner 的性能的横向扩展能力，每一个节点能够支撑 10,000 QPS reads 或 2,000 QPS writes，并且随着节点的增加实现性能的线性增长。

聊到这里，下一个问题可能是如何实现数据库迁移；下面以从 DynamoDB 迁移到 Cloud Spanner 为例。

数据库迁移概览

下面对于主要的数据库迁移的环节做更多的说明和描述。

模式转换

从简单的数据类型转换到复杂的数据类型，从 NoSQL 的反范式模型转换到 RDBMS 的通用的范式建模是一个从 Low Level 到 High Level 的模式转换，通常是非常容易的过程。

数据迁移

从 DynamoDB 到 Cloud Spanner 的数据迁移，主要分为初始复制和增量同步两个阶段，请参考下面的数据迁移的示意图。

应用改造

应用改造主要涉及到数据库访问层的改造。通常来说 DynamoDB 主要提供 Low Level 的 Read & Write 的 APIs，而 Cloud Spanner 提供了丰富的 Read & Write 的 APIs 以及事务管理；这使得基于 Cloud Spanner 实现相同的数据操作的业务逻辑时应用代码更为高效简洁。

演示

请观看数据迁移的演示：

总结

一些客户正在进行从 DynamoDB 或者 Cassandra 到 Cloud Spanner 的数据迁移，这些客户中的很多名字都是耳熟能详。历史有无数个选择，而选择在每个人手中。Cloud Spanner 作为云原生数据库愿意更好地帮助你们解开束缚和推动创新。