最適なハッシュ・サイズの選択

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 ページ