一、概念介紹

table Cluster 是一組共享公共列並在相同塊中儲存相關資料的表。當使用 table cluster 時，單個資料塊可以包含來自多個表的行。例如，一個塊可以儲存來自 employees 和 departments 表的行，而不是隻儲存來自單個表的行。

cluster key   是 table cluster 共有的一列或多列。例如， employees 和 departments 表共享 department_id 列。在建立 table cluster 和建立新增到 table cluster 的每個表時，指定 cluster key 。

cluster key value 是特定行集的 cluster key 列的值。所有包含相同 cluster key value 的資料 ( 如 department_id=20) 都被物理地儲存在一起。每個 cluster key value 只在 Cluster table 和 cluster index 中儲存一次，不管不同表中有多少行包含該值。

例如,

假設一位人力資源經理有兩個檔案櫃 :

一個儲存員工資料夾，另一個儲存部門資料夾。

使用者經常要求查詢特定部門的所有員工的檔案。

為了使檢索更容易，管理員將所有的資料夾重新排列。

她把資料夾按部門編號分開。

因此，所有 deptid=20 的員工資料夾和部門 20 本身的資料夾都在一個盒子裡 ;

部門 100 的員工資料夾和部門 100 的資料夾位於不同的盒子中，依此類推。

當主要查詢表 ( 但不修改 ) 並且表中的記錄經常一起 select 或 join 時，可以考慮使用 table cluster 。由於 table cluster 將不同表的相關行儲存在相同的資料塊中，因此與非叢集表相比，正確使用表叢集具有以下優點：

l   對於叢集表的連線，減少了磁碟 I/O 。

l   提高了對叢集表的連線的訪問時間。

l   儲存相關表和索引資料所需的儲存空間更少，因為不會為每一行重複儲存叢集鍵值。

  通常，在以下情況下不適合使用聚類表 :

l   這些表經常 update 。

l   這些表經常需要 full table scan 。

l   這些表需要 truncate 。

 

二、Index cluster

Index cluster 是使用索引來定位資料的 table cluster 。 cluster index 是叢集鍵上的 B-tree 索引。必須先建立 cluster index ，然後才能將資料行插入到 table cluster 中。

假設您使用叢集鍵 department_id 建立了叢集 employees_departments_cluster ，如示例 2-8 所示。因為沒有指定 HASHKEYS 子句，所以這個叢集是一個索引叢集。然後，在這個叢集鍵上建立一個名為 idx_emp_dept_cluster 的索引。

Example 2-8 Indexed Cluster

CREATE CLUSTER employees_departments_cluster

   (department_id NUMBER(4))

SIZE 512;

 

CREATE INDEX idx_emp_dept_cluster ON CLUSTER employees_departments_cluster;

然後在叢集中建立 employees 和 departments 表，指定 department_id 列作為叢集鍵，如下所示 ( 省略號表示列定義所在的位置 ):

CREATE TABLE employees ( ... )

   CLUSTER employees_departments_cluster (department_id);

CREATE TABLE departments ( ... )

   CLUSTER employees_departments_cluster (department_id);

  最後，向 employees 和 departments 表新增行。 資料庫在物理上使用 相同資料塊 儲存 employees 和 departments 表的 每個部門的所有行 。 資料庫將這些行儲存在堆中，並使用索引來定位它們。

圖 2-6 顯示了 employees_departments_cluster 表叢集，其中包含員工和部門。 資料庫分別將部門 20 的員工行儲存在一起，將部門 110 的員工的行儲存在一起，以此類推。 如果表不是叢集的，則資料庫不確保將相關的行儲存在一起。

B-tree 叢集索引將叢集鍵值與包含資料的塊的資料庫塊地址 (DBA) 關聯起來。例如， key 20 的索引項顯示了包含 department 20 員工資料的 block 的地址 :

20,AADAAAA9d

叢集索引是單獨管理的，就像非叢集表上的索引一樣，可以存在於與表叢集不同的表空間中。

三、Hash Cluster

雜湊叢集與索引叢集類似，不同之處是索引鍵被雜湊函式替換。不存在單獨的叢集索引。在雜湊叢集中，資料是索引。

對於索引表或索引叢集， Oracle 資料庫使用儲存在單獨索引中的鍵值來定位錶行。要在索引表或表叢集中查詢或儲存一行，資料庫必須執行至少兩個 I/O:

l   在索引中查詢或儲存鍵值的一個或多個 I/O

l   另一個 I/O 來讀取或寫入表或表叢集中的行

  要在 hash cluster 中查詢或儲存一行， Oracle 資料庫將 hash 函式應用於該行的叢集鍵值。產生的 hash 值對應於叢集中的一個資料塊，資料庫根據執行的 sql 語句對這個資料塊進行讀寫。

hash 是一種可選的儲存表資料的方法，以提高資料檢索的效能。 當滿足以下條件時，雜湊叢集提高效能：

l   查詢表的頻率比修改表的頻率高得多。

l   雜湊鍵列經常使用相等條件進行查詢，例如， department_id=20 。 對於這樣的查詢，叢集鍵值是雜湊的，雜湊鍵值直接指向儲存行的磁碟區域。

