この記事では、2025.2リリースで導入された、IRIS SQL処理の重要な要素、InterSystems IRISのテーブル統計処理の大きな改善について紹介します。 まず最初に、テーブル統計とは何か、どのように利用されるのか、そしてなぜ今回の改善が必要だったのかを簡単におさらいします。 その後、テーブル統計を収集・保存するための新しいインフラの詳細を掘り下げてから、この変更が実際にアプリケーションにどのような影響を与えるのかを詳しく見ていきます。 最後に、新しいモデルで可能になったパターンに関する追加の注意点をいくつか紹介し、今回の初期リリースに続く次のフェーズに期待をつなげます。
この記事では、マジックメソッドとしても知られるPythonダンダーメソッドについて簡単に解説します。
ダンダーメソッドは、始めと終わりに2つのアンダースコア（__）が付いているPythonの特殊メソッドです。 このメソッドを使用することで、加算や減算、文字列表現など、組み込みの操作に対するオブジェクトの動作を定義することができます。
よくあるダンダーメソッドには、次が含まれます。
__init__(self, ...)：オブジェクトの作成時に呼び出されます。
%OnNew メソッドに似ています__str__(self)：オブジェクトを文字列として表現するために、 組み込み関数と print によって呼び出されます。__add__(self, other)： 演算子が使用される際に呼び出されます。__len__(self)：オブジェクトの長さを返すために、 組み込み関数によって呼び出されます。InterSystems IRIS の新バージョンに、 Hierarchical Navigable Small World (HNSW) インデックス・アルゴリズムに基づく新しい近似最近傍探索 (ANN) インデックスが搭載されました。こちらは、ベクトル検索 早期アクセスプログラム で入手いただけます。これにより、大規模なベクトルデータセットに対して非常に効率の良い近似最近傍探索が可能となり、クエリパフォーマンスとスケーラビリティが大幅に向上しました。
HNSW アルゴリズムは、グラフベース構造を利用して高次元データのベクトル検索を最適化するよう設計されており、大規模なベクトル集合における近似近傍探索を高速化します。HNSW によって、レコメンデーションシステム、自然言語処理、その他の機会学習アプリケーションなどすべてにおいて検索時間が大幅に短縮します。
HNSWの主な利点:
• データセットサイズ増加後も、より高速な検索が可能
• 高精度をたもちながら、メモリ使用量を削減
• 既存の IRIS ベクトル検索とのシームレスな統合
最新バージョンは、ベクトル検索 早期アクセスプログラム に参加いただくことで入手いただけます。ご興味のある方は、プログラムページから登録し、新バージョンをダウンロードしてお試しください。
これは InterSystems FAQ サイトの記事です。
新しいインデックスを定義した後、インデックスの再構築が完了する前にクエリを実行するとデータが存在しているにもかかわらず「検索結果0件」や検索結果数が徐々に増えるような状況が発生します。
インデックスを永続クラス定義（またはテーブル定義）に追加しコンパイルすることで今まで使用していたクエリ実行経路が削除され、再度同じクエリを実行するタイミングで新しいインデックス定義を含めた実行経路が作成されるためです。（この時にインデックス再構築が完了していないとインデックスデータが存在しない、または不完全であるため0件や徐々に検索結果数が増えるような状況を起こします。）
これを起こさなために、新しいインデックスの再構築が終了するまでクエリオプティマイザにインデックスを使用させないように指定する方法が用意されています。
※ 2024/8/2： 2024.1以降から利用できる方法を追加しました。
CREATE INDEXのDEFERオプションを使用します（オプションを付けないCREATE INDEX文では、作成時にインデックスの再構築も同時に行われます）。
一意のインデックスにまつわる興味深いパターンが最近持ちあがったので（isc.rest に関する内部ディスカッション）、コミュニティ向けに強調したいと思います。
動機付けのユースケースとして: ツリーを表すクラスがあるとします。各ノードには名前があるため、名前と親ノードでノードを一意にしたいと考えています。 各ルートノードにも一意の名前を持たせます。 この場合の自然な実装は以下のようになります。
ClassExtends%PersistentPropertyAs
}
以上です！
ただし、落とし穴があります。現状のこの実装では、複数のルートノードに同じ名前を付けることができます。 なぜでしょうか？ Parent は必須プロパティでない（また、そうすべきではない）ため、IRIS は null を一意のインデックスの個別の値として処理しないからです。 一部のデータベース（SQL Server など）はそうしていますが、SQL 標準では、それらが誤っていると述べています（出典が必要です。このことについては StackOverflow のどこかで見かけましたが、それは出典になりません。以下にある、これについてとインデックスと制約の違いについての @Dan Pasco のコメントをご覧ください）。
クラスにどのようなインデックスが必要であるのか、それをどのように定義するのかについて理解できたので、 次に、どのように処理するのかについて確認しましょう。
（注意: クラスに変更を適用する場合と同様に、ライブシステムにインデックスを追加する場合にもリスクが伴います。インデックスが入力されているときに、ユーザーがデータにアクセスしたり更新したりすると、クエリ結果が空になったり誤った結果が生じることがあります。また、構築中のインデックスが破損する場合もあります。 ライブシステムでインデックスを定義したり使用したりするには追加の手順があり、それについてはこのセクションで触れていますが、詳細はドキュメントに記載されています。）
新しいインデックスの準備ができたら、SQLオプティマイザが、クエリを実行する上で最も効率的に読み取れるインデックスであると判断するかどうかを確認できます。 プランを確認するために実際にクエリを実行する必要はありません。 クエリがあれば、プランをプログラムで確認することができます。
Set query = 1
Set query(1) = “SELECT SSN,Name FROM Sample.
これは、SQLインデックスに関する2部構成の記事の前半です。
最後に図書館に行った時のことを思い出してください。 通常そこには、分野別（そして作者順と題名順）に整理された本が並び、それぞれの棚には、本の分野を説明したコードが記載された本立てがあります。 特定の分野の本を収集する場合、すべての通路を歩いて一冊ずつ本の表紙を読む代わりに、目的の分野の本棚に直接向かって選ぶことができるでしょう。
SQLインデックスにもこれと同じ機能があります。テーブルの各行にフィールドの値へのクイック参照を提供することで、パフォーマンスを向上させています。
インデックスの設定は、最適なSQLパフォーマンスを得られるようにクラスを準備する際の主なステップの1つです。
この記事では、次のことについて説明します。
この記事では、Sampleスキーマのクラスを参照します。 このスキーマは以下に示すGitHubリポジトリにあります。
クラスの中で配列プロパティを使い、その要素 (キーと値の両方) によってスピーディに検索を実行できると非常に便利な場合があります (EAV モデルの場合は特に重宝します)。
それでは、簡単な例を見てみましょう。
(1NF/2NF/3NF)露 からの引用
行と列で特定される位置には、それぞれアプリケーションドメインの値が 1 つだけあります (それ以外は何もない)。 その目的によって、同じ値がアトミックであったり、なかったりします。 例えば、「4286」という値は、
- 「クレジットカードの PIN コード」を意味するのであれば、アトミックとなります (破損している場合や並び替えられている場合は、使用できません)。
- 単に「連続する番号」であれば、非アトミックとなります (いくつかに分割されていたり、並び替えられていても、値は意味を成します)。
この記事では、文字列や日付、($LB 形式の) 単純なリスト、「list of <...>」、「array of <...>」といったフィールドの型を伴う SQL クエリのパフォーマンスを向上させる標準的な方法にして検証します。
これは InterSystems FAQ サイトの記事です。
永続クラス（＝テーブル）定義に提供される %BuildIndices() メソッドの引数に、インデックスを再構築したい ID の開始値と終了値を指定することにより、その範囲内のインデックスのみが再構築できます。
例えば、Sample.Person クラスにある NameIDX インデックスと ZipCode インデックスを ID=10～20 のみ再構築する場合は、以下のように実行します（ID の範囲は、第5引数、第6引数に指定してます）。
set status = ##class(Sample.Person).%BuildIndices($LB("NameIDX","ZipCode"),1,,1,10,20) $LB() は $ListBuild() 関数で、%BuildIndices() メソッドでは、インデックス名を指定するために使用しています。
インデックスの再構築方法については、ドキュメントもご参照ください。
2018.1 以下はをご参照ください。
これは InterSystems FAQ サイトの記事です
揮発性テーブル（多数のINSERT、DELETEが行われるテーブル）では、ビットマップ・インデックス用ストレージは徐々に効率が低下する可能性があります。
例えば、以下の定義からなるデータが数千件あり、一定期間保持した後 TRUNCATE TABLE で一括削除を行うオペレーションが繰り返し行われているとします。
Class MyWork.MonthData Extends (%Persistent, %Populate)
{
/// 満足度
Property Satisfaction As %String(VALUELIST = ",満足,やや満足,やや不満,不満,");
/// 年齢
Property Age As %Integer(MAXVAL = 70, MINVAL = 20);
Index AgeIdx On Age [ Type = bitmap ];
}INSERT によってできたビットマップ・インデックスのストレージのイメージ（一部）は以下の通りです。
【INSERT時】
^MyWork.MonthDataI("AgeIdx",20,1) = $zwc(401,120,4,75,102,10,＜省略＞ 958)/*$bit(5,76,103,107・・・
^MyWork.MonthDataI("AgeIdx",21,1) = $zwc(407,121,29,178,251,2＜省略＞,732,772,898,960)/*$bit(3・・・
^MyWork.MonthDataI("AgeIdx",22,1) = $zwc(402,96,5,57,74,164,＜省略＞,0,4)/*$bit(20,63,77,92,10・・・
^MyWork.MonthDataI("AgeIdx",23,1) = $zwc(133,116)_$c(0,0,8,0＜省略＞,64,0,4)/*$bit(20,63,77,92・・・
^MyWork.MonthDataI("AgeIdx",25,1) = $zwc(404,119,105,155,235＜省略＞,947)/*$bit(106,156,236,30・・・
^MyWork.MonthDataI("AgeIdx",26,1) = $zwc(128,119)_$c(0,0,0,2,＜省略＞,0,128)/*$bit(26,80,115,1・・・
＜以下省略＞これはInterSystems FAQ サイトの記事です。
インデックスが複数定義されているクラス／テーブルへ csv 形式等のシーケンシャルファイルから大量データをデータベースに登録する際、推奨される登録方法として、データ登録時インデックスを生成させず、登録完了後に一括でインデックスを生成する 方法があります。
この方法は、新規に大量のレコードを一括登録する際に最も有効な手段となります。
＜メモ＞
大量のデータを追加登録する際には、既存のデータ量と新規データ量のバランスにより、この手法が有効でないケースもあります。その場合は、インデックスの再構築を範囲指定で行うこともできます。
説明に使用するクラス定義例は以下の通りです。
Class ISJ.QL2 Extends %Persistent
{
Property Name As %String;
Property Title As %String;
Property Sex As %String;
Property Company As %String;
Property Phone As %String;
Property City As %String;
Property State As %String;
Property Zip As %String;
Index NameIndex On Name;
Index CompanyIndex On Company;
Index PhoneIndex On Phone;
}これはInterSystems FAQ サイトの記事です。
テーブルチューニングを行った際に、フィールドに値がほとんど登録されていない（Null）場合や、特定の値がほとんどを占める場合、その値を[外れ値] として除外して選択性計算を行います。 また、外れ値が全レコードの何 % を占めているかの値は [外れ値の選択性] として記録されます。
InterSystems 製品のクエリオプティマイザは、選択性数値とエクステントサイズを使用してクエリの経路を決定しますが、クラスクエリ、埋め込み SQL に使用しているクエリに外れ値が含まれる場合は、外れ値の選択性が自動的に考慮され、インデックスの使用有無を決定しています。
ダイナミック SQL 、ODBC／JDBC 経由でのクエリについては、外れ値が Null である場合、自動的に外れ値の選択性が考慮されますが、Null 以外の特定の値が外れ値に検出される場合は、明示的に指示を与えるまで考慮しません。
詳細は、ドキュメント（異常値に対する述語条件【IRIS】／）をご参照ください。
SAMPLES ネームスペースの Sample.
Cachéデータベースのオブジェクトおよびリレーショナルデータモデルは、標準、ビットマップ 、ビットスライスの3種類のインデックスをサポートします。 これら3つのネイティブタイプに加えて、開発者は独自のカスタムタイプのインデックスを宣言し、バージョン2013.1以降の任意のクラスで使用できます。 たとえば、iFindテキストインデックスは、そのメカニズムを使用しています。
カスタムインデックスタイプは、挿入、更新、削除を実行するための%Library.FunctionalIndexインターフェースのメソッドを実装するクラスです。 新しいインデックスを宣言するときに、そのようなクラスをインデックスタイプとして指定できます。
例：
CustomPackage.CustomIndex クラスは、カスタムインデックスを実装するまさにそのクラスです。
たとえば、ハッカソン中に私たちのチーム（Andrey Rechitsky 、 Aleksander Pogrebnikov、そして）が開発した空間データのクワッドツリーベースのインデックスの小さなプロトタイプを分析してみましょう。
アプリケーションに、効率的に検索したいフリーテキストを含むフィールドがありますか？これまで複数の方法を試してみたものの、顧客が要求するパフォーマンスを満たせなかった経験はありませんか？私は変わった手段を使ってあらゆる問題を解決できると思っていませんか。もうご存じですよね。私ができるのは、パフォーマンス低下に対処する優れたソリューションを提供することです。
いつものように、要約版が必要な場合は記事の最後まで飛ばしてください。ただ、それだと私はがっかりしてしまいますが。
最近の（2015.1以降の）バージョンのCaché/Ensemble/HealthShareのSAMPLESネームスペースでSample.Companyのバージョンを開くと、擬似ランダムに生成されたテキストであるMissionフィールドが表示されます。このテキストフィールドを検索してみましょう。 私はこの演習のために約256,246社データを生成しましたが、ご自身で必要な数の会社を生成してから同じ手順に従ってください。例えば、次のクエリを実行するとしましょう。
SELECT * FROM Sample.Company WHERE Mission LIKE ‘% agile %’
これはかなり合理的なクエリですが、どのように実行されるのでしょうか？
前のパート（1、）では、ツリーとしてのグローバルを話題に取り上げました。 この記事では、それらを疎な配列と見なします。
疎な配列は、ほとんどの値が同一であると想定される配列の種類です。
疎な配列は実際には非常に大きいため、同一の要素でメモリを占有することには意味がありません。 したがって、疎な配列を整理し、重複した値の格納にメモリが浪費されないようにすることには意味があります。
疎な配列は、、など一部のプログラミング言語では言語の一部になっています。 他の言語では、疎な配列を使用できるようにする特別なライブラリが存在します。 C++の場合は、などがあります。
次の理由により、グローバルは疎な配列を実装するのに適した候補であると言えます。
Set ^a(1, 2, 3)=5
Write ^a(1, 2, 3)