近頃、LLM や AI などに関する話題で非常ににぎわっています。 ベクトルデータベースもそれなりに関わっており、IRIS 以外では、世界中で多様なサポートがすでに実現されています。

なぜベクトルなのでしょうか？

• 類似検索: ベクトルでは、データベース内で最も類似する項目やドキュメントを検索するなど、効率的な類似検索が可能です。 従来のリレーショナルデータベースは完全一致検索向けに設計されているため、画像やテキストの類似検索といったタスクには向いていません。
• 柔軟性: ベクトル表現には汎用性があり、テキスト（Word2Vec、BERT などの埋め込み経由）や画像（ディープラーニングモデル経由）などの様々なデータタイプから導き出すことができます。
• クロスモーダル検索: ベクトルでは、様々なデータモダリティでの検索が可能です。 たとえば、画像のベクトル表現を基に、マルチモーダルデータベースで類似する画像や関連するテキストを検索できます。

理由は他にも多数あります。

そこで、この Python コンテストでは、このサポートを実装してみることにしました。 残念ながら時間内に完成させることはできませんでしたが、その理由を以下で説明します。

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

IRIS/IRIS for Health2024.1以降のバージョンのSQLで、JSON_TABLE関数がサポートされています。
【ドキュメント】JSON_TABLE(SQL)

これを使用することにより、JSON形式データを表形式で取得することが出来ます。

【例】郵便番号情報を外部から取得し、表形式にマッピングする。
(取得データ(JSON))

この記事では、2023年3月1日～31日の期間に開催された「技術文書ライティングコンテスト：InterSystems IRISチュートリアル」に応募された24作品の中から、Heloisa Paivaさんが投稿されたシンプルですぐに試せる記事をご紹介します。

はじめに

このチュートリアルは、テストやチュートリアル用のサンプル作成など、あらゆる目的でサンプルデータベースを作成するための、私が見つけた最も簡単な方法についての簡単なチュートリアルです。

ネームスペースの作成

1. ターミナルを開きます。
2. 次のコマンドを実行します。 "Do $SYSTEM.SQL.Shell()" （※または :sql の入力でもSQLシェルに切り替えできます）
3. "CREATE DATABASE " コマンドを実行します。実行時、作成したいネームスペース名をコマンドの引数に指定します。（TESTネームスペースを作成する例：CREATE DATABASE TEST）

これで、管理ポータルから新しいネームスペースを作成するより簡単で素早い方法でネームスペースを作成できます。

古くなった MUMPS アプリケーションの新たな生命を吹き込みたいとお考えでしたら、以下にご紹介するステップを実行すれば、グローバルをクラスにマッピングし、美しいデータを Object や SQL に公開できます。

今回ご紹介する例には、パート 1 ではカバーしなかった内容を 4 つないし 5 つ程度盛り込んでいます。

その後は親子マッピングの例を紹介して完結となります。それを修得したらマッピングはもう完璧でしょう。

前回と同じ免責事項: これらの記事を読んでもグローバルがよく理解できないという方は、WRC (Support@InterSystems.com) までメールでお問い合わせください。喜んでサポートさせていただきます。

グローバルをクラスにマッピングするステップ。

古くなった MUMPS アプリケーションに新たな生命を吹き込みたいとお考えですか？　以下にご紹介するステップを実行すれば、グローバルをクラスにマッピングし、美しいデータを Object や SQL に公開できます。

上の内容に馴染みが無い方は、以下の記事を初めからお読みください。

グローバルをマッピングする技術 1

グローバルをマッピングする技術 2

この記事の例では、典型的な親子構造をマッピングする方法をお見せします。

前回と同じ免責事項: これらの記事を読んでもグローバルがよく理解できないという方は、WRC (Support@InterSystems.com) までメールでお問い合わせください。喜んでサポートさせていただきます。

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

(1NF/2NF/3NF)^露 からの引用

行と列で特定される位置には、それぞれアプリケーションドメインの値が 1 つだけあります (それ以外は何もない)。
その目的によって、同じ値がアトミックであったり、なかったりします。 例えば、「4286」という値は、

• 「クレジットカードの PIN コード」を意味するのであれば、アトミックとなります (破損している場合や並び替えられている場合は、使用できません)。
• 単に「連続する番号」であれば、非アトミックとなります (いくつかに分割されていたり、並び替えられていても、値は意味を成します)。

この記事では、文字列や日付、($LB 形式の) 単純なリスト、「list of <...>」、「array of <...>」といったフィールドの型を伴う SQL クエリのパフォーマンスを向上させる標準的な方法にして検証します。

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

SQLのINSERT/UPDATE/DELETE文で大量のデータを更新する際に、高速化する方法をご紹介します。
以下の2つの手順を実行することで、更新処理のパフォーマンスを向上させることが可能です。

１．INSERT/UPDATE/DELETE時にインデックスを作成せず、あとでまとめて作成する

２．INSERT/UPDATE/DELETE時にジャーナルをOFFにする

１は、%NOINDEX キーワードを指定してインデックスの生成を後でまとめて行うことで、インデックスの構築を抑制しパフォーマンスを向上させる方法です。

クエリ実行例は、以下のようになります。

新しい動的 SQL クラス（%SQL.Statement および %StatementResult）のパフォーマンスは %ResultSet より優れてはいますが、%ResultSet の使用方法をせっかく学習したので、しばらくの間新しい方を使用せずにいましたが、 やっとチートシートを作ったので、新しいコードを書いたり古いコードを書き直す際に役立てています。 皆さんのお役に立てればいいなと思っています。

次に示すのは、私のチートシートの詳細版です。

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

クエリパフォーマンスを左右するクエリプランは、テーブルチューニングを行った結果の統計情報を元に生成されます。

ある環境で期待したプランになったけれど、他の環境では意図したプランにならない場合、（期待したプランとなる）既存環境からテーブル統計情報をエクスポートして別の環境にインポートし、同じ統計情報をもとにしたクエリプランで実行することができます。

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

テーブルチューニングを行った際に、フィールドに値がほとんど登録されていない（Null）場合や、特定の値がほとんどを占める場合、その値を [外れ値] として除外して選択性計算を行います。 また、外れ値が全レコードの何 % を占めているかの値は [外れ値の選択性] として記録されます。

InterSystems 製品のクエリオプティマイザは、選択性数値とエクステントサイズを使用してクエリの経路を決定しますが、クラスクエリ、埋め込み SQL に使用しているクエリに外れ値が含まれる場合は、外れ値の選択性が自動的に考慮され、インデックスの使用有無を決定しています。

より産業向けのグローバルストレージスキーム

この連載の第1回では、リレーショナルデータベースにおけるEAV（Entity-Attribute-Value）モデルを取り上げ、テーブルにエンティティ、属性、および値を保存することのメリットとデメリットについて確認しました。 このアプローチには柔軟性という点でメリットがあるにもかかわらず、特にデータの論理構造と物理ストレージの基本的な不一致などによりさまざまな問題が引き起こされるという深刻なデメリットがあります。

こういった問題を解決するために、階層情報の保存向けに最適化されたグローバル変数を、EAVアプローチが通常処理するタスクに使用できるかどうかを確認することにしました。

パート1では、オンラインストア向けのカタログをテーブルを使って作成し、その後で1つのグローバル変数のみで作成しました。 それでは、複数のグローバル変数で同じ構造を実装してみることにしましょう。

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