IRIS 2024.3 で発生する2つの製品障害が確認されました。お使いの環境が該当する場合は、それぞれの解決方法にしたがってご対応いただきますよう、よろしくお願いします。
InterSystemsCachГ©データベースは、すべてのデータ、アプリケーションスクリプトならびにユーザー、ロールおよびセキュリティ構成が保存されるファイルです。 通常、ファイルの名前は cache.dat です。 ドキュメント。
これは、InterSystems FAQサイトの記事です。
質問：
データ容量を見積もる計算式はありますか？
回答：
正確に見積もるための計算式は残念ながらありません。
InterSystems IRIS Data Platformの場合、データ部に関してはデータを全て可変長で格納しますので、各フィールドの平均がどのくらいであるかという目安の数字で平均レコード長を求め、キー部分も同様の計算を行い、必要な容量の推測値を求める必要があります。
インデックス部に関してはキー圧縮されますので、データと同じような上記の計算を行った推測値よりは少なくなることが期待できます。 ただしその圧縮率はデータの特性に大きく影響されますので、どの程度少なくなるかは一概には言えません。
実データのサンプル（例えば、１万件のデータ）をロードし、その時点でのサイズを確認して想定される件数分のデータ容量を推測するというのが現実的な方法となります。
これは InterSystems FAQ サイトの記事です。
永続クラス定義では、データを格納するグローバル変数名を初回クラスコンパイル時に決定しています。
グローバル変数名は、コンパイル後に表示されるストレージ定義（Storage）で確認できます。
例）
開発者の皆さん、こんにちは！
この記事は、2024年7月に開催された「InterSystems Pythonプログラミングコンテスト2024」でエキスパート投票、コミュニティ投票の両方で1位を獲得された @Henry Pereira Pereira さん @José Pereira さん @Henrique Dias Dias さんが開発された sqlzilla について、アプリを動かしてみた感想と、中の構造について @José Pereira さんが投稿された「Text to IRIS with LangChain」の翻訳をご紹介します。
第2回 InterSystems Japan 技術文書ライティングコンテスト 開催！ では、生成AIに関連する記事を投稿いただくと、ボーナスポイントを4点獲得できます📢 @José Pereira さんの記事を💡ヒント💡に皆様の操作体験談、アイデアなどを共有いただければと思います。
開発されたアプリSQLzilla についての概要ですが、Open Exchange の sqlzilla のREADMEに以下のように紹介されています。
「SQLzilla は、Python と AI のパワーを活用して、自然言語の SQL クエリ生成を通じてデータ アクセスを簡素化し、複雑なデータ クエリとプログラミング経験の少ないユーザーとの間のギャップを埋めます。」
Debeziumをご存じでしょうか？
グローバルサミット2023にて、Debeziumを題材としたセッション「Near Real Time Analytics with InterSystems IRIS & Debezium Change Data Capture」がありましたので、ご覧になられた方もおられるかと思います。
ご興味がありましたら、グローバルサミット2023の録画アーカイブをご覧ください。
FAQによると、"dee-BEE-zee-uhm"(ディビジウム..ですかね)と読むそうです。元素周期表のように複数のDB(s)を束ねる、というニュアンスみたいです。
CDC(Change data capture)という分野のソフトウェアです。
外部データベースでの変更を追跡して、IRISに反映したいという要望は、インターオペラビリティ機能導入の動機のひとつになっています。一般的には、定期的にSELECT文のポーリングをおこなって、変更対象となるレコード群(差分。対象が少なければ全件)を外部システムから取得する方法が、お手軽で汎用性も高いですが、タイムスタンプや更新の都度に増加するようなバージョンフィールドが元テーブルに存在しない場合、どうしても、各ポーリング間で重複や見落としがでないように、受信側で工夫する必要があります。また、この方法ではデータの削除を反映することはできませんので、代替案として削除フラグを採用するといったアプリケーションでの対応が必要になります。
CDCは、DBMSのトランザクションログをキャプチャすることで、この課題への解決策を提供しています。DebeziumはRedHatが中心となっているCDCのオープンソースプロジェクトです。
これは InterSystems FAQ サイトの記事です。
以下の状態の時、ReadOnlyでマウントされます。
- データベースの構成設定「読み込み専用でマウント」にチェックをつけている
- データベースマウント時「読み込み専用」のチェックをつけている
- ミラー構成を使用していないのにデータベースにミラー属性がついている
- 詳細は「ミラー・データベースがミラー構成削除後に読み取り専用でマウントされる」をご参照ください。
- データベースファイルが存在するディレクトリを全体をコピーし、そのディレクトリに対してデータベースを作成したとき
これは InterSystems FAQ サイトの記事です。
バージョン2017.2以降から、CREATE TABLE文で作成したテーブル定義のデータを格納するグローバル変数の命名ルールが変わり ^EPgS.D8T6.1 のようなハッシュ化したグローバル変数名が設定されます。（この変更はパフォーマンス向上のために追加されました。）
※ バージョン2017.1以前については、永続クラス定義のルールと同一です。詳細は関連記事「永続クラス定義のデータが格納されるグローバル変数名について」をご参照ください。
以下のテーブル定義を作成すると、同名の永続クラス定義が作成されます。
CREATETABLE Test.Product(
ProductID VARCHAR(10) PRIMARY KEY,
ProductName VARCHAR(50),
Price INTEGER
)永続クラス：Test.Productの定義は以下の通りです。（パラメータ：USEEXTENTSETに1が設定されます）
このフォーメーションは私の GitHub にあり、30 分で csv ファイルと txt ファイルの読み取りと書き込み方法、Postgres を使ったIRIS データベースとリモートデータベースの挿入とアクセス方法、FLASK API の使用方法について説明します。これらすべてに、PEP8 命名規則に従った、Python のみのインターオペラビリティフレームワークを使用します。
このフォーメーションは、ほとんどをコピー＆ペースト操作で実行でき、グローバル演習を行う前に、ステップごとの操作が説明されています。
記事のコメント欄、Teams、またはメール（lucas.enard@intersystems.com）でご質問にお答えします。
このフォーメーションに関するあらゆる点において、ご意見やご感想をお送りいただけると幸いです。
1. Ensemble / Interoperability のフォーメーション
このフォーメーションでは、Python および特に以下を使用した InterSystems のインターオペラビリティフレームワークを学習することを目標としています。
- 本番環境
- メッセージ
- ビジネスオペレーション
- アダプター
- ビジネスプロセス
- ビジネスサービス
- REST サービスと運用
目次:
これは InterSystems FAQ サイトの記事です。
メモ：xxx にはネームスペース名が入ります。
xxxENSTEMPは、プロダクション実行中に作成される一時データが保存されるデータベースです。
^IRIS.Temp.Ens* のグローバルがこのデータベースにマッピングされています。なお、xxxENSTEMPはジャーナルにかかれない設定のデータベースです。
xxxSECONDARYは、プロダクションで使用される資格情報を保存するデータベースです。
^Ens.SecondaryData* のグローバルがこのデータベースにマッピングされています。
注意：InterSystems IRIS for Health、HealthShare ではこれらデータベースは作成されません
詳細は以下ドキュメントをご覧下さい。
InterSystems IRIS の一時プロダクション・データの格納場所
InterSystems IRIS のパスワード資格情報の格納場所
関連する記事もご参照ください。
これは、InterSystems FAQ サイト の記事です。
1つのインスタンスで作成可能なネームスペース数の上限は、2048個になります。
ただし多数のネームスペースを使用するには、それに合わせてメモリの設定が必要になります。使用するメモリの設定については下記の関連トピックご参照ください。
管理ポータルのメモリ関連設定項目について
また1つのインスタンスに作成可能なデータベース数（リモートデータベースを含む）の上限は、15998個になります。
なおライセンスの種類によっては、作成可能な数に制限が設けられています。
詳細については、以下ドキュメントをご参照ください。
ドキュメント：ネームスペースの構成
ドキュメント：ローカル・データベースの構成
開発者のみなさん、こんにちは！
2022年3月9日開催「InterSystems Japan Virtual Summit 2022」のセッション「ストレージの節約手法について」のアーカイブを YouTube に公開いたしました。
（プレイリストはこちら）
データベースの構成要素であるデーターベースファイル、ジャーナルファイルに関するストレージ容量の増大を招く要因とその解決策、そしてこれら要素に関わる新機能についてもご説明します。
ストレージのコスト管理が重要なクラウド環境で特に有用な情報です。
ぜひ動画をご参照ください。
【目次】
00:58 ストレージコスト削減に成功されたお客様事例のご紹介
02:24 ディスクの使用状況を詳しく見る
04:57 ストレージコストの節約（＝ストレージの節約）のための方法
15:44 ジャーナルのコスト削減（＝ストレージの削減）
23:24 今後リリース予定の新機能について
これは、InterSystems FAQサイトの記事です。
システムユーティリティクラス：SYS.Database のクエリ：FreeSpace を利用してディスクの空き容量を任意のタイミングで確認することができます。
IRIS ターミナルで試す方法は以下の通りです（%SYSネームスペースに移動してから実行します）。
zn "%SYS"
set stmt=##class(%SQL.Statement).%New()
set st=stmt.%PrepareClassQuery("SYS.Database","FreeSpace")
set rset=stmt.%Execute()
//全件一括表示
do rset.%Display()出力結果例は以下の通りです。
※コマンド実行例では、全データベースが同じディスクに置かれているので、ディスクの空き容量（DiskFreeSpace）はすべて同じ値が返っています。
これは、InterSystems FAQサイトの記事です。
データベースの空き容量は、システムモニタを使用して監視することができます。
システムモニタは、システム開始時に自動開始され、予め設定された閾値に対してアラートが通知されます。
システムの閾値については以下ドキュメントをご参照ください。
システム・モニタのステータスおよびリソース・メトリック【IRIS】
システム・モニタのステータスおよびリソース・メトリック
データベースの空き容量については、システムデフォルトでは 50 MBを下回る場合にアラートが通知され、メッセージログ（コンソールログ）にアラート（深刻度 2）として記録され、alerts.log ファイルにも出力されます。
データベースの空き容量を任意サイズで監視したい場合、システムモニタに含まれる「アプリケーションモニタ」を利用して設定します。
注意：アプリケーションモニタでは、アラート対象となる情報があってもメッセージログ（コンソールログ）に出力しないため、メール通知／メソッド実行 を使用して通知するように設定します。
例えば、空き容量が 100MB を下回った時にアラートを通知したい場合は、アプリケーションモニタが提供する %Monitor.System.Sample.Freespace（空き容量メトリック）を利用します。
開発者の皆さん、こんにちは！
InterSystems データセットコンテスト の投票結果が発表されました！この記事ではコンテスト受賞者を発表します！
受賞された開発者の皆さん、👏おめでとうございます！🎊
開発者の皆さん、こんにちは！
今週から データセットコンテスト の投票が始まります！
InterSystems IRIS を使い開発されたベストソリューションにぜひ、投票をお願いします！
🔥 投票はこちらから！ 🔥
投票方法については、以下ご参照ください。
開発者の皆さん、こんにちは！
InterSystems IRIS 2021.2 Preview 版 がリリースされました。新しい機能として LOAD DATA があります。
ということで、今回のコンテストでは、この新しい「LOAD DATA」をテストするコンテストにしてみたいと思います！
🏆 InterSystems Datasets Contest 🏆
応募期間: 2021年12月27日～2022年1月9日
💰 賞金総額： $9,450 💰
これは、InterSystems FAQサイトの記事です。
グローバル単位でジャーナルのON/OFF設定を行いたい場合は、グローバルマッピング設定で、
・ジャーナルしたいグローバル ⇒ ジャーナルON(「はい」)のデータベースにマッピング
・ジャーナルしたくないグローバル ⇒ ジャーナルOFF(「いいえ」)のデータベースにマッピング
と、分けることで可能です。 但し、通常のデータベースは、ジャーナルOFF設定であっても、トランザクション中の更新についてはジャーナルファイルに記録されます。
一時グローバルを保存するIRISTEMP/CACHETEMPデータベースは、トランザクション中でもジャーナルファイルに記録されませんので、トランザクションデータもジャーナル記録したくない場合にはこれをマッピング先にすることも可能です。
但し、IRISTEMP/CACHETEMPデータベースは一時データベースであるため、インスタンス再起動でグローバルデータは失われますので注意が必要です。
一時グローバルと IRISTEMP データベース
これは、InterSystems FAQサイトの記事です。
InterSystems製品のデータ（テーブルの行データ、オブジェクトのインスタンスデータ）は、グローバル変数に格納されています。
各グローバルのデータサイズは、管理ポータル>システム>構成>ローカルデータベース>グローバルのページから参照したいグローバルのプロパティをクリックし、表示されるグローバル属性ページ上のサイズ計算ボタンをクリックすることで個別のグローバルのサイズを取得することができます。
ネームスペース上のグローバルのデータサイズをまとめて表示するには、ターミナル上で^%GSIZEユーティリティを起動することで取得することができます。
実行方法は以下の通りです。
Cachéでのデータ同期については、オブジェクトとテーブルを同期させるさまざまな方法があります。
データベースレベルでは、シャドーイングまたはミラーリングを使用できます。
これは非常によく機能し、データの一部分だけを同期する必要がある場合には、
グローバルマッピングを使用してより小さなピースにデータを分割することができます。
または、クラス/テーブルレベルで双方向の同期が必要な場合には、オブジェクト同期機能を使用することができます。
これらすべての優れた機能には次のような制限があります。
Caché/IRISからCaché/IRISにしか機能しません。
より産業向けのグローバルストレージスキーム
この連載の第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つあります。
これは InterSystems FAQ サイトの記事です。
ディスクの空きスペースにもよりますが、ブロック別で最大サイズが異なります。
各バージョン共通で、8KBのブロックサイズを使用した場合は、32TBです。
バージョン2008.1以降のバージョンでは、8KB以外のブロックサイズを指定できるようになったため、最大サイズは以下の通りです。
- 16KBのブロックサイズを使用した場合、64TB
- 32KBのブロックサイズを使用した場合、128TB
- 64KBのブロックサイズを使用した場合、256TB
目的
このツールは、データベース内からランダム読み出し入力/出力（IO）を生成するために使用されます。 このツールの目的は、目標IOPSを達成し、許容範囲内のディスク応答時間の維持を確保するために、可能な限り多くのジョブを駆動することです。 IOテストから収集された結果は、IOサブシステムに基づいて構成ごとに異なります。 これらのテストを実行する前に、対応するオペレーティングシステムとストレージレベルの監視が、今後の分析のためにIOパフォーマンスの測定データーを保存するように設定されていることを確認してください。
MonCaché — InterSystems Caché での MongoDB API 実装
免責事項：この記事は筆者の私見を反映したものであり、InterSystemsの公式見解とは関係ありません。
構想
プロジェクトの構想は、クライアント側のコードを変更せずに MongoDB の代わりに InterSystems Caché を使用できるように、ドキュメントを検索、保存、更新、および削除するための基本的な MongoDB（v2.4.9） API 機能を実装するところにあります。
動機
おそらく、MongoDB に基づくインターフェースを使って、データストレージに InterSystems Caché を使用すると、パフォーマンスが向上するのではないか。 このプロジェクトは、学士号を取得するための研究プロジェクトとして始まりました。
ダメなわけないよね？！ ¯\(ツ)/¯
制限
この研究プロジェクトを進める過程で、いくつかの簡略化が行われました。
以下の記事では、DeepSee の中程度の複雑さのアーキテクチャ設計を説明します。 前の例で説明したとおり、この実装には、DeepSee キャッシュや DeepSee の実装と設定用の個別のデータベースが含まれています。 この記事では、同期に必要なグローバルの保存用と、ファクトテーブルとインデックスの保存用に、2 つの新しいデータベースを紹介します。
以下の記事は、DeepSee の基本的なアーキテクチャを実装するためのガイドです。 この実装には、DeepSee キャッシュ用のデータベースと DeepSee 実装と設定用のデータベースが含まれています。
以下の記事は、この連載の締めくくりとして、完全に柔軟なアーキテクチャの例で確認されたすべてのデータベースのリストを掲載しています。
これは InterSystems FAQ サイトの記事です。
このエラーが発生する原因としては、アプリケーションの中で既に他のプロセスからロック対象リソースがロックされていて、何らかの理由でそのロックが解放されていないケースが考えられます。
他のプロセスがロックしている兆候がない場合は、ロックテーブルの空き領域が不足しているケースが想定されます。
その場合は、メッセージログ（コンソールログ）に LOCK TABLE FULL のメッセージが出力されます。
トランザクション処理を行なっている場合には、ロック解放の延期が影響しているケースも考えられます。
トランザクションとロック解放の延期については、以下のドキュメントをご参照下さい。
また、トランザクション中に、同一テーブルに対する大量レコードのSQL 文による更新がある場合、ロックしきい値（既定値は1000）に到達してロックエスカレーションが発生し、その結果として、テーブルロック状態になっている可能性もあります。
このように、ロックタイムアウトエラーの原因は幾つか考えられますので、まずは、管理ポータル（バージョン2010.2以前では、[システム管理ポータル]）の、ロックメニューにて、現在のロックの状態をご確認下さい。
InterSystems IRIS では、情報を格納する「グローバル」というユニークなデータ構造をサポートしています。 基本的に、グローバルとは、マルチレベルのインデックスを持つ永続配列であり、トランザクションの実行やツリー構造のスピーディなトラバーサルといった機能が備えられているほか、ObjectScript として知られるプログラミング言語にも対応しています。
ここから先、少なくともコードサンプルについては、グローバルの基礎を理解されているという想定のもとに話しを進めていきます。
グローバルはデータを保存するための魔法の剣です パート1
グローバルはデータを保存するための魔法の剣ですパート2 - ツリー
グローバルはデータを保存するための魔法の剣です パート3 - 疎な配列
グローバルは、普通のテーブルとは全く異なる構造でデータを格納し、OSI モデルの下位層で動作します。 それでは、グローバルを使ったトランザクションとはいかなるもので、どのような特性が見られるのでしょうか。
リレーショナルデータベースの理論では、ACID テスト (Wikipedia で ACID を参照する) に合格するトランザクションこそが、適切に実装されたトランザクションとされています。
これは InterSystems FAQ サイトの記事です。
管理ポータル：システムオペレーション > データベース にあるオプションボタン（ラジオボタン）「空き容量ビュー」で表示される内容は、システムクラス SYS.Database のFreeSpace クエリで取得可能です。
次のようなコードでクエリを実行します。
例:
(%SYSネームスペースにて作成、実行します)
/// ZISJ.mac
Set stmt=##class(%SQL.Statement).%New()
Set status=stmt.%PrepareClassQuery("SYS.Database","FreeSpace")
Set rs=stmt.%Execute()
While rs.%Next() {
Write !
For i=1:1:9 {
Write rs.%GetData(i),","
}
}
もしくは、以下のようにも行えます。