パフォーマンスタグは、ソフトウェアのパフォーマンスの問題と、パフォーマンスの問題を解決および監視するためのベストプラクティスに関する投稿をグループ化します。
InterSystems IRIS の新バージョンに、 Hierarchical Navigable Small World (HNSW) インデックス・アルゴリズムに基づく新しい近似最近傍探索 (ANN) インデックスが搭載されました。こちらは、ベクトル検索 早期アクセスプログラム で入手いただけます。これにより、大規模なベクトルデータセットに対して非常に効率の良い近似最近傍探索が可能となり、クエリパフォーマンスとスケーラビリティが大幅に向上しました。
HNSW アルゴリズムは、グラフベース構造を利用して高次元データのベクトル検索を最適化するよう設計されており、大規模なベクトル集合における近似近傍探索を高速化します。HNSW によって、レコメンデーションシステム、自然言語処理、その他の機会学習アプリケーションなどすべてにおいて検索時間が大幅に短縮します。
HNSWの主な利点:
• データセットサイズ増加後も、より高速な検索が可能
• 高精度をたもちながら、メモリ使用量を削減
• 既存の IRIS ベクトル検索とのシームレスな統合
開発者の皆さん、こんにちは。
（2024/5/30：6月の日時、ウェビナー内容を更新しました）
InterSystems IRIS、InterSystems IRIS for Healthの新バージョン2024.1がリリースされました。
様々な機能の追加や実験的機能としての追加が行われましたが、その中から以下3種類の内容についてウェビナーを開催します！📣
✅4月23日（火）13時半～14時：IRIS 2024.1の管理用Webサーバ（PWS）廃止に備えて
YouTube公開しました👉https://youtu.be/bVwWZt1oNws?list=PLzSN_5VbNaxCeC_ibw2l-xneMCwCVf-Or
✅5月30日（木）13時半～14時：ベクトル検索機能のご紹介
YouTube公開しました👉https://youtu.be/v0G7K2et_Yk?list=PLzSN_5VbNaxB39_H2QMMEG_EsNEFc0ASz
✅6月25日（火）13時半～14時：FHIR新機能のご紹介～2024.1～
オンデマンド配信はこちら👉https://event.on24.com/wcc/r/4597704/ADA161B6446E6BA01623C875CF596FD0
（資料PDFもオンデマンド配信画面よりダウンロードいただけます）
InterSystems IRIS 製品には、便利なツール ^SystemPerformance (Caché / Ensemble 時代は ^pButtons と呼ばれていました) があり、データベースのパフォーマンス情報を HTML 形式で出力してくれます。 IRIS for Windows で ^SystemPerformance を実行すると、 InterSystems 独自のパフォーマンスログ mgstat と Windows パフォーマンスログの両方を含んだ HTML が生成されます。
Caché と InterSystems IRIS データベースの整合性は、システム障害から完全に保護されてはいますが、物理ストレージデバイスが保管しているデータは、デバイスの障害によって破損してしまいます。 そのため、多くのサイトでは、データベースの整合性チェックを定期的に実行するように選択しており、特に特定のバックアップが災害時に信頼できるかどうかを検証するためにバックアップが行われています。 システム管理者がストレージの破損を伴う災害に対応するために、整合性チェックも緊急に必要となる場合もあります。 整合性チェックはチェックされているグローバルの各ブロック（すでにバッファーにない場合）を、グローバル構造で指示された順序で読み取る必要があります。 これには膨大な時間がかかりますが、整合性チェックは、ストレージサブシステムが維持できる限り高速に読み取ることができます。 一部の状況においては、できる限り迅速に結果を取得するために、そのように実行することが望ましい場合がありますが、 他の状況においては、ストレージサブシステムの帯域幅の過剰な消費を避けるために、整合性チェックをより保守的に行う必要があります。
YASPEはYAPE(Yet Another pButtons Extractor)の後継機種です。YASPEは、メンテナンスと拡張を容易にするために、多くの内部変更を行い、一から書き直しました。
YASPEの機能は以下の通りです。
YASPEはPythonで書かれています。ソースコードはGitHubで公開されており、Dockerコンテナ用には以下で公開されています。
これは InterSystems FAQ サイトの記事です。
InterSystems IRIS Data Platform（以下IRISと表記）ではマルチモデルのサポートにより、データに対して様々なアクセス手法を使用することができます。
主だったアクセス手法としてダイレクトアクセス、SQLアクセス、オブジェクトアクセスがあります。
ダイレクトアクセス は、IRISのネイティブ構造であるグローバルと呼ばれるキーバリュー型のデータに直接アクセスする方法です。
SQLアクセス は、リレーショナルデータベースシステムにアクセスするための標準言語であるSQLを使用してデータにアクセスする方法です。
オブジェクトアクセス は、オブジェクト指向言語でオブジェクトを操作するための表記法として幅広く利用されるドット記法を使用してデータにアクセスする方法です。
ダイレクトアクセスとSQLアクセスおよびオブジェクトアクセスでは、処理の抽象度が異なります。
抽象度が高くなるに伴い、内部的な処理のオーバヘッドが増加するため、単純な1スレッド単位でのアクセススピードの速さについては、ダイレクトアクセスが、SQLアクセスとオブジェクトアクセスに比較して速い場合が多いです。
しかしながら、今後SQLアクセスに関してより高速に処理できるよう様々な開発が進行中です。
これは InterSystems FAQ サイトの記事です。
Question:
IRIS Data Platformは大量のトラフィック処理に耐えられますか?
Answer:
IRIS Data Platformは他のデータベースシステムに比較してデータの処理スピードおよび処理能力の面で優れています。
ESGという外部機関が実際に他社データベース製品とのベンチマークテストを実施した結果に関するレポートを公表しています。
またウルシステムズ社による検証結果も公開されています。
ご参考いただければ幸いです。
この短い記事では、マシンにPythonをセットアップしなくて済むように、dockerコンテナでYapeを実行する方法について説明します。
このシリーズの前回の記事からしばらく時間が経っているため、簡単に振り返ってみましょう。
まず、matplotlibで基本的なグラフを作成する方法について話しました。 そして、bokehを使った動的グラフについて紹介しました。 最後にパート3では、monlblデータを使ったヒートマップの生成について説明しました。
フィードバックをさまざまなチャンネルを通じて受け取りましたが、これらを実行するための環境をセットアップするのが困難であるという、共通したテーマが見られました。 そこで、それを少しでも簡単に行えるよう、Murrayと協力して、Murrayの優れたYapeツール用のDockerfileを作成してみることにしました。 GitHubページ
もちろん、これを行うには、マシンにdockerがインストールされている必要があります。
公式のPythonイメージに基づく、どちらかと言えば単純なdocker定義:
FROM python:3
WORKDIR .
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
これまでに何度もコードカバレッジとコードのパフォーマンス最適化について説明してきたため、ほとんどの方はすでにSYS.MONLBLユーティリティについてご存知かと思います。 コードを視覚的に見る方が通常は、純粋な数値を見るよりもはるかに直感的に理解できます。これが、このシリーズの記事の大きなポイントです。 今回は、Pythonとそのツールから少し離れて、^%SYS.MONLBLレポートからヒートマップを生成する方法を探りたいと思います。
簡単に言うと、ヒートマップは特定の値を色で表現してデータの要約を得ることに特化した視覚化ツールです。 このケースでは、データはコード行であり、コード行に掛けられた時間が色にマッピングされます。
行ごとに監視するモニターの実行については、ドキュメントをご覧ください。 つまり、分析の完全な出力をCSVファイルとして操作します。 分析しようとしているコードのソースコードが実際にあれば、はるかに便利であるため、 kフラグ（ソースを保持）を使ってコードをコンパイルするようにしてください。
ターゲット出力として、準備されたhtmlファイルを使用することにします。 これには、非常に基本的なレイアウトと、最終的な色付けを行うための小さなJavaScript関数だけが含まれます。
先週のディスカッションでは、1つのファイルのデータ入力に基づく単純なグラフを作成しました。 ご存知のように、解析して相関付けるデータファイルが複数あることがあります。 そこで今週は、perfmonデータを追加して読み込み、それを同じグラフにプロットする方法について学習しましょう。 生成したグラフをレポートやWebページで使用する可能性があるため、生成したグラフのエクスポート方法についても説明します。
標準のpButtonsレポートから抽出されたperfmonデータは、少し独特なデータ形式です。 一見すると、かなり単純なCSVファイルで、 最初の行には列のヘッダーがあり、それ以降の行にはデータポイントが含まれています。 ただし、ここでの目的のために、値エントリーを囲む引用符をどうにかする必要があります。 標準的なアプローチを使用してファイルをPythonに解析すると、文字列オブジェクトの列ができてしまい、うまくグラフ化できません。
InterSystemsは最近、HL7バージョン2の相互運用性に焦点を当てた、IRIS for Health 2020.1のパフォーマンスとスケーラビリティのベンチマークを完了しました。 この記事では、さまざまなワークロードで観察されたスループットを説明し、IRIS for HealthをHL7v2メッセージングの相互運用性エンジンとして使用しているシステムの一般的な構成とサイジングのガイドラインを提供します。
この連載の第1回では、リレーショナルデータベースにおけるEAV（Entity-Attribute-Value）モデルを取り上げ、テーブルにエンティティ、属性、および値を保存することのメリットとデメリットについて確認しました。 このアプローチには柔軟性という点でメリットがあるにもかかわらず、特にデータの論理構造と物理ストレージの基本的な不一致などによりさまざまな問題が引き起こされるという深刻なデメリットがあります。
こういった問題を解決するために、階層情報の保存向けに最適化されたグローバル変数を、EAVアプローチが通常処理するタスクに使用できるかどうかを確認することにしました。
パート1では、オンラインストア向けのカタログをテーブルを使って作成し、その後で1つのグローバル変数のみで作成しました。 それでは、複数のグローバル変数で同じ構造を実装してみることにしましょう。
最初のグローバル変数^catalogには、ディレクトリ構造を保存します。 2つ目のグローバル変数^goodには、店の商品を保存します。 ^indexグローバルには、店のインデックスを保存します。 プロパティは階層的なカタログに関連付けられているため、プロパティ用の個別のグローバル変数は作成しません。
この連載の最初の記事では、リレーショナルデータベースのEAV（Entity–Attribute–Value）モデルを見て、それがどのように使用されて、何に役立つのかを確認しましょう。 その上で、EAVモデルの概念とグローバル変数と比較します。
原則として検索する必要のある、フィールド数、または階層的にネストされたフィールドの数が不明なオブジェクトがある場合があります。
たとえば、多様な商品群を扱うオンラインストアを考えてみましょう。 商品群ごとに固有の一意のプロパティセットがあり、共通のプロパティもあります。 たとえば、SSDとHDDドライブには共通の「capacity」プロパティがありますが、SSDには「Endurance, TBW」、HDDには「average head positioning time」という一意のプロパティもあります。
場合によっては、同じ商品でも別のメーカーが製造した場合には、それぞれに一意のプロパティが存在します。
では、50種の商品群を販売するオンラインストアがあるとしましょう。 各商品群には、数値またはテキストの固有のプロパティが5つあります。
まずはこの記事で手短にこの疑問に回答します。 この連載のパート2には、pButtonsから抽出されたパフォーマンスデータのグラフを含めました。 pButtonsの.htmlファイルからmgstatなどのメトリックを抽出してExcelで簡単にグラフ作成する方法として、カット＆ペーストよりも素早く行える方法がないか、オフラインで尋ねられました。
pButtonsは、収集したデータをWRCに送信して確認しやすくするために、そのデータを1つのhtmlファイルにコンパイルするのですが、 特に24時間などの長い収集時間で実行されるpButtonsの場合は、mgstat、vmstatなどの時間ベースのデータをグラフィック表示にして確認できれば、トレンドやパターンが見やすくなります。
これは InterSystems FAQ サイトの記事です。
InterSystems 製品には、テーブルのコンテンツに関する統計を収集し、クエリの最適化に役立てる「テーブルチューニング機能」があります。
設定方法は、以下のドキュメントをご参照ください。
ターミナルでは次のコマンドを実行します。
do$SYSTEM.SQL.Stats.Table.GatherTableStats("スキーマ名.テーブル名",1,1)
2021.1以前のバージョンでは以下メソッドを利用します。
Do$system.SQL.TuneTable("スキーマ名.テーブル名",1,1)
また、以下の資料もご参照ください。
1) パフォーマンス調査の基礎知識として必要なグローバル構造の解説やSQLの動作の仕組みからクエリプランの見方の解説
2) パフォーマンスチューニングの例（P13～）
3) ビットマップ・インデックスの圧縮やオプティマイザ・ヒントなど、Caché SQLのパフォーマンスを最大限に引き出すための情報について
これは InterSystems FAQ サイトの記事です。
<STORE> エラーは サーバ上のプロセスが使用しているプロセス個別メモリ容量が上限に達した場合に発生します。
このメモリはオブジェクトを開いたり、ローカル変数を使用することで消費されるものとなります。
このエラーは サーバ上のプロセスでメモリを大量に使用した場合に発生します。
Caché バージョン2012.2以降、プロセス個別のメモリ容量の最大値が大幅に拡張されました（約2TB）。
この変更により、ローカル変数の使用領域を大幅に増やすことができるようになったため 特別な状況が発生しない限り（プログラムのバグにより大量のローカル変数を作成し続ける等） エラーを回避できるようになりました。
但し、このためのメモリ領域は、プログラムが動作するハードウェアが提供する資源の一つですので物理的な制限は当然あります。
システム全体の資源管理を念頭に置き慎重な使用をお勧めします。
設定値詳細については以下ドキュメントをご参照ください。
InterSystems および Intel は先日、InterSystems IRIS を「Cascade Late」としても知られる第 2 世代 Intel® Xeon® スケーラブルプロセッサおよび Intel® Optane™ DC パーシステントメモリ（DCPMM）と組み合わせて一連のベンチマークを実施しました。 さまざまなワークロード設定とサーバー構成で、Intel の最新のサーバーテクノロジーを使用した InterSystems IRIS のパフォーマンスとスケーラビリティ機能を実証するのがこのベンチマークの目的です。 このレポートには、さまざまなベンチマークの結果とともに、Intel DCPMM と InterSystems IRIS のユースケースが 3 つ示されています。
このツールは、データベース内からランダム読み出し入力/出力（IO）を生成するために使用されます。 このツールの目的は、目標IOPSを達成し、許容範囲内のディスク応答時間の維持を確保するために、可能な限り多くのジョブを駆動することです。 IOテストから収集された結果は、IOサブシステムに基づいて構成ごとに異なります。 これらのテストを実行する前に、対応するオペレーティングシステムとストレージレベルの監視が、今後の分析のためにIOパフォーマンスの測定データーを保存するように設定されていることを確認してください。
*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。
稼働後のシステムで、お客様から「パフォーマンスが思ったように出ない」と問い合わせを受けることが良くあります。漠然とした「遅い」状況をどのように解決すればいいのでしょう？
パフォーマンスに困ったときにどこに着目し、どのツールで調べていくか、お客様から日々ご相談をいただくカスタマーサポートから、解決に向かうアプローチの「イロハ」をご紹介します。
この他にも、開発者コミュニティでは、パフォーマンスに役立つ技術情報を公開しています。
こちらも合わせてご覧ください。
注記（2019年6月）: 多くの変更がありました。最新の情報についてはこちらをご覧ください。 注記（2018年9月）: この記事が最初に投稿されて以来、多くの変更がありました。Dockerコンテナバージョンを使用することをお勧めします。コンテナとして実行するためのプロジェクトと説明は、以前と同じGitHubの公開場所に残っていますので、ダウンロードして実行し、必要に応じて変更してください。
これは InterSystems FAQ サイトの記事です。
ローカル変数の容量は、プロセスに許可する最大メモリ割り当て容量によって制限されます。
この値は、システム構成パラメータの bbsiz で設定します（設定方法は記事の後半にあります）。
既定値は、1プロセスあたり、262,144 KB です。
※IRIS 2022.1 以降は、既定値が -1(最大値：制限なし) になりました。
※Caché/Ensemble 2012.1以前では 16,384 KB でした。
値は 256KB からスタートし、プロセスがより大きな領域を必要とする場合は、bbsiz で設定した値まで拡張します。
（バージョン2012.1以前では 128KB～49,536KB の範囲で設定できます。）
この値を超えるようなローカル変数の使用があると、 エラーが発生します。
現在のプロセスに残っている使用可能なメモリ量は、$STORAGE 変数で確認できます（バイト単位）。
詳細は以下ドキュメントページをご参照ください。
$STORAGEについて【IRIS】
$STORAGEについて
インターシステムズ製品のプロセス・メモリについて
一般的に多量のローカル変数を使うと、システムが稼動するために必要なメモリ量も増加します。
大規模システムの場合には、そのことが原因でメモリ不足が発生することもあり得るため注意が必要です。
これは InterSystems FAQ サイトの記事です。
InterSystems Data Platformは、データベースキャッシュやルーチンキャッシュなどの共有メモリを、起動時に割り当てます。
バージョン2007.1以降をWindows上で動作させる際、Windows特有の共有メモリに関する問題が生じることが判明しています。
詳細については、以下の技術資料をご参照ください。
また、以下の記事もあわせてご覧ください。
コンソールログに "Failed to allocate xxxMB shared memory using large pages..." のエラーメッセージが出ているとき
クラスにどのようなインデックスが必要であるのか、それをどのように定義するのかについて理解できたので、 次に、どのように処理するのかについて確認しましょう。
（注意: クラスに変更を適用する場合と同様に、ライブシステムにインデックスを追加する場合にもリスクが伴います。インデックスが入力されているときに、ユーザーがデータにアクセスしたり更新したりすると、クエリ結果が空になったり誤った結果が生じることがあります。また、構築中のインデックスが破損する場合もあります。 ライブシステムでインデックスを定義したり使用したりするには追加の手順があり、それについてはこのセクションで触れていますが、詳細はドキュメントに記載されています。）
新しいインデックスの準備ができたら、SQLオプティマイザが、クエリを実行する上で最も効率的に読み取れるインデックスであると判断するかどうかを確認できます。 プランを確認するために実際にクエリを実行する必要はありません。 クエリがあれば、プランをプログラムで確認することができます。
Set query = 1
Set query(1) = “SELECT SSN,Name FROM Sample.Person WHERE Office_State = 'MA'”
これは、SQLインデックスに関する2部構成の記事の前半です。
最後に図書館に行った時のことを思い出してください。 通常そこには、分野別（そして作者順と題名順）に整理された本が並び、それぞれの棚には、本の分野を説明したコードが記載された本立てがあります。 特定の分野の本を収集する場合、すべての通路を歩いて一冊ずつ本の表紙を読む代わりに、目的の分野の本棚に直接向かって選ぶことができるでしょう。
SQLインデックスにもこれと同じ機能があります。テーブルの各行にフィールドの値へのクイック参照を提供することで、パフォーマンスを向上させています。
インデックスの設定は、最適なSQLパフォーマンスを得られるようにクラスを準備する際の主なステップの1つです。
この記事では、次のことについて説明します。
この記事では、Sampleスキーマのクラスを参照します。 このスキーマは以下に示すGitHubリポジトリにあります。また、CachéとEnsembleでインストールされるSamplesネームスペースでも提供されています。
数年ほど前、Caché Foundationsの講座（現「Developing Using InterSystems Objects and SQL」）において、%UnitTestフレームワークの基礎を講義していたことがあります。 その時、ある受講者から、ユニットテストを実行している間に、パフォーマンス統計を収集できるかどうかを尋ねられました。 それから数週間後、この質問に答えるために、%UnitTestの例にコードを追加したのですが、 ようやく、このコミュニティでも共有することにしました。
クラスの中で配列プロパティを使い、その要素 (キーと値の両方) によってスピーディに検索を実行できると非常に便利な場合があります (EAV モデルの場合は特に重宝します)。
それでは、簡単な例を見てみましょう。
(1NF/2NF/3NF)露 からの引用
行と列で特定される位置には、それぞれアプリケーションドメインの値が 1 つだけあります (それ以外は何もない)。 その目的によって、同じ値がアトミックであったり、なかったりします。 例えば、「4286」という値は、
- 「クレジットカードの PIN コード」を意味するのであれば、アトミックとなります (破損している場合や並び替えられている場合は、使用できません)。
- 単に「連続する番号」であれば、非アトミックとなります (いくつかに分割されていたり、並び替えられていても、値は意味を成します)。
この記事では、文字列や日付、($LB 形式の) 単純なリスト、「list of <...>」、「array of <...>」といったフィールドの型を伴う SQL クエリのパフォーマンスを向上させる標準的な方法にして検証します。
これは InterSystems FAQ サイトの記事です。
データベースキャッシュおよびルーチンキャッシュをモニターし、最適値を調べる方法をご紹介します。
(1) データベースキャッシュ
現状の設定値で問題ないかは、^GLOSTAT ユーティリティ のCache Efficency値(キャッシュ効率)でモニターします。
Cache Efficiency 値は大きければ大きいほど良いですが、目安として100 以上であれば、設定サイズは問題ありません。
実行例)
これは InterSystems FAQ サイトの記事です。
システムのパフォーマンスが低下した場合、OSやインターシステムズ製品の様々なツールを使用して情報収集を行い
”通常時と比較して、どこがどの程度変わっているか”
を確認することで、問題のある箇所を特定できます。
（逆に、通常時の状況が不明な場合、パフォーマンス問題点の切り分けが非常に困難となる場合もあります。）
いざ という時に備え、通常時のパフォーマンスを確認することは、大変重要な情報となります。
収集情報詳細は、以下のドキュメントをご参照ください。
ガイド内でご紹介しているサンプルは、https://github.com/Intersystems-jp/performance-sample からダウンロードいただけます。
パフォーマンス低下時の情報収集ツールについては、以下の関連FAQトピックをご参照ください。