みなさんこんにちは！ 今回は、IRIS 2024.1で実験的機能として実装されたVector Search (ベクトル検索)について紹介します。ベクトル検索は、先日リリースされたIRIS 2024.1の早期アクセスプログラム(EAP)で使用できます。IRIS 2024.1については、こちらの記事をご覧ください。

ベクトル検索でどんなことができるの？

ChatGPTをきっかけに、大規模言語モデル(LLM)や生成AIに興味を持たれている方が増えていると思います。開発者の方々の中には、中はどうなっているのか気になっている方も多いのではないでしょうか。実は、LLMや生成AIの仕組みを理解したいと思えば、ベクトルの理解は不可欠な要素となります。

ベクトルとは？

ベクトルは、高校の数学で習う「あの」ベクトルのことです。が、今回は、複数の数値をまとめて扱うデータ型であるという理解で十分です。例えば、

本稿について

本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。
Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。

メモリ自動設定をやめる

パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。

更新: 2020年11月20日 バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。

搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。

これは InterSystems FAQ サイトの記事です。

タイムアウトを無効にするためには、DSNの設定でクエリタイムアウト無効に設定します。

Windowsコントロールパネル > [管理ツール] > [データソース（ODBC）] > [システムDSN]の構成

で クエリタイムアウト無効 にチェックを入れますと、タイムアウトは無効になります。

アプリケーション側で変更する場合は、ODBC APIレベルで設定することが可能です。

ODBCのSQLSetStmtAttr関数をコールする際に、SQL_ATTR_QUERY_TIMEOUT属性を設定してから、データソースに接続してください。

これはInterSystems FAQ サイトの記事です。

DATE 型は InterSystems 製品のデータ型の %Date に、TIME 型は %Time に対応しています。

%Date は内部日付（特殊変数 $Horolog のカンマ区切り1番目）、%Time は内部時刻（$Horolog のカンマ区切り2番目）を登録するタイプであるため、サーバ側ロジックでは表示モードを切り替えない限り、内部（論理）形式の値が使用されます。
サーバ側ロジックで内部日付・時刻の表示形式を変更する方法は、操作方法により異なります。

以降の実行例では、Sample.Person テーブルを使用して解説します。
（コマンド実行例は SELECT 文で記載していますが、更新文に対しても同様に記述できます。）

IRISをアップグレードすると、SQLクエリオプティマイザの機能向上により、旧バージョンとは異なるクエリプランによるクエリ実行コード(クエリキャッシュ)が作成される場合があります。
ほとんどの場合はパフォーマンスが向上するのですが、稀にパフォーマンスが低下するケースもあります。

・アップグレードによりオプティマイザが改善しているとはいえ、中には遅くなるクエリがあるのではないか？
・予期しないSQLの問題が起きるのではないか？
・アップグレード後に全てのクエリパターンをテストするには時間と労力がかかりすぎる

このように、機能向上よりも安定性を優先して「今までのプランのまま実行したい」というご要望もあることでしょう。
こちらの記事では、そのようなお客様への解決策をご案内します。

これは InterSystems FAQ サイトの記事です。

SQLゲートウェイの接続設定は管理ポータルで作成できますが、プログラムでも作成が可能です。

管理ポータル：
[システム管理] > [構成] > [接続性] > [SQLゲートウェイ接続]

こちらのトピックでは、ODBC/JDBCそれぞれの設定をプログラムで行う方法をご紹介します。

マッピングの例

三連載で 4 記事目を書いてしまったら、これまでのハイライトとして 5 記事目を書かないわけにはいかないでしょう！

注意: 何年か前に Dan Shusman 氏が私に「グローパルのマッピングは芸術だ」と言いました。 そのやり方に正解も不正解もありません。 どのようなマッピングを行うかは、データをどう解釈するかで決まります。 例のごとく、最終的な結論を出す方法は 1 つに限られません。 ここでご紹介する例の中には、同じ型のデータを異なる方法でマッピングする例がいくつかあります。