l   合理地證估雜湊鍵的數量和每個鍵值儲存的資料的大小。

  3.1      Hash Cluster Creation

叢集鍵與索引叢集的鍵一樣，是由叢集中的表共享的單個列或組合鍵。
雜湊鍵值是插入到 cluster 鍵列中的實際值或可能值。 例如，如果叢集鍵是 department_id ，那麼雜湊鍵值可以是 10 、 20 、 30 等等。

每個桶都有一個惟一的數字 ID ，稱為雜湊值。 每個雜湊值對映到儲存與雜湊鍵值對應的行 ( 部門 10 、 20 、 30 ，等等 ) 的資料庫塊地址。

叢集的雜湊值的數量取決於雜湊鍵。 在例 2-9 中，可能存在的部門數為 100 ，因此 HASHKEYS 被設定為 100 。

Example 2-9 Hash Cluster

CREATE CLUSTER employees_departments_cluster

   (department_id NUMBER(4))

SIZE 8192 HASHKEYS 100;

在建立 employees_departments_cluster 之後，可以在叢集中建立 employees 和 departments 表。然後可以將資料載入到雜湊叢集中，就像在示例 2-8 中描述的索引叢集中一樣。

3.2       Hash Cluster Queries

資料庫，而不是使用者，決定如何雜湊使用者輸入的鍵值。例如，假設使用者經常執行以下查詢，為 p_id 輸入不同的部門 ID 號 :

SELECT *

FROM   employees

WHERE  department_id = :p_id;

SELECT *

FROM   departments

WHERE  department_id = :p_id;

SELECT *

FROM   employees e, departments d

WHERE  e.department_id = d.department_id

AND    d.department_id = :p_id;

如果使用者查詢 department_id=20 中的僱員，那麼資料庫可能會將該值雜湊到 bucket 77 。如果使用者查詢 department_id=10 中的員工，那麼資料庫可能會將該值雜湊到 bucket 15 。資料庫使用內部生成的雜湊值來定位包含所請求部門的僱員行的塊。

圖 2-7 將雜湊叢集段描述為水平的塊行。如圖所示，查詢可以在單個 I/O 中檢索資料。

 

雜湊叢集的一個限制是無法對非索引的叢集鍵進行範圍掃描。假設在例 2-9 中建立的雜湊叢集沒有單獨的索引。對於 id 在 20 到 100 之間的部門的查詢不能使用雜湊演算法，因為它不能雜湊 20 到 100 之間的所有可能值。因為不存在索引，所以資料庫必須執行完整掃描。

3.3    Hash Cluster Variations

single-table hash cluster 是雜湊叢集的優化版本，一次只支援一個表。雜湊鍵和行之間存在一對一的對映。當使用者需要通過主鍵快速訪問表時，單表雜湊叢集可能是有益的。例如，使用者經常通過 employee_id 在 employees 表中查詢僱員記錄。

sorted hash cluster 儲存與雜湊函式的每個值對應的行，這樣資料庫就可以有效地按排序順序返回它們。資料庫在內部執行優化排序。對於總是按排序順序使用資料的應用程式，這種技術意味著可以更快地檢索資料。例如，應用程式可能總是對 orders 表的 order_date 列進行排序。

3.4    Hash Cluster Storage

Oracle 資料庫為雜湊叢集分配空間的方式與索引叢集不同。在例 2-9 中， HASHKEYS 指定可能存在的部門數量，而 SIZE 指定與每個部門關聯的資料的大小。資料庫根據以下公式計算儲存空間值 :

HASHKEYS * SIZE / database_block_size

因此，如果示例 2-9 中的塊大小為 4096 位元組，那麼資料庫至少會向雜湊叢集分配 200 個塊。

Oracle 資料庫不限制可以插入到叢集中的雜湊鍵值的數量。例如，即使 HASHKEYS 是 100 ，也不能阻止您在 departments 表中插入 200 個惟一的部門。但是，當雜湊值的數量超過雜湊鍵的數量時，雜湊叢集檢索的效率就會降低。

為了說明檢索問題，假設圖 2-7 中的 block 100 完全包含了 department 20 的行。使用者使用 department_id 43 將新部門插入到部門表中。 department 的數量超過了 HASHKEYS 值，因此資料庫將 department_id 43 雜湊為雜湊值 77 ，這與 department_id 20 使用的雜湊值相同。將多個輸入值雜湊到同一個輸出值稱為雜湊衝突。

資料庫將塊 100 連結到一個新的溢位塊，比如塊 200 ，並將插入的行儲存在新塊中。 block 100 和 block 200 現在都可以為其中任何一個部門儲存資料。 如圖 2-8 所示，一個部門 20 或 43 的查詢現在需要兩個 I/O 來檢索資料 :block 100 及其相關的 block 200 。 您可以通過使用不同的 HASHKEYS 值重新建立叢集來解決這個問題。

 

 

From 《 Oracle® Database Concepts 11 g Release 2 (11.2) 》 . Overview of Table Clusters

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31442014/viewspace-2679053/，如需轉載，請註明出處，否則將追究法律責任。