永続クラスによる SQL 最適化テーブルの定義
InterSystems IRIS の SQL では、データ定義言語 (DDL) 文を記述する代わりに、自身を SQL テーブルとして提示する永続クラスを Object Script に定義できます。このページでは、クラス定義に使用することで、テーブルにアクセスする SQL 文に優れたパフォーマンスを実現できる一群のクラス機能について説明します。これらの機能は、新しいクラス定義にも既存のクラス定義にも適用できますが、目的のテーブルにデータが存在する場合は使用に際して注意を要するものがあります。
グローバルの命名方法
データの保存先となるグローバルの名前は、テーブルを定義する USEEXTENTSET クラス・パラメータと DEFAULTGLOBAL クラス・パラメータの値で決まります。インデックスの命名方法も、グローバルの名前によって決まります。この 2 つのパラメータの関係は以下のとおりです。
-
USEEXTENTSET=0 であれば、ユーザ指定の名前と付加された文字コードでグローバル名が構成されます。例えば、名前が Sample.MyTest であるクラスは、マスタ・マップでは ^Sample.MyTestD を名前とするグローバルに対応し、すべてのインデックス・マップでは ^Sample.MyTestI を名前とするグローバルに対応します。DEFAULTGLOBAL を指定している場合は、永続クラス名に代わって、指定したグローバル名が使用されます。
-
USEEXTENTSET=1 の場合は、マスタ・マップおよび独立した各インデックス・マップに対し、ハッシュ化したグローバル名が作成されます。この処理では、パッケージ名とクラス名の両方がハッシュ化され、マスタ・マップとインデックス・マップごとに増分する整数が名前に付加されます。この名前は、そこから意味を読み取れるものではありませんが、グローバルの保存と検索では低レベルで優れた効率を提供します。インデックス・マップごとに別々のグローバルを使用することも、パフォーマンス面と運用面で有利です。DEFAULTGLOBAL を指定した場合は、ハッシュ化したパッケージ名とクラス名に代わって、指定した名前が使用されます。
USEEXTENTSET クラス・パラメータと DEFAULTGLOBAL クラス・パラメータの両方が、ストレージ定義がどのように生成されるかに影響します。すでにストレージ定義があるクラスでこれらのパラメータを変更しても、そのストレージ定義を再設定しない限り、何の効果もありません。"ストレージ定義の再設定" を参照してください。この処理を実行すると既存のどのデータにもアクセスできなくなるので、インポート・データをロードする前に、これらのパラメータを開発環境でのみ更新するようにします。
USEEXTENTSET は 1 に設定することをお勧めします。これは、CREATE TABLE を使用してテーブルを作成するときの既定の設定です。%Persistent から継承するクラスで下位互換性を確保する必要がある場合は、USEEXTENTSET の既定の設定は 0 です。したがって、新しいクラスでは、初めてコンパイルする前に、このパラメータを 1 に設定することをお勧めします。
USEEXTENTSET パラメータと DEFAULTGLOBAL パラメータの詳細は、それぞれ "ハッシュ定義のグローバル名" と "ユーザ定義のグローバル名" を参照してください。
ストレージ・レイアウトの決定
永続クラスを定義して、クラスのすべてのパラメータまたは一部のパラメータで列指向ストレージを活用できます。このような手法の利点と欠点を "SQL テーブルのストレージ・レイアウトの選択" で説明しています。
既定では、クラスのすべてのパラメータで、永続クラスによって行ストレージ・レイアウトが使用されます。ただし、STORAGEDEFAULT パラメータを使用すると、この既定の設定を列指向に設定できます。また、一部のパラメータに行ストレージを使用し、他のパラメータには列指向ストレージを使用する混合ストレージ・レイアウトを定義できます。
Note:
InterSystems IRIS では、クラスにストレージ定義エントリを生成するときに、STORAGEDEFAULT パラメータの値が既定で使用されます。クラスを初めてコンパイルするとき、または新しいプロパティを追加するときにのみ、この値が考慮されます。ストレージの XData ブロックに保存されたストレージ定義がすでに存在するクラスでは、このパラメータを変更しても、クラス・エクステントについて格納されているデータも含め、そのストレージには何の影響もありません。したがって、クラスを初めてコンパイルする前に、使用するストレージ・レイアウトを決定する必要があります。
インデックス
テーブルのフィールドまたはフィールドのグループにインデックスを定義できます。複数の異なるタイプのインデックス (標準、ビットマップ、ビットスライス、および列指向) を定義できます。SQL の最適化では、定義済みのインデックスを使用し、これらのインデックスの対象になっているフィールドが関係する述語に基づいて、クエリ、更新、削除の各操作で特定のレコードにアクセスします。
クラス定義で定義するインデックスと DDL 文で定義するインデックスとの大きな相違点の一つとして、クラスで定義するインデックスは作成と構築を別々の操作にする必要があることが挙げられます。その理由は、クラスのコンパイルはクラス定義にのみ影響し、インデックスのエントリも含め、そのデータは変化しないことにあります。定義したインデックスを今後の SQL クエリで使用するには、そのインデックスを手動で構築する必要があります。
クラス定義でインデックスを定義する例は、"クラス定義を使用したインデックスの定義" を参照してください。
インデックスのフィールドの詳細は、"インデックスの対象" を参照してください。
エクステント・インデックス
エクステント・インデックスは、特定のフィールドのインデックスは作成せず、マスタ・マップにある各行の ID エントリを収めただけの特殊なタイプのインデックスです。ビットマップ適合の IDKEY があるクラスでは、エクステント・インデックスをビットマップ・エクステント・インデックスとして実装できます。このインデックスは、きわめて効率的な存在確認とカウントの機能を提供します。例えば、クエリ SELECT COUNT(*) FROM t は、ビットマップ・エクステント・インデックスがあるテーブルでは、それがないテーブルよりも桁違いに優れた効率を発揮します。
クラスにビットマップ・エクステント・インデックスを定義するには、以下のように記述します。
Index BME [ Extent, Type = bitmap ];
まれな状況として、ビットマップ適合の IDKEY がないクラスでは、Type キーワードを定義しなくてもかまいません。
CREATE TABLE DDL 文を使用してテーブルを作成するときに、ビットマップ・エクステント・インデックスが自動的に作成されます。どの永続クラスにも、ビットマップ・エクステント・インデックスを追加することをお勧めします。標準のインデックス同様に、エクステント・インデックスも作成とは別に構築する必要があります。
