系统架构: 第3章并行架构: 进程和内存协调

前言

本文摘自经典英语论文“系统的体系结构”（下载原始英语PDF），原始作者是Joseph M. Hellerstein，Michael Stonebraker和James Hamilton. 该论文可作为入门阅读为中国主要大学的实验室的提供帮助，帮助学生快速了解的内部运行机制.

本文包括6章，即: 第1章概述，第2章流程模型，第3章并行体系结构: 进程和内存协调，第4章关系查询处理器，第5章存储管理，第6章事务: 并发控制和恢复，第7章共享组件和第8章结论.

本文的翻译是由厦门大学实验室的林子瑜老师团队完成的. 其中，林子瑜负责校对，刘英杰负责翻译第一章和第二章，罗道文负责翻译第三章和第四章. 第三章，谢荣东同学负责翻译第五章，第六章，第七章和第三章. 8.

如果对本文的翻译有任何疑问，请联系林子瑜先生.

林子瑜的电子邮件是: ziyulin@xmu.edu.cn.

林子瑜的个人主页是: .

厦门大学实验室的网站是:

厦门大学海云花园林子玉

2013年9月

摘要

管理系统（DBMS）广泛存在于现代计算机系统中，并且是其中的重要组成部分. 它是学术界和工业界数十年来研究与开发的结果. 在计算机开发的历史中，是最早开发的多用户服务系统之一. 因此，其研究也催生了许多系统开发技术，以确保系统的可伸缩性和稳定性. 这些技术现在已在许多其他领域中使用. 尽管在教科书中可以找到许多与有关的算法和概念，但是有关如何使工作的系统设计问题的信息很少. 本文从体系结构的角度讨论了一些设计指南，包括处理模型，并行体系结构，存储系统设计，事务处理系统，查询处理和优化结构以及代表性的共享组件和应用程序. 当行业中有多种设计方法可供选择时，我们将使用当前成功的商业开源软件作为参考标准.

备注:

（1）您可以转到页面底部下载本章的PDF文件；

（2）您可以访问“系统架构（中文版）”的整页，以查看本文的其他章节.

第3章并行架构: 进程和内存协调

在现代服务器中，并行硬件已经是不争的事实. 它们以各种配置存在. 在本章中，我们将总结标准的管理系统术语，然后讨论过程模型和内存协调（内存协调）问题.

3.1共享内存

在具有共享内存的并行系统中（如图3-1所示），所有处理器都可以使用相同的内存和硬盘，并且性能大致相同. 现在，该体系结构已成为标准. 大多数服务器硬件包含2到8个处理器. 高端计算机可以包含数十个处理器，这些处理器可以提供更高的处理器资源，但通常更昂贵. 高度并行的共享内存机器是硬件行业中最后的之一，并且广泛用于高端交易处理应用程序中. 服务器硬件的成本不可避免地与管理系统的成本相形见,，因此有时购买少量大型，昂贵的系统是可以接受的折衷方案.

图3-1共享内存架构

多核处理器支持多个处理内核，并在单个芯片上共享一些基础结构，例如缓存和内存总线. 就编程而言，这使其与共享内存体系结构非常相似. 如今，几乎所有部署都涉及多个处理器，每个处理器具有多个CPU. DBMS体系结构需要充分利用这种潜在的并行性. 幸运的是，第2章中介绍的所有三个DBMS的体系结构在现代共享内存硬件体系结构上都可以很好地工作.

共享内存机器的过程模型自然遵循单处理器方法. 实际上，大多数系统都是从其原始的单处理机实现的，然后演变为共享内存的实现. 在具有共享内存的计算机中，操作系统通常支持将作业（进程或线程）透明地分配给每个处理器，并且共享数据结构可以继续被所有作业访问. 这三种模型都可以在这些系统上很好地运行，并支持执行多个独立的SQL并行请求. 主要挑战是修改查询执行层，以利用将单个查询语句并行化到多个处理器的能力. 我们将推迟第5章的介绍.

3.2不共享

无共享并行系统由多个独立计算机组成的集群组成，这些计算机可以通过网络高速相互通信，也可以在商业网络组件上逐渐频繁地通信. 对于给定的系统，不能直接访问另一个系统的内存和硬盘.

图3-2不共享的体系结构

