可扩展的 SQL
大型站点和应用程序如何保持基于 SQL？
Michael Rys，微软公司
NoSQL 创新的主要推动力之一是渴望实现非常高的可扩展性，以应对互联网规模工作负载的不可预测性。然而，许多大型社交网站（如 Facebook、MySpace 和 Twitter）以及许多其他需要高可扩展性的网站和分布式一级应用程序（如电子商务和银行业）据报道仍以 SQL 为基础构建其核心数据存储和服务。
问题是，他们是如何做到的？
（SQL 实际上是一种声明性查询语言的名称，而更准确地说，本文关注的是传统的关系数据库系统。由于通常将NoSQL 视为关系数据库系统的对立面，因此我们在此处采用了编辑上的自由，使用 SQL 作为关系数据库系统的同义词。）
敏捷性和可扩展性要求
NoSQL/大数据运动的主要目标是实现敏捷性。在各种敏捷性维度中——例如模型敏捷性（更改数据模型的简易性和速度）、操作敏捷性（更改操作方面的简易性和速度）和编程敏捷性（应用程序开发的简易性和速度）——其中最重要的能力之一是快速且无缝地扩展应用程序以适应大量数据、用户和连接。可扩展的架构对于大型分布式应用程序尤为重要，例如社交网络站点、电子商务网站以及更传统的商店和企业的销售点/分支机构基础设施，在这些应用中，应用程序的可扩展性与业务的可扩展性和成功直接相关。
这些应用程序有几个可扩展性要求
• 用户负载方面的可扩展性。 应用程序需要能够扩展到大量用户，可能达到数百万。
• 数据负载方面的可扩展性。 应用程序需要能够扩展到大量数据，可能达到 PB 级，这些数据可能由少数用户产生，也可能是许多用户的聚合产生。
• 计算可扩展性。 对数据的操作应能够随着用户数量和数据大小的增加而扩展。
• 规模敏捷性。 为了扩展以适应应用程序负载的增加或减少，架构和操作环境应提供快速添加或删除资源的能力，而无需更改应用程序或影响应用程序的可用性。
可扩展的架构
几种主要的架构方法实现了高水平的可扩展性。它们中的大多数都基于某种形式的功能和/或数据分区来实现横向扩展，并将工作分布在多个处理节点上。
功能分区 通常遵循面向服务的范例，即使用多个独立的服务构建应用程序，每个服务执行特定的任务（图 1）。这允许应用程序通过根据需要为这些服务分配单独的资源来实现横向扩展。然而，仅靠功能横向扩展分区通常无法提供足够的可扩展性，因为任务数量有限，并且与可扩展性需求的主要驱动因素（用户数量和数据大小）没有直接关系。因此，功能分区通常与数据分区相结合。
数据分区 将应用程序的处理分布在一组数据分区上（图 2）。根据处理节点的拓扑和数据的特性，部署不同形式的数据分区。例如，如果用户群在地理上分散，并且出于可扩展性和性能原因存在地域性要求，例如在世界范围内的社交网站中，那么数据通常会根据这些地理边界进行分区。另一方面，如果横向扩展要求更多地受到对数据运行数据分析算法的成本的限制，则数据可以更随机地分区——例如，基于客户 ID。在这种情况下，相等的分区大小更为重要。
一旦应用程序使用分布式模型构建以实现扩展，它将不得不处理一组超出简单集中式应用程序结构的要求
• 由于数据和处理的分布，在集中式应用程序模型中提供数据一致视图和事务执行的数据库现在分布在许多数据库中。因此，应用程序（或中间层）必须提供额外的事务/一致性层，以提供跨分区的一致性。
• 此外，对应用程序的更改必须以不会干扰应用程序的一致性保证和要求的方式推广到所有分区。例如，如果应用程序针对一组跨多个节点分区的表发出分布式查询，并且应用程序正在更新其中一些分布式表的模式，那么模式更改要么需要向后兼容，以便可以在本地推广，而不会影响正在进行的查询，要么必须全局更新模式，从而在推广阶段影响应用程序的可用性。
• 最后，分区节点故障和网络分区的可能性增加。因此，节点需要冗余，并且应用程序必须能够应对网络分区。
此外，所有这三个要求都必须在不 негативно 影响应用程序服务的可用性的情况下得到满足，而这正是应用程序最初被横向扩展的主要原因。
2000 年，Eric Brewer 提出了一个猜想，即分布式 Web 服务不可能同时提供所有三个保证——一致性、可用性和分区容错性。1 这个猜想现在通常被称为 CAP 定理2，并且是传统关系数据库技术（提供强大的 ACID 保证——原子事务、事务一致性和隔离以及数据持久性）无法同时提供大型分布式应用程序所需的分区容错性和可用性的主要论据之一。
那么，为什么许多领先的社交网站（Facebook、MySpace、Twitter）、电子商务网站（酒店预订系统和购物网站）和大型银行应用程序仍然使用传统的数据库系统（如 MySQL (Facebook,3 Twitter9) 或 SQL Server (MySpace,7 Choice Hotels International,6 Bank Itau5)）而不是使用新的 NoSQL 系统来实现呢？
如何使用 SQL 进行横向扩展？
高层次的答案是，应用程序架构仍然在权衡 CAP 定理要求的相同权衡。考虑到应用程序的可用性必须出于业务原因得到保证，并且不能排除分区和节点故障，应用程序架构必须在所提供的一致性级别上做出一些妥协。请注意，这并不意味着不能使用关系数据库本身；但这表示单个分区节点的强一致性保证不能跨所有节点实现，并且应用程序架构不能使用“传统”数据库技术，例如分布式查询、完全 ACID 事务和请求的同步处理，而不会遇到可用性和可扩展性问题。
例如，传统的分布式查询引擎（如 Microsoft SQL Server 的链接服务器）假设数据源紧密耦合，并且无法适应快速变化的拓扑——无论是由于添加节点还是由于节点故障。它们同步运行，并且在节点故障的情况下会等待节点回复或使查询失败，从而影响服务的可用性。
使用关系数据库系统作为其底层数据存储构建可扩展应用程序有哪些方法？基本上，应用程序架构遵循先前概述的相同面向服务、功能和数据分区方案。每个叶分区将使用关系数据库，提供本地一致性和查询处理。为了保证节点可用性，每个节点将被镜像并实现高可用性。根据围绕故障转移和读取与更新频率的服务级别保证，每个镜像将以同步或异步方式进行管理。
跨许多本地一致节点的全局一致性将根据应用程序要求的级别提供，通常会放宽全局操作的原子性、强一致性和/或隔离性。存在许多技术，例如开放式嵌套事务系统（Saga,4 多级并发控制10）和乐观并发控制方法，以及特定的分区和应用程序逻辑，以降低不一致的风险。例如，开放式嵌套多级事务通过允许某些本地更改在全球事务提交之前变为全局可见来放宽事务隔离。这提高了事务吞吐量，但代价是当必须撤消全局事务及其影响时，可能会产生代价高昂的补偿工作。因此，开放性通常仅限于可交换且具有明确定义的补偿操作的特定操作。实际上，即使某些事务管理器提供了这些高级事务模型，但它们尚未得到广泛使用。
更常见的情况是，应用程序首先对数据进行分区以避免本地冲突，然后使用乐观方法，假设冲突很少发生。这种方法考虑到了大多数人实际上对全局数据的最终一致性状态感到满意这一想法。
接受短期的“不正确”全局状态和结果在我们的日常生活中实际上非常普遍。即使是银行交易也常常是“最终一致的”。例如，兑现支票或结算投资交易在交易执行时不会在全球范围内完全一致。资金可能会在从买方账户中扣除之前进入卖方账户，但可以保证资金最终会被扣除，并且全局状态将变得一致。
使用最终一致性是一种比始终假设全局一致状态更复杂的应用程序设计范例。程序员必须确定可接受的不一致级别——数据可以保持不一致状态多长时间。平台提供商必须以这样一种方式设计系统，使程序员可以轻松理解可能的不一致性，并在出现不一致性时提供处理它们的机制。通常，敏捷性和可扩展性的提升值得应用程序架构的额外复杂性。
将最终一致性作为可接受的全局一致性保证也允许应用程序在网络故障期间提供可用性，从而实现更高的可扩展性。一方面，更新已变得不可用的节点将不再阻止或使全局事务失败，只要系统可以保证它最终将被更新。另一方面，最终一致性允许应用程序在旧数据上运行并仍然提供有用的结果；有时，如果无法查询节点，它甚至允许部分结果（尽管这是应用程序必须做出的决定）。这也意味着架构可以使用异步服务构建，这将提供更高的可扩展性，因为功能服务和各个数据分区可以执行其工作而不会阻止应用程序。
如何使用 SQL 进行扩展的示例
正如我们已经提到的，一些具有高可扩展性要求的应用程序正在传统关系数据库系统之上构建。例如，Twitter 将 NoSQL 数据库 Cassandra 用于其某些需求，但其管理推文的核心数据库系统仍然使用 MySQL 关系数据库系统。9
以下示例概述了 MySpace 如何使用 Microsoft SQL Server 实现其架构的可扩展性。MySpace 仍然是最大的社交网站之一。2009 年，它使用 440 个 SQL Server 实例来管理 1.3 亿用户和一个 PB 的数据，高峰时段有 440 万并发活跃用户。7
正如先前概述的那样，MySpace 已选择同时使用功能分区和数据分区。数据分区在地理上分布，以便更接近某个区域的用户，并进一步按用户 ID 进行分区以实现扩展。这是有道理的，因为大多数用户都希望最频繁地访问他们自己的数据。显然，由于 MySpace 是一个社交网站，个人用户可以在其中连接并留下消息和评论，因此操作不仅针对单个分区，还需要跨分区更新数据。鉴于对可用性和可扩展性的巨大需求，MySpace 需要在规模和正确性之间取得平衡。
基本方法是以异步方式执行大部分工作。更改事件的异步处理以及与应用程序的交互提供了高可用性，并且通过使分区以统一的方式处理排队的请求，系统能够轻松地横向扩展。使用可靠的消息基础设施提供了更改最终变得可见的保证，从而实现了最终的正确性。
图 3 提供了 MySpace 服务调度器架构的高级抽象。它由几十个请求路由器组成，这些路由器调度传入的请求以执行特定的用户或系统操作——例如，在朋友的照片上发布评论、提交博客条目或系统请求（例如部署新的模式对象）。在稳态期间，请求路由器是彼此的精确副本，包括将服务映射到分区的路由表。
请求以异步方式分布在路由器之间，并被调度到各个帐户分区（在 MySpace 的情况下约为 440 个）和请求的服务端点。请注意，帐户分区在稳态下提供所有相同的服务和模式，从而保证每个服务都可以由每个节点提供，而无需依赖任何其他节点。
每个路由器以及每个分区和服务都使用 SQL Server 和 SQL Server Service Broker 实现。Service Broker 是使此架构可靠有效地工作的关键要素。它提供了异步消息传递功能，允许请求在服务之间高速流动。Service Broker 与其他服务总线和异步消息传递组件一样，允许通过简单地在不同分区上添加同一服务的多个实例来实现横向扩展。请求在这些服务实例之间进行负载平衡，而无需更改应用程序逻辑。与 MQSeries、RabbitMQ、NServiceBus 和 MSMQ（Microsoft 消息队列）等其他一些消息总线的有趣区别在于，Service Broker 深入构建到数据库引擎中。
除了提供可扩展的架构外，Service Broker 还提供了一种通信结构，保证发送到服务的消息能够可靠、按顺序且仅一次地传递。这保证了即使在发生网络分区或节点故障的情况下，消息也不会丢失，而是在节点重新连接后最终会被传递。由于每个服务都将由数据库服务器执行，因此本地一致性在为特定事务指定的级别上提供。使用 Service Broker 构建和扩展服务将提供全局最终一致性。
每个分区的可用性可以通过使用数据库镜像提供故障转移副本的方式来提高。如果发生故障转移，Service Broker 连接也会自动且透明地故障转移。
所描述的应用程序横向扩展架构通过在所有请求路由器上复制所有路由信息并在所有分区上提供服务，避免了单点故障和争用。使用 Service Broker 进行异步处理提供了可扩展性以及最终一致性。然而，架构、服务和分区将随着时间的推移而演变。因此，当数据重新分区时，对路由信息的更改以及对服务和模式的更新也需要以可扩展的方式维护。如果在向路由表添加新分区时跨所有请求路由器获取全局锁，那将是不好的。
为了解决这个问题，当前的架构使用相同的基于 Service Broker 的方法来推广对服务和模式的更改。帐户服务的重新分区将异步更新。为了在路由器的路由表更新之前检测到分区中的更改，如果分区假设无效，则分区将使请求失败，并将更新后的信息返回给路由器，然后路由器将基于新的路由信息重试请求。
类似的架构也正在被用于多个基于关系数据库的电子商务网站。例如，Bank Itau 提供了一个可扩展的分支银行系统5，而 Choice Hotels International 使用异步消息传递构建了一个高度可扩展的在线酒店预订系统6。
总结与展望
构建可扩展的数据库应用程序不一定是一个关于应该使用关系数据库系统还是 NoSQL 系统的问题。这更多的是一个关于选择足够敏捷以进行扩展的正确应用程序架构的问题。例如，将异步消息传递与关系数据库系统相结合，可以提供强大的基础设施，使开发人员能够构建高度可扩展、敏捷的应用程序，这些应用程序提供分区容错和可用性，同时提供高水平的最终一致性。
使用 SQL 的横向扩展应用程序正在使用与使用 NoSQL 的横向扩展应用程序类似的架构原则构建，同时为声明性查询处理、优化、索引和数据存储/高可用性提供更成熟的基础设施。此外，无需用具有不同配置、管理和故障排除要求的不同数据库系统替换数据层，即可扩展现有的 SQL 应用程序，这一点非常具有吸引力。
在决定使用 SQL 数据库系统还是 NoSQL 数据库系统时，还需要考虑其他方面，例如数据模型、敏捷性要求、查询优化、数据处理逻辑、现有基础设施以及个人能力、优势和劣势。遗憾的是，讨论这些方面超出了本文的范围。
然而，所有数据库系统，无论是关系数据库还是 NoSQL 数据库，仍然需要提供额外的服务，以便开发人员更容易构建大规模可扩展的应用程序。例如，关系数据库系统应增加对数据分区横向扩展（如分片8）的集成支持。NoSQL 数据库正在努力提供更多传统数据库功能，例如二级索引、声明性查询语言等。
在数据库系统提供易于使用的横向扩展服务之前，开发人员将不得不设计具有横向扩展意识的应用程序，并使用更通用的应用程序模式，例如异步消息传递、功能和数据分区以及容错，以构建提供高可用性和可扩展性的容错系统。
问
致谢
我要感谢 Erik Meijer、Luis Vargas 和 Terry Coatta 的审阅和富有洞察力的评论，这些评论极大地改进了本文。
参考文献
1. Brewer, E. A. 2000. Towards robust distributed systems. (Invited talk) Principles of distributed computing, Portland, Oregon, (July).
2. CAP; http://en.wikipedia.org/wiki/CAP_theorem.
3. Facebook; http://blog.facebook.com/blog.php?post=7899307130.
4. Garcia-Molina, H., Salem, K. 1987. Sagas. Proceedings of the 1987 SIGMOD International Conference on Management of Data: 249-259; http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/sigmod87.html#Garcia-MolinaS87.
5. Helland, P., Stelzmuller, C. 2009. SQLCAT: SQL service broker: high-performance distributed applications in real-world deployments. PASS Summit; http://www.softconference.com/pass/sessionDetail.asp?SID=174551.
6. Microsoft Case Studies. 2011. Global hotel company delivers reservations in milliseconds with highly reliable system; http://www.microsoft.com/casestudies/Microsoft-SQL-Server-Service-Broker/Choice-Hotels-International/Global-Hotel-Company-Delivers-Reservations-in-Milliseconds-with-Highly-Reliable-System/4000009199.
7. Microsoft Case Studies. 2009. MySpace uses SQL Server Service Broker to protect integrity of 1 petabyte of data; http://www.microsoft.com/Casestudies/Case_Study_Detail.aspx?casestudyid=4000004532.
8. MSDN Blogs; http://blogs.msdn.com/b/cbiyikoglu/archive/tags/federations/.
9. Twitter; http://engineering.twitter.com/2010/07/cassandra-at-twitter-today.html.
10. Weikum, G. 1986. A theoretical foundation of multilevel concurrency control. Proceedings of the Fifth SIGACT-SIGMOD Symposium on Principles of Database Systems (PODS): 31-43.
喜欢还是讨厌？请告诉我们
Michael Rys ([email protected]) 是微软 SQL Server RDBMS 团队的首席项目经理。他负责超越关系数据和服务的场景，包括非结构化和半结构化数据管理、搜索、空间、XML 等。他代表微软公司参加 W3C XML Query 工作组和 ANSI SQL 标准化工作。1998 年加入微软之前，他在斯坦福大学（博士后）和苏黎世瑞士联邦理工学院从事面向对象和半结构化数据库、多级事务管理以及分布式异构信息集成方面的研究，并在苏黎世瑞士联邦理工学院获得博士学位。Rys 是 的高级会员，也是 IEEE 的会员，并在 XQuery 和 XML 以及数据库方面做过多次演讲并为多本书籍做出了贡献。他的网络日志可以在 http://sqlblog.com/blogs/michael_rys/default.aspx 找到，并且可以在 @SQLServerMike 上关注他（当他有时间发推文时）。
© 2011 1542-7730/11/0400 $10.00
最初发表于 Queue vol. 9, no. 4—
在 数字图书馆 中评论这篇文章
更多相关文章
Qian Li, Peter Kraft - 事务和无服务器是天作之合
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台实现了许多在现有无服务器平台或基于服务器的部署中不可能实现的新功能。
Pat Helland - 任何其他名称的身份
新兴的系统和协议都在收紧和放松我们对身份的概念，这很好！它们使完成工作变得更容易。REST、IoT、大数据和机器学习都围绕着有意保持灵活且有时模糊的身份概念。身份概念是我们分布式系统的基本机制的基础，包括互换性、幂等性和不变性。
Raymond Blum, Betsy Beyer - 实现数字持久性
当今的信息时代正在为世界所依赖的数据创造新的用途和新的管理方式。世界正在从熟悉的物理人工制品转向更接近信息本质的新型表示方式。我们需要流程来确保知识的完整性和可访问性，以保证历史将被知晓和真实。
Graham Cormode - 数据草图
您是否曾经感到被源源不断的信息流所淹没？看起来似乎永无止境的新电子邮件和短信需要持续关注，还有电话要接听、文章要阅读、敲门声要回应。将这些碎片拼凑在一起以跟踪重要内容可能是一个真正的挑战。为了应对这一挑战，流数据处理模型越来越受欢迎。其目标不再是捕获、存储和索引每一分钟的事件，而是快速处理每个观察结果，以便创建当前状态的摘要。
© 保留所有权利。