この記事の最後には、私が長年お客様のために書いてきたマッピングの例をまとめた zip ファイルをご用意しています。 過去 4 つの記事で触れた内容をまとめたハイライトとして、いくつか例を挙げていきたいと思います。 この記事は単なるハイライトですので、過去 4 記事ほどの詳細はカバーいたしません。 不明な点があれば、遠慮なくご連絡ください。もっと詳しく説明させていただきます。

これは InterSystems FAQ サイトの記事です。

IRISには、データ項目の値を実体として持たずに、何らかの演算処理の結果として提供する機能があります。

これを計算プロパティまたは計算フィールドといいます。

計算プロパティを定義するためには、最低限以下の手順を実行します。

プロパティ定義にSqlComputedキーワードを含めます。

プロパティ定義にSqlComputedCodeを含めて、値を算出するための処理ロジックとして含めます。

または、SqlComputedCodeを含めずに、代わりに<プロパティ名>Computationという名前のクラスメソッドを記述します。

以下は、Age（年齢）プロパティを計算プロパティとして定義した例になります。

これは InterSystems FAQ サイトの記事です。

計算プロパティを定義する際に利用可能なキーワードが複数あります。

詳細は、以下をご参照ください。

計算プロパティの定義

実際のこれらのキーワードの関連性は、少々複雑ですので具体的なコードを作成して動作を確認してみます。

以下のようなクラス定義を作成します。(プロパティとインデックス定義のみ表示します)

完全なクラス定義は以下より、ダウンロードできます。

サンプルクラス定義

クラスの中で配列プロパティを使い、その要素 (キーと値の両方) によってスピーディに検索を実行できると非常に便利な場合があります (EAV モデルの場合は特に重宝します)。

それでは、簡単な例を見てみましょう。

Python は世界で最も使用されているプログラミング言語になり（出典: https://www.tiobe.com/tiobe-index/）、SQL はデータベース言語としての道をリードし続けています。 Python と SQL が連携して、SQL だけでは不可能であった新しい機能を提供できれば、素晴らしいと思いませんか？ 結局のところ、Python には 380,000 を超える公開ライブラリがあり（出典: https://pypi.org/）、Python 内で SQL クエリを拡張できる興味深い機能が提供されています。 この記事では、Embedded Python を使用して、InterSystems IRIS データベースに新しい SQL ストアドプロシージャを作成する方法を詳しく説明します。

サンプルとして使用する Python ライブラリ

この記事では、IRIS で SQL を扱う人にとって非常に便利な GeoPy と Chronyk という 2 つのライブラリを使用します。

InterSystems IRIS 2020.1 には、重要なアプリケーションの構築を支援する新機能と機能改善が多数盛り込まれています。 2019.1 から 2020.1 までに行われた多数の大幅なパフォーマンス改善のほかに、最近の SQL の歴史において最も大きな変更点の 1 つであるユニバーサルクエリキャッシュ（UQC）が導入されています。 この記事では、SQL ベースのアプリケーションに対するそのインパクトについて、技術的な観点で詳しく説明しています。

これは、InterSystems FAQ サイトの記事です。

ウィンドウ関数は、結果セットを部分的に切り出した領域に集約関数を適用できるもので、WHERE GROUP BY および HAVING 節が適用された後、SELECT クエリで選択された行に対して作用します。
IRIS/IRIS for Health 2021.1からサポートしています。
サポートされるウィンドウ関数は以下の通りです。

これは InterSystems FAQ サイトの記事です。

日時検索で、TimeStamp型のクエリのパフォーマンスが出ない場合の対処法をご紹介します。

%TimeStamp データ型形式 (yyyy-mm-dd hh:mm:ss.ffff)は、人が読めることを目的とした ODBC 日付形式の文字列として格納されます。
そのため、どうしてもデータサイズが大きくなりクエリの実行に時間がかかってしまいます。
%TimeStamp型のプロパティにインデックスを作成している場合にも、クエリオプティマイザはそのインデックスを優先して最適化するようにはなっておりません。