没有共享的系统不提供抽象的硬件共享，协调不同机器的任务完全留给了DBMS. DBMS支持这些集群的最常用技术是在集群中的每台机器或节点上运行它们的标准流程模型. 每个节点都可以接受客户端SQL请求，访问所需的元数据，编译SQL请求以及访问数据，就像上述单个共享内存一样. 主要区别在于集群中的每个系统仅保存部分数据. 对于每个SQL请求，无共享系统中的每个节点不仅单独执行本地数据查询，还将此请求发送到群集的其他成员，然后所有计算机并行执行本地保存数据的查询. 每个表都通过水平数据分区传播到集群中的多个系统，因此每个处理器可以独立于其他处理器执行.

中的每个元组都分配给一台单独的机器，因此每个表都被水平拆分，然后分布在整个系统中. 典型的数据分区方案包括: 元组属性的基于散列的分区，元组属性的基于范围的分区，轮询和混合分区方案（前两种方案的混合）. 每台单独的计算机负责访问，锁定和记录本地磁盘上的数据. 在查询执行期间，查询优化器将选择如何对表进行水平重新分区，然后将中间结果分配给每台计算机以满足查询的需求，然后将作业的逻辑分区分配给每台计算机. 不同计算机上的查询执行组件将数据请求和元组发送到其他计算机，但是不需要传输任何线程状态和其他低级信息. 使用基于值的元组分区的自然结果是，在这些系统中，仅需要最小的协调. 但是，为了获得良好的性能，您需要一个良好的数据分区. 这给管理员带来了巨大的负担-合理，明智地确定表的分布. 同时，这给查询优化器带来了沉重负担，需要在负载分配方面做好工作.

这种简单的分区方案无法解决DBMS上的所有问题. 例如，必须采用明确的跨处理器协调来处理事务完成，提供负载平衡并支持某些维护任务. 例如，对于分布式死锁检测和两阶段提交[30]之类的问题，必须在处理器之间交换明确的控制信息. 这需要附加的逻辑，如果执行不当并行处理系统结构，可能会成为性能瓶颈.

同时，在无共享系统中，必须正确管理本地故障. 在非共享系统中，处理器故障通常会导致整个系统停止运行，因此整个DBMS也将停止运行. 在无共享系统中，群集中单个节点的故障不一定会影响其他节点. 但是，这肯定会影响DBMS的整体操作，因为中的部分数据存储在故障节点中. 在这种情况下，至少有三种可行的方法. 第一种方法是在任何一个节点发生故障时停止所有节点. 这实际上是在模拟共享内存系统中将发生的情况. 第二种方法在Informix上称为“数据跳过”，它允许在正常节点上继续执行查询，同时跳过故障节点的数据. 当数据的可用性比结果的完整性更重要时，这很有用. 但是，由于种种努力，它没有明确定义的语义，这对于许多工作负载而言不是一个有用的选择，尤其是因为DBMS在多层系统中经常被用作“记录存储库”. 高层（通常是应用程序服务器）权衡可靠性和一致性. 第三种方法是采用冗余方案，范围从完整的故障恢复（需要两倍的计算基础和软件）到类似于链集群的细粒度冗余[43]. 在后一种技术中，元组的副本将分布在群集中的多个节点之间. 与其他简单机制相比，链式群集的优势在于: （a）与其他简单机制相比，需要部署的机器数量更少，以确保更好的可用性； （b）当一个节点发生故障时，系统负载将平均分配给其余节点: 其余n-1个节点，每个节点完成原始工作n /（n-1）. 线性性能下降的这种形式将随着节点的故障而继续. 实际上，介于两者之间的是许多常见的商业系统，既没有粗粒度的完整冗余，也没有细粒度的链簇.

无共享架构在当今非常普遍，并且具有无与伦比的可扩展性和成本特征. 它主要用于极高端的应用程序，通常是决策支持应用程序和数据仓库. 在一个有趣的硬件体系结构组合中，无共享群集通常由许多节点组成，并且每个节点都是具有共享内存的多处理器.

3.3共享磁盘

如图3-3所示，在具有共享磁盘的并行系统中，所有处理器都可以访问性能大致相同的磁盘，但不能访问彼此的RAM. 这种体系结构非常普遍，两个突出的示例是Oracle RAC和DB2 for zSeries SYSPLEX. 随着存储区域网络（SAN: Storage Area Networks）的普及，共享磁盘近年来变得越来越普遍. SAN允许将一个或多个逻辑磁盘安装在一个或多个主机系统上，这使创建共享磁盘配置更加容易.

图3-3共享磁盘体系结构

