http://suo.im/61qgLg 作者:陈峻
数据库体系结构发展的下一步是分布式SQL。在这里看看一些特征。
随着各个组织先后将其业务转向云端环境时,他们很快地意识到:在一些最关键的应用背后,那些旧式的关系型数据库不但限制了迁移的速度,而且根本无法有效地实现灵活的业务扩展。许多企业既希望保持诸如Oracle、SQL Server、Postgres和MySQL之类关系型数据库的可靠性,又能够享受到云服务所带来的规模效应、以及全局稳定性等“红利”。
为了满足此类需求,人们开始转向使用NoSQL数据库。但是由于NoSQL并非完全为提供真正的一致性而设计的,因此它无法作为事务型数据库而使用。当然,最近有一些NoSQL解决方案声称能够提供“ACID事务”。不过,它们无法提供诸如:财务分帐、库存控制、以及身份管理等关键任务所需的隔离级别。
2012年,Google发表了一篇有关Spanner的论文。文中介绍了一种全新的基于分布式系统的,且可以全球性扩展的分布数据库。总的说来,Google Cloud Spanner是一种可扩展的、多版本的、同步复制(synchronously-replicated)型数据库。它是第一个能够在全球范围内分发数据,并支持外部一致性(externally-consistent)的分布式事务的系统。
下面我们此基础上,一起来具体讨论此类分布式SQL的基本相关概念,特别是如何实现可扩展性和一致性的。通常,为了能够在分布式环境中真正具有可扩展性,分布式SQL数据库具有如下七种核心特征:
正如我们无需繁重的准备就能够实现扩展式计算那样,分布式SQL数据库能够在不增加操作复杂性的情况下,适应云端环境的无缝扩展。也就是说,它具有在多个分布式参与者之间均匀分布数据的能力。
分布式SQL数据库必须在分布式环境中提供高度的隔离性。云端环境往往是由各种分布式系统和微服务所组成,而不同的调用和操作可能会指向同一块数据,因此我们很难保证事务一致性。分布式SQL数据库除了能够调节资源的争用,还能够提供与单实例数据库相同的事务隔离级别。
分布式SQL数据库能够在无需任何外部工具的条件下,提供最高级别的弹性。凭借着云服务为我们的业务所提供持续在线环境,分布式数据库可以将故障恢复的用时减到最少,并且无需任何外部配置,即可自动化地复制数据。
由于云服务能够以一种可接受的服务水平,将用户的业务触达全球的各个角落,因此分布式SQL数据库也能够据此突破地域的限制。在复杂、广泛、分散的地理环境中,它能够进行分布处理和数据存储,以满足各地用户的业务需求。
众所周知,SQL是数据库所使用的结构化语言,也是所有应用逻辑的默认语言。凭借着其通用性,我们不必重新培训开发人员,即可熟练地对接和调用数据库资源。除了上面提到的Spanner,诸如Amazon Aurora、Yugabyte、FaunaDB和CockroachDB等都能够支持SQL。
在分布式系统中,由于数据被分散到了各个地区的数据中心,因此应用架构师往往需要了解每个站点的位置,在程序逻辑上找到最近的位置,以便将需要调用的存储数据绑定为应用的一部分。那么,分布式SQL可以在其数据表中,基于某些字段对数据进行地理分区,进而让数据更接近用户侧。这就是所谓的数据库的数据主权(data sovereignty)问题。据此,开发人员可以确保用户对其信息的低延迟访问,从而最大程度地减少数据在云端传输的费用和流量的开销。
分布式SQL数据库的一个独特特征是:半自治单元(semi-autonomous units),它们可以参与到较大的系统中。也就是说,每个单元都能够自行部署,然后加入到CockroachDB集群之类更大的系统中。通过该特征,分布式SQL数据库可以更好地扩展到真正的多云环境中,而不仅仅依赖于单个网络,来完成数据的分发。在此模式下,参与者(participant)的云服务类别将不再受到限制,它们可以位于任何地方,任何一种公共云、私有云、甚至是单个的本地(on-premise)实例。显然,这对于我们在分布式混合与多云环境中的各类应用来说,都是至关重要。
上述七项特征可谓分布式SQL在云端环境中所独有的。但是,说到底它仍然是一种数据库,因此也应当具备数据库的如下基本功能:
当然,上述所谓“基本”功能要求,其实并不简单,它们旨在提供更加成熟的、针对企业级应用的数据库。
作为一种新兴的类别和演变的方向,分布式SQL数据库还需要在数据一致性和本地化等方面,进一步配合云端环境来不断改进。毕竟,在严苛的生产环境中,此类数据库会碰到更多有关性能和效率等方面的实际问题。
前文提到的CockroachDB,是一种云原生的分布式SQL数据库。它可以帮助各种企业级应用,将最基本的工作负载和一些关键性的任务迁移到云端,并实现了对于各种高级云端原生环境的策略编排。您可以作为了解分布式SQL的一个切入口进行试用。