Oracle動態并行處理框架及其優越性
2024-08-29 13:51:10
供稿：網友
并行處理技術是數據庫的一項核心技術，它使組織能夠高效地治理和訪問TB級的數據。假如不能提供高效的并行處理技術，這些大型數據庫（通常用于數據倉庫但也越來越多地出現在業務系統中）將不會存在。 簡而言之，并行處理就是利用多個CPU和I/O資源來執行單個數據庫操作。盡管現在每個主要的數據庫供給商都聲稱可以提供并行處理能力，但每個供給商所提供的體系結構其實存在要害的差異。 本文討論Oracle9 i 并行處理的體系結構，并說明于在實際應用中其相對于其它體系結構的優越性。需要著重指出的是，Oracle9i并行處理體系結構的主要優點在于它能在任何情況下完全利用底層硬件基礎架構——每個處理器單元、每個內存字節以及所有可用的I/O帶寬。本文還講述Oracle 并行處理組件與其它要害業務組件（例如：Oracle Realapplication Cluster）的無縫集成。 簡介 現在的數據庫，無論是用于數據倉庫、操作數據存儲(ODS)或OLTP 系統，都包含豐富的信息。然而，由于其中涉及海量數據，及時查找和展示信息是一個巨大的挑戰。并行處理技術能夠解決這一挑戰。使用并行處理技術，數分種內（而非數小時或數天）就可以處理數TB級的數據。并行處理技術通過利用所有可用的硬件資源取得這樣的高性能：多個CPU、多個I/O通道、多個存儲陣列和磁盤驅動器，以及大量的內存。數據庫軟件越能有效地利用所有這些資源，處理查詢和其它數據庫操作就越有效。 此外，現在的數據庫應用的復雜性大大都增強了，不僅需要支持大量并發用戶，而且需要治理不同類型的用戶。因此，一個并行查詢體系結構不僅應該確保底層硬件平臺的所有資源都得到充分利用，而且應該更進一步，將這些資源適當地分配給多個并發請求。很顯然，支持CEO的戰略決策的請求比執行批處理報表更加重要，并行查詢體系結構應該能夠處理這些商務要求：不僅基于請求自身，而且應該基于發出請求的人以及當前可用的系統資源的數量來做出動態的分配。 Oracle9i 的并行處理體系結構能夠全面滿足這些要求，Oracle9i的體系結構不僅提供業界領先的高性能，而且是唯一可以自適應和動態調整的。 Oracle9i 的并行處理體系結構充分利用每種硬件投資――SMP、群集或MPP的優勢——在任何時間保證最佳的吞吐量和連續的、優化的系統使用量。 Oracle9i 數據庫根據可用資源、請求優先級和實際系統負載控制來平衡所有并行操作。 并行化設計策略——靜態與動態 并行處理的思想就是將單個任務分解為多個更小的單元。不是通過一個進程完成所有工作，而是將任務并行化而使多個進程同時在更小的單元上運行。這可以極大地提高性能和最佳地利用系統。然而，并行處理的最要害部分是如何作出將單個任務分成更小的工作單元的正確決策。 典型地，有兩種方法用于實現數據庫系統的并行處理。主要區別在于是否需要進行物理數據布局，將靜態的數據分區作為并行處理的前提。 通過物理數據分區的靜態并行——不共享 在純不共享數據庫體系結構中必須將數據庫文件在多計算機系統的節點上進行分區才能進行并行處理。每個節點擁有一個數據子集，擁有節點使用單一進程或線程，以獨占方式執行對此數據子集的所有訪問。數據訪問不能在分區內并行。（有時，也用術語“虛擬處理器”來代替節點?！疤摂M處理器”是在SMP計算機上模擬不共享節點的一種機制。為了簡單，在討論不共享體系結構時，我們將統一使用“節點”作為術語）。換句話說，純不共享系統使用分區或受限訪問方法在多個處理節點間劃分工作。節點對數據所有權的改變相對少見——為了適應業務需求的改變而進行的數據庫重組、添加或刪除節點以及節點故障是所有權更改的典型原因。這種數據所有權的改變對純不共享系統而言總是意味著要進行人工治理。從概念上看，可以認為純不共享系統與分布式數據庫非常相似。為了在某個節點上執行要求的讀/寫操作，該節點上的事務必須將消息發送給擁有需要被訪問的數據的其它節點，并協調在其它節點上完成的工作。將消息傳遞給其它節點，在它們擁有的數據集上請求執行特定操作（功能）稱為功能傳送。另一方面，假如從遠程節點請求簡單數據，則必須訪問完整的數據集并將它從擁有節點返回至請求節點（數據傳送）。 在不共享體系結構下的并行處理像分布式數據庫一樣運作。每個節點以獨占方式擁有其數據分區。沒有其它任何節點可以訪問此數據，而使節點成為單一的訪問點和故障點 此方法具有一些基本缺點，無法解決今天高端環境對可伸縮性和高可用性要求: (1)、首先，不共享方法在用于共享一切的SMP硬件時并不是最佳的。為了獲得并行處理的益處而要求對數據進行物理分區，在共享一切的SMP系統中很明顯是一種人工的、過時的要求。因為在SMP系統中每個處理器都可以對所有數據進行直接的、等同的訪問。 (2)、其次，在不共享方法中使用嚴格的基于分區的并行處理策略，通常會導致不正常的資源利用。例如以下兩種情況：在沒有必要訪問表的所有分區時；或當單一節點所擁有的更大的未分區表是操作的一部分時。在這些情況下，限制分區內并行處理的緊密所有權模式，無法利用所有可用的處理能力，因而不能提供最佳的處理能力使用方案。 (3)、第三，由于具有對節點對應物理數據分區的關系，不共享系統在適應變化的業務需求方面一點都不靈活。當業務增長時，無法方便地以增量方式擴充系統來適應增長的業務需求?？梢陨壦鞋F有的節點，保持它們對稱并避免數據重新分區。在大多數情形下，升級所有節點費用太高；必須添加新節點并重組（進行物理重新分區）現有數據庫。一個不需要進行任何重組的方案總是比必須重組的方案要更好，即使可以利用到最復雜的重組工具。 (4)、最后，由于使用嚴格的受限制的訪問模式，不共享系統無法完全利用群集系統為保證系統高可靠性所提供的潛在的容錯能力。 毫無疑問，基于使用靜態數據分布的不共享體系結構，大量的并行處理可以在實驗室條件下并行化和擴展。然而，在每個現實環境中，必須正確地解決上面談到的問題才能滿足今天高端要害任務要求。
執行時的動態并行——共享一切 使用Oracle 的動態并行處理框架，可以共享所有數據。并行化和將工作分成更小的單元的決策，并不受限于數據庫設置（創建）時所做的任何預先確定的靜態數據分布。 由于能夠為每個語句構造不受限制的、優化的數據子集，執行時動態并行可以提供與不共享體系結構等同的或甚至更好的可伸縮性。每個查詢在訪問、連接和處理數據的不同部分時都有它自己的特征。因此，每個SQL語句在被解析時都要進行優化和并行化處理。數據更改時，假如有更加優化的并行執行計劃可用，或者系統中新添加了一個節點，那么Oracle可以自動適應新的情況。這樣可為并行化任何種類的操作提供最高程度的靈活性： (1)、在語句執行前，對于每個查詢要求，會動態地優化并行訪問的物理數據子集。 (2)、對于每個查詢，都會優化其并行度。與不共享環境不同，不存在必需的最小并行度來調用所有節點訪問所有數據，這是訪問所有數據的基礎要求。 (3)、操作可以根據當前工作負載、特征和查詢的重要性，使用一個、一些或全部Real Application Cluster 節點并行運行。 只要語句得到優化和并行化，就可以知道所有后續的并行子任務。原始進程變為查詢協調器；并行處理服務器（PX 服務器）從一個或多個節點上的并行處理服務器的公用緩沖池得到分配，并開始并行執行該操作。 與不共享體系結構相似，共享一切體系結構中的每個并行處理服務器在其個人數據子集上獨立工作。數據或功能在并行進程之間的傳送機制也與上述的不共享體系結構相似或者相同。確定請求的并行計劃之后，每個并行處理服務器都知道其數據集和任務，而進程間通信就像在不共享環境中一樣很少。 然而，與不共享體系結構不同，每個并行處理的SQL 語句不需要考慮任何物理數據庫布局限制就可以進行優化。這使得每個并行處理可以構造最佳的數據子集，從而提供與純不共享體系結構相比同等的，甚至在大多數情形下更好的可伸縮性和性能。只要有益，并行操作的后續步驟就會由一個并行處理服務器進行組合和處理，從而減少數據傳送或功能傳送的需求。 為什么共享一切比不共享更好？ 不共享體系結構可以追溯到將海量并行處理(MPP)系統看作唯一能提供可伸縮的高端并行計算的硬件體系結構。MPP系統中的每個節點都有它自己的系統組件（CPU、內存和磁盤），在不同的子任務上工作，并且不能共享其任何資源。 這一切都已過去。現在，大多數成功的、廣泛使用的并行硬件系統都是對稱多處理器系統(SMP)， 要么是單機的，要么是作為松耦合的群集。SMP系統利用共享公用內存和磁盤資源的多處理器，因而也被稱為“共享一切”系統。 純不共享體系結構的支持者總是聲稱共享一切體系結構（非凡是群集環境）對于高端環境會缺乏可伸縮性并引起顯著的開銷，因而這種體系結構不能用于具有高度并行和/或并發性的高端應用。這種說法是錯誤的。今天的硬件和軟件技術已經解決了過去所有的問題，如高速群集互連或Oracle Real Application Clusters 的高速緩存融合體系結構。 Oracle 的動態并行處理框架建立在與不共享軟件相同的并行高級計算基礎設計之上，具有所有的優點，還增強了其功能并克服了不共享方法在體系結構上的缺點。基于不共享原理的軟件可以看作是第一代、但已經過時的數據庫并行處理軟件。
