| Oracle® Database管理者ガイド 12cリリース1 (12.1) B71301-11 |
|
 前 |
 次 |
ハッシュ・クラスタは、データ検索のパフォーマンスを向上できます。
ハッシュ・クラスタに表を格納することは、データ検索のパフォーマンスを改善するための1つの選択肢です。ハッシュ・クラスタは、索引付きの非クラスタ化表または索引クラスタの代替手段を提供します。
索引付きの表または索引クラスタでは、Oracle Databaseは、表内の行の位置を特定するために、別個の索引に格納しているキー値を使用します。ハッシングを使用するには、ハッシュ・クラスタを作成し、そこに表をロードします。表の行は物理的にはハッシュ・クラスタに格納され、ハッシュ関数の結果に従って検索されます。
Oracle Databaseはハッシュ関数を使用して、特定のクラスタ・キー値に基づく、ハッシュ値と呼ばれる数値の分布を生成します。ハッシュ・クラスタのキーは、索引クラスタのキーと同じように単一列キーでもコンポジット・キー(複数列キー)でもかまいません。ハッシュ・クラスタ内で行を検索または格納する場合、データベースは行のクラスタ・キー値にハッシュ関数を適用します。結果として生成されるハッシュ値はクラスタ内のデータ・ブロックに対応しており、データベースは、発行された文のかわりにそのデータ・ブロックに対して読取りまたは書込みを行います。
索引付きの表または索引クラスタ内の行を検索または格納するためには、少なくとも2回(通常はそれ以上)のI/Oを実行する必要があります。
1回以上のI/Oによる、索引内でのキー値の検索または格納
別のI/Oによる、表またはクラスタ内での行の読取りまたは書込み
一方、ハッシュ・クラスタでは、ハッシュ関数を使用して行の位置が特定されるので、I/Oは必要ありません。結果として、ハッシュ・クラスタ内の行の読込みや書込みに必要とされるのは最小限のI/O操作のみになります。
関連項目:
この章のタスクを実行する前に、「スキーマ・オブジェクトの領域の管理」を一読されることをお薦めします。
ハッシングが最も有用である状況とまったく利点がない状況を対比することにより、どのような場合にハッシュ・クラスタを使用するかを決定できます。ハッシングではなく索引を使用する場合は、表を個別に格納するのか、またはクラスタの一部として格納するのかを考慮してください。
注意:
ハッシングを使用する場合でも、クラスタ・キーを含む表のどの列にも異なる索引を設定できます。
ハッシングは、ほとんどの問合せがクラスタ・キーの等価問合せであり、ハッシュ・クラスタ内の表のサイズが主に静的である場合に有効です。
ハッシングは、次のような状況で有効です。
ほとんどの問合せが次のようなクラスタ・キーとの等式を含んでいる場合。
SELECT ... WHERE cluster_key = ...;
このような場合、等価条件内のクラスタ・キーがハッシュされ、対応するハッシュ・キーが通常1回の読込みで検索されます。それに対して、索引付きの表では、最初にキー値を索引内で検索する必要があり(通常複数回の読込み)、その後で行が表から読み込まれます(別の読込み)。
ハッシュ・クラスタ内の表のサイズが最初から固定されていて、行数とそのクラスタ内の表が必要とする領域を決定できる場合。ハッシュ・クラスタ内の表でそのクラスタの初期割当てより多くの領域が必要な場合、オーバーフロー・ブロックが必要となるためにパフォーマンスがかなり低下するおそれがあります。
ハッシングは、いくつかの状況では有利ではありません。
ハッシングは次のような状況では有効ではありません。
ほとんどの問合せがクラスタ・キー値全体にわたって行を検索する場合。たとえば、全表スキャンや次のような問合せでは、ハッシュ関数は特定のハッシュ・キーの位置を決定するために使用できません。そのかわりに、全表スキャンと同等の機能を実行して問合せの行をフェッチする必要があります。
SELECT . . . WHERE cluster_key < . . . ;
索引では、キー値はその索引内で順序付けられており、問合せのWHERE句を満たすクラスタ・キー値を、比較的少ないI/Oで見つけることができます。
表が固定でなく、継続的に拡大する場合。表が無制限に拡大する場合、表(そのクラスタ)の存続期間にわたって必要な領域を事前に定義することはできません。
アプリケーションが頻繁に表の全表スキャンを実行し、その表内でデータが散在している場合。この状況でハッシングを使用すると、全表スキャンの処理時間が長くなります。
最終的にハッシュ・クラスタが必要とする領域を事前に割り当てることができない場合。
異なるタイプのハッシュ・クラスタを作成するために、HASHKEYS句を含むCREATE CLUSTER文を使用できます。
ハッシュ・クラスタを作成するには、HASHKEYS句を指定したCREATE CLUSTER文を使用します。
次の文は、trialno列(クラスタ・キー)でクラスタ化されたクラスタをtrial_clusterという名前で作成します。
CREATE CLUSTER trial_cluster ( trialno NUMBER(5,0) )
TABLESPACE users
STORAGE ( INITIAL 250K
NEXT 50K
MINEXTENTS 1
MAXEXTENTS 3
PCTINCREASE 0 )
HASH IS trialno
HASHKEYS 150;
次の文は、trial_clusterハッシュ・クラスタにtrial表を作成します。
CREATE TABLE trial (
trialno NUMBER(5,0) PRIMARY KEY,
... )
CLUSTER trial_cluster (trialno);
索引クラスタの場合と同様に、ハッシュ・クラスタのキーは、単一列でもコンポジット・キー(複数列のキー)でもかまいません。前述の例では、trialno列がキーとなっています。
HASHKEYS値(この例では150)は、ハッシュ関数が生成できる一意のハッシュ値の数を指定し、制限します。指定した値は最も近い素数に丸められます。
HASH IS句を指定しない場合は、内部ハッシュ関数が使用されます。すでにクラスタ・キーがその範囲に均一に分布する一意識別子の場合は、内部ハッシュ関数を無視し、前述の例のようにクラスタ・キーをハッシュ値として指定できます。また、HASH IS句を使用して、ユーザー定義のハッシュ関数を指定することもできます。
ハッシュ・クラスタのクラスタ索引は作成できませんが、ハッシュ・クラスタ・キーに索引を作成する必要はありません。
関連項目:
クラスタ内に表を作成する方法、索引とハッシュ・クラスタに共通するCREATE CLUSTER文のパラメータ設定のガイドライン、およびクラスタを作成するために必要な権限の追加情報は、「クラスタの管理」
ソートされたハッシュ・クラスタには、ハッシュ関数の各値に対応する行が、ソートされた順序で効率よくデータベースから返すことができるような方法で格納されます。常にソート順にデータを使用するアプリケーションの場合、ソートされたハッシュ・クラスタを使用することによって論理I/Oを最小化でき、これにより、より迅速にデータを取得できます。
ある電話会社では、1つの交換機を介した固定数の発信電話番号について、詳細な通話記録を保存するとします。各発信電話番号から、無制限の通話件数が発生する可能性があります。
アプリケーションは、通話が発信されると通話記録を保存します。各通話には、タイムスタンプによって識別される詳細な通話記録があります。たとえば、通話記録がタイムスタンプ0とともに保存され、続いて通話記録がタイムスタンプ1とともに格納されるというように保存されます。
各発信電話番号の請求書が生成されるときには、先入れ先出し(FIFO)で処理されます。次の表に、3つの発信電話番号について詳細な例を示します。
| telephone_number | call_timestamp |
|---|---|
6505551212 |
0, 1, 2, 3, 4, ... |
6505551213 |
0, 1, 2, 3, 4, ... |
6505551214 |
0, 1, 2, 3, 4, ... |
次のSQL文では、telephone_number列がハッシュ・キーです。ハッシュ・クラスタは、call_timestampおよびcall_duration列でソートされます。この例では表定義のクラスタ化とソート用の列にクラスタ定義と同じ名前を使用していますが、これは必須ではありません。ハッシュ・キーの数は、10桁の電話番号に基づいています。
CREATE CLUSTER call_detail_cluster ( telephone_number NUMBER, call_timestamp NUMBER SORT, call_duration NUMBER SORT ) HASHKEYS 10000 HASH IS telephone_number SIZE 256; CREATE TABLE call_detail ( telephone_number NUMBER, call_timestamp NUMBER SORT, call_duration NUMBER SORT, other_info VARCHAR2(30) ) CLUSTER call_detail_cluster ( telephone_number, call_timestamp, call_duration );
例23-1 連続した順序で挿入されるデータ
この例に示すように、call_detail表に行をFIFOで供給するとします。
INSERT INTO call_detail VALUES (6505551212, 0, 9, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 1, 17, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 2, 5, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 3, 90, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 0, 35, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 1, 6, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 2, 4, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 3, 4, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 0, 15, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 1, 20, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 2, 1, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 3, 25, 'misc info'); COMMIT;
例23-2 call_detailの問合せ
この例では、SET AUTOTRACE ONの後、電話番号6505551212のコール詳細についてcall_detail表を問い合せます。
SQL> SET AUTOTRACE ON;
SQL> SELECT * FROM call_detail WHERE telephone_number = 6505551212;
TELEPHONE_NUMBER CALL_TIMESTAMP CALL_DURATION OTHER_INFO
---------------- -------------- ------------- ------------------------------
6505551212 0 9 misc info
6505551212 1 17 misc info
6505551212 2 5 misc info
6505551212 3 90 misc info
Execution Plan
----------------------------------------------------------
Plan hash value: 2118876266
----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 56 | 0 (0)|
|* 1 | TABLE ACCESS HASH| CALL_DETAIL | 1 | 56 | |
----------------------------------------------------------------------
問合せは、問合せプランにソートがないにもかかわらず、タイムスタンプ順に行を取得しています。
次に、既存の行を削除し、その同じ行を不規則な順序で挿入するとします。
DELETE FROM call_detail; INSERT INTO call_detail VALUES (6505551213, 3, 4, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 0, 15, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 0, 9, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 1, 20, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 2, 1, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 1, 6, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 2, 4, 'misc info'); INSERT INTO call_detail VALUES (6505551214, 3, 25, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 1, 17, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 2, 5, 'misc info'); INSERT INTO call_detail VALUES (6505551212, 3, 90, 'misc info'); INSERT INTO call_detail VALUES (6505551213, 0, 35, 'misc info'); COMMIT;
call_detailに同じ問合せを再実行すると、ORDER BY句を指定していない場合でも、データベースから再度行がソート順に取得されます。データベース内部でソートが実行されるため、SORT ORDER BY操作は問合せプランに表示されません。
ここで、非クラスタ化表call_detail_nonclusteredを作成して、例23-1に示したものと同じ値をロードするとします。データをソート順に取得するには、次のようにORDER BY句を使用する必要があります。
SQL> SELECT * FROM call_detail_nonclustered WHERE telephone_number = 6505551212
2 ORDER BY call_timestamp, call_duration;
TELEPHONE_NUMBER CALL_TIMESTAMP CALL_DURATION OTHER_INFO
---------------- -------------- ------------- ------------------------------
6505551212 0 9 misc info
6505551212 1 17 misc info
6505551212 2 5 misc info
6505551212 3 90 misc info
Execution Plan
----------------------------------------------------------
Plan hash value: 2555750302
----------------------------------------------------------------------------------
|Id| Operation | Name |Rows|Bytes|Cost (%CPU)|Time |
----------------------------------------------------------------------------------
| 0| SELECT STATEMENT | | 4 | 224 | 4 (25)| 00:00:01 |
| 1| SORT ORDER BY | | 4 | 224 | 4 (25)| 00:00:01 |
|*2| TABLE ACCESS FULL| CALL_DETAIL_NONCLUSTERED | 4 | 224 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
前述のプランで示した非クラスタ化の場合、ソートを行うにはクラスタ化の場合よりもコストがかかります。ソートされたハッシュ・クラスタに格納されていない表では、行、バイト、コスト、時間のすべてが大きくなります。
表の行への高速アクセスを提供する単一表ハッシュ・クラスタを作成できます。ただし、この表はハッシュ・クラスタ内の唯一の表にする必要があります。
ハッシュ・キーとデータ行の間に1対1のマッピングが必要となるためです。次の文は、クラスタ・キーvarietyを持つ単一表ハッシュ・クラスタpeanutを作成します。
CREATE CLUSTER peanut (variety NUMBER) SIZE 512 SINGLE TABLE HASHKEYS 500;
HASHKEYS値は最も近い素数に丸められるため、このクラスタはそれぞれサイズ512バイトのハッシュ・キー値を最大503個持ちます。SINGLE TABLE句は、ハッシュ・クラスタにのみ有効です。また、必ずHASHKEYSも指定する必要があります。
関連項目:
CREATE CLUSTER文の構文は、『Oracle Database SQL言語リファレンス』を参照してください。
ハッシュ・クラスタを作成するときは、パフォーマンスと使用領域が最適になるように、クラスタ・キーを正しく選択し、HASH IS、SIZEおよびHASHKEYSの各パラメータを設定することが重要です。次に示すガイドラインでは、これらのパラメータを設定する方法について説明します。
正しいクラスタ・キーの選択は、クラスタ化表に対して最もよく発行される問合せのタイプによって決まります。
たとえば、ハッシュ・クラスタ内のemp表について検討します。問合せが従業員番号によって行を頻繁に選択する場合、最適なクラスタ・キーはempno列です。問合せが部門によって行を頻繁に選択する場合、最適なクラスタ・キーはdeptno列です。単一の表を含むハッシュ・クラスタの場合は、通常、含まれる表の主キー全体をクラスタ・キーにします。
ハッシュ・クラスタのキーは、索引クラスタのキーと同じように単一列でもコンポジット・キー(複数列キー)でもかまいません。コンポジット・キーによるハッシュ・クラスタは、データベースの内部ハッシュ関数を使用する必要があります。
HASH ISパラメータを指定するのは、クラスタ・キーがNUMBERデータ型の単一の列であり、均一に分布した整数を含む場合のみです。
この条件を満たしていれば、それぞれの一意のクラスタ・キー値が衝突(同じハッシュ値を持つクラスタ・キーが2つ発生すること)せずに一意のハッシュ値にハッシュするように、クラスタ内に行を分散させることができます。この条件が当てはまらない場合は、この句を指定せずに内部ハッシュ関数を使用してください。
SIZEは、ハッシュ・キーに対応するすべての行を保持するために必要な領域の平均サイズに設定します。
そのため、SIZEを適切に決定するには、格納するデータの特性をよく理解する必要があります。
ハッシュ・クラスタに含まれている表が1つで、その表の行のハッシュ・キー値が一意(1つの値につき1行)である場合、SIZEはクラスタ内の平均の行サイズに設定できます。
ハッシュ・クラスタが複数の表を含む場合、SIZEは代表的なハッシュ値に対応するすべての行を保持するために必要な領域の平均サイズに設定できます。
また、SIZEの見積り値を決定した後で、次の点を考慮してください。SIZEの値が小さい場合(データ・ブロックごとに5つ以上のハッシュ・キーを割り当てることができる場合)は、その値をCREATE CLUSTER文のSIZEに使用できます。しかし、SIZEの値が大きい場合(データ・ブロックごとに割当て可能なハッシュ・キーが4つ以下の場合)は、衝突の発生頻度を予測し、データ検索パフォーマンスと領域使用効率のどちらを重視するか検討する必要があります。
ハッシュ・クラスタで内部ハッシュ関数を使用せず(HASH ISを指定した場合)、衝突がわずかであるか、または衝突のないことが予想される場合は、見積り値をそのままSIZEに設定できます。この場合、衝突は発生せず、領域は可能なかぎり効率的に使用されます。
挿入時に頻繁な衝突が予想される場合、行を格納するためにオーバーフロー・ブロックが割り当てられる可能性は高くなります。衝突が頻繁に起こる場合にブロックのオーバーフローの可能性を軽減し、最大のパフォーマンスを引き出すには、次のようにSIZEを調整する必要があります。
| ブロック当たりの使用可能領域/算出されたSIZE | SIZEの設定 |
|---|---|
1 |
|
2 |
|
3 |
|
4 |
|
>4 |
|
ただし、SIZEの値を過大に見積ると、クラスタ内の未使用領域を増やすことになります。領域効率がデータ検索のパフォーマンスよりも重要な場合は、前述の表で示した調整を無視して、SIZEに元の値を使用してください。
HASHKEYSを指定すると、ハッシュ・クラスタを作成し、ハッシュ・クラスタのハッシュ値の数を指定できます。
ハッシュ・クラスタ内の行を最大限まで分散させるために、データベースはHASHKEYS値を最も近い素数に丸めます。
例では、クラスタ・キーを正しく選択し、HASH IS、SIZEおよびHASHKEYSの各パラメータを設定する方法を示します。すべての例において、データ・ブロック・サイズは2KBで、利用可能なデータ領域(ブロック・サイズからオーバーヘッドを差し引いた領域)の平均は各ブロックの1,950バイトとします。
ハッシュ・クラスタの領域を制御する例を示します。
ハッシュ・クラスタにemp表をロードすることになりました。ほとんどの問合せは、従業員番号によって従業員レコードを検索します。emp表の最大行数は常に10,000、平均の行サイズは55バイトと見積られています。
この場合は、empnoをクラスタ・キーにします。この列には一意の整数が格納されているので、内部ハッシュ関数は無視できます。SIZEは平均の行サイズ(55バイト)に設定できます。これにより、各データ・ブロックに34のハッシュ・キーが割り当てられます。HASHKEYSは、表の行数である10,000に設定できます。この値は、10,000より大きい最初の素数である10,007に切り上げられます。
CREATE CLUSTER emp_cluster (empno NUMBER) . . . SIZE 55 HASH IS empno HASHKEYS 10000;
ハッシュ・クラスタの領域を制御する例を示します。
この例の条件は、「ハッシュ・クラスタ内の使用領域の制御: 例1」の例と同様です。ただし、この例では、ほとんどの場合、行が部門番号によって検索されるとします。平均10名の従業員を持つ部門が最大で1,000部門存在します。部門番号は10ずつ増加します(0、10、20、30、...)。
この場合は、deptnoをクラスタ・キーにします。この列には一様に分布する整数が格納されているので、内部ハッシュ関数は無視できます。事前に見積ったSIZE (各部門のすべての行を保持するために必要な領域の平均サイズ)は55 * 10バイト、つまり550バイトです。SIZEにこの値を使用して、各データ・ブロックに3つのハッシュ・キーのみを割り当てることができます。いくらかの衝突が予想される状況で、最大限のデータ検索パフォーマンスが必要な場合、オーバーフロー・ブロックを必要とする衝突を防ぐために、見積りのSIZEを少し変更してください。SIZEを12%調整して620バイトにすることにより(「SIZEの設定」を参照)、予想される衝突を考慮した上で行の領域をより多く確保できます。
HASHKEYSは、一意の部門番号の数である1,000に設定できます。この値は、1,000より大きい最初の素数である1,009に切り上げられます。
CREATE CLUSTER emp_cluster (deptno NUMBER) . . . SIZE 620 HASH IS deptno HASHKEYS 1000;
索引クラスタの場合と同じように、ハッシュ・クラスタ内のデータに必要な記憶域を見積ることは重要です。
Oracle Databaseは、SIZEおよびHASHKEYSの設定に従って、ハッシュ表の格納に十分な領域の初期割当てを保証します。ハッシュ表サイズを考慮せずに記憶域パラメータINITIAL、NEXTおよびMINEXTENTSを設定した場合は、少なくともSIZE*HASHKEYSに達するまで増分(追加の)エクステントが割り当てられます。たとえば、データ・ブロック・サイズが2KB、各ブロックの使用可能なデータ領域(ブロック・サイズからオーバーヘッドを差し引いた領域)が約1,900バイトの場合に、CREATE CLUSTER文でSTORAGEパラメータとHASHパラメータを次のように指定したとします。
STORAGE (INITIAL 100K
NEXT 150K
MINEXTENTS 1
PCTINCREASE 0)
SIZE 1500
HASHKEYS 100
この例では、各データ・ブロックにハッシュ・キーを1つのみ割り当てることができます。そのため、ハッシュ・クラスタが必要とする初期領域は少なくとも200KB(100×2KB)です。しかし、記憶域パラメータの設定にはこの要件が考慮されていません。そのため、100KBの初期のエクステントと150KBの増分のエクステントがハッシュ・クラスタに割り当てられます。
一方、HASHパラメータが次のように指定されたとします。
SIZE 500 HASHKEYS 100
この場合、各データ・ブロックに3つのハッシュ・キーが割り当てられます。そのため、ハッシュ・クラスタが必要とする初期領域は少なくとも68KB(34×2KB)です。記憶域パラメータの初期設定はこの要件を満たしているため、100KBの初期エクステントがハッシュ・クラスタに割り当てられます。
ハッシュ・クラスタは、ALTER CLUSTER文を使用して変更できます。
たとえば、次のALTER CLUSTER文は、emp_deptクラスタを変更します。
ALTER CLUSTER emp_dept . . . ;
ハッシュ・クラスタの変更に関係する問題は、「クラスタの変更」で説明されている索引クラスタを変更する場合と同じです。ただし、SIZE、HASHKEYSおよびHASH ISの各パラメータはALTER CLUSTER文に指定できません。これらのパラメータを変更するには、クラスタを再作成して、元のクラスタからデータをコピーする必要があります。
ハッシュ・クラスタは、DROP CLUSTER文を使用して削除できます。
たとえば、次のDROP CLUSTER文は、emp_deptクラスタを削除します。
DROP CLUSTER emp_dept;
ハッシュ・クラスタ内の表は、DROP TABLE文を使用して削除されます。ハッシュ・クラスタとハッシュ・クラスタ内の表の削除についての問題は、索引クラスタの場合と同じです。
関連項目:
ハッシュ・クラスタに関する情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。
次のビューには、ハッシュ・クラスタに関する情報が表示されます。
| ビュー | 説明 |
|---|---|
|
|
|
これらのビューでは、表の列とクラスタの列がマップされています。 |
|
これらのビューには、ハッシュ・クラスタのハッシュ関数がリストされます。 |
