Google Cloud Platform 提倡在数据存储中使用强一致性

  • Thomas Betts
  • 盖磊

2018 年 2 月 7 日

话题:数据库语言 & 开发架构AI

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

在创建应用平台中,为降低复杂性并减少潜在的软件缺陷,一开始就应以实现数据层中的强一致性为基础。这一前提是 Mike Curtiss 最近在 Google Cloud Platform 博客上发表的一篇博文中提出的。按 Curtiss 的论述:“换句话说,将数据集整体置于缺省提供事务和一致性的数据存储中,会导致错误更少、麻烦更小,并且应用代码也更易于维护。”

在大量的系统中,必须要处理并发数据访问。任何工作于其中的开发人员,对 Curtiss 所描述的场景都不会陌生。两个银行账户之间转账,就是一个需要外部一致性的教科书式范例。但是,如果要在应用逻辑中解决这种一致性,可能会导致错误、额外的复杂性,以及其它一些意想不到的复杂性。相比较而言,如果使用了缺省提供外部一致性的数据存储,那么就可以简化应用逻辑。这将使系统更强大,并提高了开发团队的生产力。

Google Cloud Spanner 就是一种以构建强一致性为基础功能的的关系数据库服务。在 Spanner 中,组合了水平可扩展性和强一致性。这引发了一种看法,认为 Spanner违反了 CAP 定理

在博客文章中,很好地比较了各种数据存储所使用的一致性级别。Curtiss 也尝试去挑战一些常见假设,例如是否外部一致性会对性能产生不合理的严重影响。但是,鉴于 Spanner 全面提供强一致性读,避免了开发人员碰上使用其它大多数数据存储中习以为常的一些限制。

虽然这篇博文意在推销 Spanner 的能力,但文中也提供了一些通用的使用指导。首先,应尽可能使用强一致性读。在强一致性读操作不可用的情况下,只要确认妥协(compromises),可以退而求其次使用有限过期(Bounded staleness)一致性读。按理说,强一致性写要比强一致性读更重要。如果系统没有提供强一致性写,那么应用开发人员会承受额外的负担,并且可能会引入数据不一致。

此外,Google Clound Platform 为Cloud Spanner外部一致性提供了更多信息。

查看英文原文: Google Cloud Platform Recommends Strong Consistency in Data Stores

数据库语言 & 开发架构AI