深入探讨数据库可扩展性的三大维度,分析横向扩展在存在数据竞争场景下的性能瓶颈,以及Spacetime如何通过创新架构实现真正的水平扩展。
在选择数据库系统时,开发者们最常问的问题之一就是:这个系统能否扩展?这个问题看似简单,但实际上涉及数据库架构中最复杂也最容易被误解的领域。许多人将横向扩展能力视为评估数据库系统的核心指标,却忽略了扩展性本身是一个多维度的概念,而且并非所有工作负载都能够从横向扩展中受益。本文将深入分析数据库可扩展性的本质,探讨横向扩展在OLTP场景下面临的真实挑战,并展示一种创新的解决思路。 首先需要澄清的是,可扩展性并非一个单一的属性,而是由多个相互独立的维度构成。计算能力、存储容量和网络带宽构成了数据库可扩展性的三大基础维度。计算能力决定了系统每秒能够处理的事务数量,存储容量决定了系统能够持久化的数据规模,而网络带宽则决定了系统能够同时支持的连接数和传输吞吐量。
这三个维度在技术上可以独立扩展,但在实际应用中,它们往往相互影响,构成了复杂的性能调优问题。 传统观点认为,横向扩展意味着通过增加机器数量来提升系统整体性能。这种理解在某些场景下是正确的,但在OLTP数据库领域,事情远比想象中复杂。要理解这一点,我们需要首先区分垂直扩展和水平扩展的本质差异。垂直扩展是指通过升级单台机器的硬件配置来提升性能,例如使用更快的CPU、更大的内存或更快的存储设备。而横向扩展则是通过增加机器数量来分散工作负载,使系统能够处理更大的请求量。
然而,横向扩展并非万能解决方案。一个经常被忽视的事实是,并非所有计算任务都能够并行化。在数据库事务处理中,如果多个事务试图修改相同的数据行,系统就必须以某种方式协调它们的执行顺序。这种协调开销往往会成为性能的主要瓶颈,而不是网络通信或数据存储本身。 让我们以PostgreSQL为例来说明这一点。PostgreSQL在大多数情况下是一个单节点数据库,它不会自动在多台机器间分配计算负载或存储容量。
虽然可以通过部署多个PostgreSQL实例并配置读副本来实现一定程度的水平扩展,但这种扩展需要开发者自行处理数据分片、负载均衡和一致性保证等复杂问题。PostgreSQL的设计哲学是将简单情况保持简单,将复杂情况留给需要它的用户。 相比之下,像Neon这样的云原生数据库解决方案在存储层面实现了水平扩展。它将表数据存储在对象存储中,并通过本地页面缓存结构来加速数据访问。这种架构为数据库提供了理论上无限的存储容量,但在计算能力方面仍然受限于单个主节点的写入能力。Neon的方案展示了如何将不同维度分离处理,这为后续的架构创新提供了重要启示。
再看CockroachDB这样的分布式关系数据库,它的架构设计从一开始就将水平扩展作为核心目标。CockroachDB采用对称架构,集群中的任何节点都可以处理SQL请求,包括读取和写入操作。数据通过范围机制分布在整个集群中,每个范围通常会被复制到三台机器上以保证可靠性。这种设计在理论上提供了优秀的水平扩展能力,但实践中的表现却往往不如预期。 问题的根源在于数据竞争。当多个事务同时试图修改相同的数据时,它们必须协调执行顺序以保证事务的隔离性。
在单节点数据库中,这种协调发生在内存和CPU缓存层面,开销相对较小。但在分布式数据库中,协调需要跨越网络进行,涉及复杂的分布式共识机制。即使是看似简单的提交操作,也需要等待多数节点确认后才能完成。这意味着原本在单节点上可能只需要几微秒的事务,在分布式环境中可能需要数毫秒才能完成。 考虑一个典型的OLTP场景:一个事务需要修改用户表和关联的元数据表。在单节点PostgreSQL中,这两个表的数据很可能位于同一台机器上,整个事务可以在单个CPU核心上快速完成。
但在CockroachDB集群中,如果使用随机主键,数据被分散在多台机器上的概率会很高。这意味着原本可以在一台机器上完成的事务,现在需要跨越网络与多个节点通信协调。根据概率计算,在一个包含N个节点的集群中,两个随机选择的行位于同一台机器上的概率约为N分之一。 更糟糕的是数据竞争带来的性能退化。假设一个热门数据行的关键部分只需要三微秒就能完成修改。在单节点高性能配置下,每秒可以处理约三十万个并发事务。
但如果在分布式环境中每次提交需要一毫秒(这在分布式系统中并不罕见),那么同样的数据每秒只能处理约一千个事务。性能下降了三百倍!这种退化的根本原因在于:当存在数据竞争时,多个写事务的执行必须串行化,而分布式协调的开销远高于本地协调。 这引出了一个反直觉但极其重要的结论:在存在数据竞争的OLTP场景下,单节点高性能数据库的扩展效率可能远超分布式数据库。虽然分布式数据库看起来能够通过增加机器来提升性能,但每台机器都需要承担协调开销。当工作负载存在竞争时,增加机器数量并不能有效提升吞吐量,因为热门数据点上的事务仍然必须串行执行。 理解了这一点,我们就能明白为什么Spacetime选择了单线程执行模型作为其核心设计原则。
在数据库引擎的早期开发阶段,团队曾经尝试过并行执行和MVCC事务机制,但当他们实际测量性能时,发现单线程执行反而表现更好。这个发现可能让很多习惯于认为并行化总能提升性能的工程师感到意外,但它深刻反映了现代CPU架构中缓存一致性的重要性。 现代CPU的L1缓存延迟可能比L3缓存低二十倍以上。当并行化工作负载将廉价的本地缓存访问转变为频繁的跨核同步和通信时,可能需要十多个核心才能匹配一个经过仔细优化的单核心性能。这还没有考虑网络请求、序列化开销以及分布式元数据管理带来的额外缓存未命中问题。在很多场景下,增加硬件投入不仅无法提升性能,反而可能因为引入更多协调开销而导致性能下降。
Spacetime的设计哲学与此密切相关。它并不试图让分布式协调变得免费,而是确保只有真正需要跨机器协调的工作负载才需要承担这种开销。这种理念体现在其基于Actor模型的整体架构中。在Spacetime中,每个数据库都是一个单线程的执行单元,拥有自己的状态和事务日志。不同数据库上的事务可以并行执行而无需相互协调,只有那些需要跨数据库边界的操作才会涉及分布式事务机制。 这种方法论的核心洞察是:水平扩展性本质上取决于工作负载本身的特性,而非数据库系统本身。
如果你的事务主要在单一数据集上操作且存在竞争,那么单节点高性能数据库可能是更好的选择。如果你的事务跨越多个数据集且相互独立,那么通过增加机器来分散负载是有意义的。Spacetime的设计允许开发者根据实际工作负载选择合适的扩展策略,而不是一刀切地强制使用分布式架构。 在实际应用中,这种设计已经证明其价值。BitCraft等游戏项目通过维护一个根数据库来处理全局数据,同时部署多个区域数据库来管理不同地区的玩家数据,实现了良好的扩展效果。每个区域数据库处理本区域的玩家交互,这些事务执行快速且本地化,而全局数据操作虽然涉及跨数据库通信,但由于发生频率较低,整体性能仍然保持在高水平。
展望未来,Spacetime计划通过多个阶段进一步增强其水平扩展能力。首先是异步跨数据库通信,允许数据库以类型安全的方式相互发送消息而无需同步等待。然后是分层存储架构,将内存视为最快的缓存层,磁盘作为中等速度的存储层,对象存储作为容量最大但延迟最高的层。这种分层设计的灵感来源于计算机体系结构中的缓存层次结构,通过异步预取和反缓存技术,可以在小事务延迟和大规模存储容量之间取得平衡。 分层存储的关键技术在于避免在等待缓存未命中时阻塞整个事务执行。当事务访问尚未加载到快速存储层的数据时,系统会中止该事务并异步获取数据,同时允许其他事务继续执行。
一旦数据就绪,原始事务可以重新执行。这种方法的美妙之处在于中止几乎不产生任何开销,因为事务尚未提交,而重新执行的代价仅是微秒级的CPU时间,与毫秒级的I/O等待相比可以忽略不计。 网络层面的水平扩展同样重要。Spacetime采用对称架构,允许客户端连接到任意节点,系统会确保写请求被正确路由到目标数据库。这实现了连接的扇入聚合,多个客户端连接可以复用到达数据库主节点的单条连接。对于读取密集型工作负载,可以通过部署一致的读副本来实现读取的扇出分发,从而水平扩展读取吞吐量和带宽。
最后,同步跨数据库事务将通过两阶段提交机制实现真正的分布式事务能力。这种设计允许在需要原子性的场景下跨多个数据库执行操作,同时保持大多数事务的本地快速路径。关键的优化在于保持执行单线程但为分布式事务重新引入MVCC机制,允许并发事务在等待网络往返时继续执行。 总而言之,数据库的水平扩展能力是一个复杂的话题,不能简单地用能或不能来回答。真正的可扩展性取决于工作负载的特性、数据竞争的模式以及系统架构如何在不同维度之间取得平衡。Spacetime通过承认并拥抱这些复杂性,而不是试图掩盖它们,提供了一种务实且高性能的解决方案。
这种方法的核心原则是:你不应该为你不需要的水平扩展付出代价,直到你真正需要它为止。 。