共享磁盘系统相对于非共享系统的一个潜在优势是它们具有较低的管理成本. 共享磁盘系统中的DBA无需考虑将表分区和分发到其他计算机即可实现并行性. 但是，大型仍需要分区，因此对于大型，两者之间的差异不是很大. 共享磁盘体系结构的另一个显着特征是，单个DBMS处理节点的故障不会影响其他节点对整个的访问. 这与共享内存系统（整体上发生故障）和无共享系统（由于节点的故障而导致，至少使用某些其他数据冗余机制将导致至少某些数据不可访问）不同，这是不同的. 但是，即使具有这些优点，共享磁盘系统仍然容易遭受单点故障. 当数据未到达存储子系统时，如果数据由于硬件或软件故障而损坏或以其他方式破坏，则系统中的所有节点只能访问这些损坏的页面. 如果存储子系统使用RAID或其他数据冗余技术，则损坏的页面将被冗余地存储，但所有副本仍会损坏.

由于不需要在共享磁盘系统中对数据进行分区，因此可以将数据复制到RAM并在多台计算机上进行修改. 与共享内存系统不同，共享磁盘系统没有自然的内存位置来协调数据共享，并且每台计算机都有为锁定和缓冲池页面准备的本地内存. 因此，有必要协调多台计算机之间的显示数据共享. 共享磁盘系统依赖于分布式锁管理设备和缓存一致性协议来管理分布式缓冲池. 这些是复杂的软件组件，并且可能成为竞争负载的瓶颈. 某些系统由硬件子系统管理，例如IBM zSeries SYSPLEX.

3.4内存访问不平衡

具有独立内存的群集系统中的不平衡内存访问（NUMA: 非统一内存访问）系统提供了共享内存编程模型. 群集中的每个系统都可以快速访问本地内存，但是高速群集中每台计算机之间的远程访问都有一定程度的互连延迟. 这种体系结构的名称来自内存访问时间的这种不一致.

NUMA的硬件体系结构是无共享系统和共享内存系统之间有趣的中间地带. 它们比什么都不共享的群集容易编程，并且它们的处理器比共享内存系统更大. 您可以避免争用共享点，例如共享内存系统总线.

NUMA群集尚未获得广泛的商业成功，但是NUMA设计概念已在共享内存多处理器领域采用. 随着共享内存多处理器系统扩展到大量处理器，它们在内存体系结构中显示出越来越大的不平衡. 通常并行处理系统结构，大型共享内存多处理器系统的内存分为多个部分，每个部分与系统中一小部分处理器相关联. 内存和CPU的每个组合子集通常称为“ pod”. 每个处理器访问本地Pod存储器的速度比访问远程Pod存储器的速度快. NUMA设计模式的使用使共享内存系统可以扩展到更多的处理器，这使得NUMA共享内存多处理器现在非常普遍. 但是，NUMA集群并没有成功获得任何重要的市场份额.

DBMS可以在NUMA共享内存系统上运行的一种方法是忽略内存访问的不平衡. 如果不平衡很小，则此方法几乎不能接受. 但是，当短程内存访问时间与远程内存访问时间的比率从1.5: 1增加到2: 1时，DBMS需要使用优化来避免内存访问瓶颈. 这些优化可以采取不同的形式，但是所有优化都必须遵循相同的基本方法: （1）在为处理器分配内存时，尝试使用本地内存（避免使用远程内存）； （2）如果可能，请确保将DBMS用户分配给与以前相同的硬件处理器. 这种组合可以使DBMS负载在更大范围内正常运行. 同时，共享内存系统在内存访问时间上有些不平衡.

尽管NUMA集群几乎消失了，但是编程模型和优化技术对于现代DBMS系统仍然很重要，因为许多大型共享内存系统在内存访问性能上存在重大失衡.

3.5线程和多处理器

当我们删除第2.1节中有关单处理器硬件的第二个简化假设时，当使用DBMS线程为每个DBMS工作者实现一个线程时，潜在的问题立即变得显而易见. 第2.2.1节中描述的轻量级DBMS线程包的自然实现是，所有线程都在单个操作系统进程中运行. 不幸的是，单个进程一次只能在一个处理器上执行. 因此，在多处理器系统中，DBMS一次只能使用一个处理器，而系统中的其他处理器将处于空闲状态. 早期的Sybase SQL Server体系结构受到此类限制. 在1990年代，随着共享内存多处理器的日益普及，Sybase迅速改变了系统架构并开发了多系统进程架构.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-199956-1.html