在多个进程上运行多个DBMS线程时,某个时刻将有一个进程完成大部分工作,而其他进程(与处理器相同)则处于空闲状态. 在这种情况下,为了使该模型更好地工作,DBMS必须在进程之间实现线程迁移.
当DBMS线程映射到多个操作系统进程时,需要做出以下决定: (1)需要使用多少个操作系统进程; (2)如何将DBMS线程分配给操作系统线程; (3)如何分配给多个操作系统进程. 一个好的经验法则是,每个物理处理器都会生成一个进程. 这样可以最大程度地提高硬件的固有并行性,同时最大程度地减少每个进程的内存开销.
3.6标准操作程序
为了支持并行性,这种趋势与上一节中描述的趋势相似,也就是说,大多数主流DBMS支持多种并行模式. 由于共享内存系统(SMP,多核系统以及两者的结合)在商业上的普及,所有主要的DBMS供应商都支持共享内存并行性. 但是,我们开始看到不同的供应商为多节点群集并行性提供了不同的支持(可以使用共享磁盘或无共享设计).
IBM销售不同的DBMS产品,并选择在某些产品上实现共享磁盘支持,并在其他产品上支持无共享模型. 到目前为止,还没有领先的商业系统在单个代码库中同时支持无共享模式和共享磁盘模式. 未实现Microsoft SQL Server.
3.7讨论和其他材料
以上设计代表了在不同服务器系统中使用的一些硬件/软件体系结构模式. 尽管这些设计首先出现在DBMS中,但是在其他数据密集型领域,包括像Map-Reduce这样的低级数据(越来越多的用户使用它来处理各种自定义数据分析任务),对这些数据进行后端编程概念越来越受到认可. 但是,尽管这些设计概念正在更广泛地影响计算,但是系统并行性的设计仍然存在新的问题.
并行软件体系结构将在未来十年中迎来一项重要挑战. 挑战来自处理器供应商开发的新一代“多核”架构的概念. 这些设备将引入新的硬件设计概念,即在单个芯片上具有数十个,数百个甚至数千个处理单元,它们通过高速芯片网络相互连接,但仍保留许多现有的瓶颈,例如,芯片内存和磁盘. 这将导致磁盘和处理器的内存路径出现新的不平衡和瓶颈,这肯定需要重新检查DBMS架构才能满足硬件性能的潜力.
在面向服务的计算领域,已经可以预见到一些相关的体系结构将向更大的规模转移. 这里的核心思想是在由数万台计算机组成的大型数据中心内为用户安排处理(硬件和软件). 在这种规模下,只有实现高度的自动化,应用程序和服务器管理才能负担得起. 服务器数量无法扩展任何管理任务. 此外,群集中通常使用更不可靠的商业服务器,并且不可避免地会发生故障,从故障中恢复需要完全自动化的操作. 如此规模的服务每天都会发生磁盘故障,每周都会发生服务器故障. 在这样的环境中,管理的备份通常被整个的冗余副本所取代,这些副本被保存在不同磁盘上的不同服务器上. 根据数据的价值,冗余副本可以保存在不同的数据中心中. 自动离线备份仍然可以使用,因此可以从应用程序,管理工作或用户错误中恢复. 但是,从最常见的错误和故障中恢复是将故障快速转移到冗余的联机副本. 可以通过多种方式实现冗余: (a)在数据存储级别(存储区域网络)进行复制; (b)在存储引擎级别进行复制(将在7.4节中讨论); (c)由查询处理器执行冗余查询(第6章);或(d)在客户端软件级别(例如,WEB服务器或应用程序服务器)自动生成冗余请求.
在更高级别的分离中,通常在实践中部署具有DBMS功能的多个服务器以降低“ DBMS记录”的请求率. 这些机制包括用于SQL查询的各种形式的中间缓存(包括的内存,例如Oracle TimesTen),以及配置用于此目的的更传统的. 在较高的部署级别上,可以将许多支持编程模型的面向对象“应用程序服务器”架构(例如Enterprise Java Bean)配置为与DBMS一起使用的应用程序对象的事务缓存. 但是,这些方案的选择,设置和管理仍然是非标准,复杂的,仍然难以实现普遍接受的优秀模型.
备注:
(1)您可以转到页面底部下载本章的PDF文件;
(2)您可以访问“系统架构(中文版)”的整页,以查看本文的其他章节.
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-199956-2.html
我也昨天也喝了黑芝麻糊
再看你是什么反应