最大ハッシュサイズの選択と設定

Ultra Light のデフォルトの最大ハッシュサイズである 4 バイトは、ほとんどの場合に適切であるように選ばれています。値を大きくしてロー ID とともに含めるデータを増やすことができます。ただし、そうすると、インデックスのサイズが大きくなり、複数ページに断片化される場合があります。この変更によって、結果的にデータベースのサイズが大きくなる可能性があります。最大ハッシュサイズが大きくなることによる影響は、テーブルに含まれるローの数によって異なります。たとえば、ローの数が少なければ、インデックスのハッシュキーは、大きくてもインデックスページに収まる可能性があります。その場合、インデックスの断片化は起こりません。

最適なハッシュサイズを選択するには、データ型、ローのデータ、データベースのサイズ (特にテーブルに含まれるローの数が多い場合) を考慮してください。

最適なハッシュサイズを選択したかどうかを確認する唯一の方法は、ターゲットデバイスで Ultra Light クライアントアプリケーションに対してベンチマークテストを実行することです。さまざまなハッシュサイズによって、アプリケーションとクエリのパフォーマンスにどのように影響するか、さらにデータベースのサイズ自体がどう変化するかを確認する必要があります。

データ型

カラム内の値全体をハッシュする場合は、次の表で、データ型ごとに必要なサイズを確認してください。Ultra Light では、最大ハッシュサイズは本当に必要になった場合にのみ使用し、指定した最大ハッシュサイズを超えることはありません。カラムのデータ型がバイト制限いっぱいを使用しないかぎり、常により値の小さいハッシュサイズを使用します。

データ型	値全体のハッシュに使用されるバイト数
FLOAT、DOUBLE、REAL	ハッシュなし
BIT と TINYINT	1
SMALL INT と SHORT	2
INTEGER、LONG、DATE	4
DATETIME、TIME、TIMESTAMP、BIG	8
CHAR と VARCHAR	文字列全体をハッシュするには、バイト単位の最大ハッシュサイズが、カラムの宣言されたサイズと一致する必要があります。UTF-8 でエンコードされたデータベースでは、宣言されたサイズを常に 2 倍にします。ただし、最大値は 32 バイトです。たとえば、UTF-8 でエンコードされていないデータベースでカラムを VARCHAR(10) と宣言した場合は、必要なサイズは 10 バイトです。しかし、同じカラムを UTF-8 でエンコードされたデータベースで宣言した場合は、文字列全体のハッシュに使用されるサイズは 20 バイトです。
BINARY	バイト単位の最大ハッシュサイズは、カラムの宣言されたサイズと一致する必要があります。たとえば、カラムを BINARY(30) と宣言した場合は、必要なサイズは 30 バイトです。
UUID	16

たとえば、INTEGER と BINARY (20) と宣言した 2 カラムの複合インデックスに対して最大ハッシュサイズを 6 バイトに設定した場合、データ型のサイズの要件に基づいて、次の処理が行われます。

INTEGER カラムのローの値全体がハッシュされ、インデックスに格納されます。これは、整数のデータ型のハッシュに必要なのは 4 バイトだけだからです。
ハッシュの最初の 4 バイトは INTEGER カラムで使用されるので、BINARY カラムは最初の 2 バイトだけがハッシュされ、インデックスに格納されます。残りの 2 バイトで、BINARY カラムの適切な量がハッシュされない場合は、最大ハッシュサイズを大きくしてください。

ローのデータ

データベースに格納されているデータのローの値も、インデックスのハッシュの有効性に影響します。

たとえば、特定のカラムのエントリ間で共通のプレフィクスを共有している場合は、プレフィクスだけがハッシュされるサイズを選択するとハッシュの効果がなくなる可能性があります。この場合、共通のプレフィクスがハッシュされる以上のサイズを選択する必要があります。共通のプレフィクスが長い場合、値をハッシュしないことも検討してください。

ユニークでないインデックスに重複する値が数多く含まれており、Ultra Light が値全体をハッシュできない場合は、ハッシュによるパフォーマンスの向上は期待できません。

データベースサイズ

各インデックスページには固定のオーバーヘッドがありますが、ページのほとんどの領域は実際のインデックスエントリに使用されます。ハッシュサイズを大きくすると、各インデックスエントリが大きくなり、1 ページに収まるエントリの数が少なくなります。大規模なテーブルになると、大規模なハッシュを使用するインデックスの方が、小規模のハッシュを使用するテーブルやハッシュを使用しないテーブルより、使用するページ数が多くなります。必要なページ数が増えると、データベースサイズが増加し、パフォーマンスが低下します。通常、このパフォーマンス低下が生じるのは、キャッシュで保持できるページ数が固定であり、Ultra Light でページのスワップが発生するためです。

次の表に、インデックスに含まれるデータの格納に必要なページ数にハッシュサイズがどう影響するかの概要を示します。

テーブル	ページサイズ	ハッシュサイズ	エントリ数	必要なページ
テーブル A	4 KB	0	1200	3 ページ
テーブル B	4 KB	32 バイト	116	3 ページ
テーブル C	4 KB	32 バイト	1200 エントリ	11 ページ

ハッシュサイズの設定

最大ハッシュサイズは次の 2 つの方法で設定できます。

データベースのデフォルトの最大サイズを格納することによって、データベースの作成時に max_hash_size 作成パラメーターを設定します。デフォルトでインデックスをハッシュしない場合は、この値を 0 に設定します。インデックスをハッシュする場合は、この値を 32 バイト以内の任意の値に変更するか、Ultra Light のデフォルト値 4 バイトを使用できます。
デフォルトを変更する場合は、新しいインデックスを作成するときに特定のハッシュサイズを設定します。次のいずれかの方法を実行します。
- Sybase Central で、新しいインデックスを作成するときに [最大ハッシュサイズ] プロパティを設定します。
- SQL で、CREATE TABLE 文または CREATE INDEX 文で WITH MAX HASH SIZE 句を使用します。

参照

DocCommentXchange で意見交換できます