検索

これは InterSystems FAQ サイトの記事です。 以下の状態の時、ReadOnlyでマウントされます。 データベースの構成設定「読み込み専用でマウント」にチェックをつけている データベースマウント時「読み込み専用」のチェックをつけている ミラー構成を使用していないのにデータベースにミラー属性がついている 詳細は「ミラー・データベースがミラー構成削除後に読み取り専用でマウントされる」をご参照ください。 データベースファイルが存在するディレクトリを全体をコピーし、そのディレクトリに対してデータベースを作成したとき 詳細は「データベースファイルが存在するフォルダ全体をコピーしたとき、コピーしたデータベースファイルがマウントできません。」をご参照ください

これは、InterSystems FAQ サイト の記事です。 1つのインスタンスで作成可能なネームスペース数の上限は、2048個になります。ただし多数のネームスペースを使用するには、それに合わせてメモリの設定が必要になります。使用するメモリの設定については下記の関連トピックご参照ください。管理ポータルのメモリ関連設定項目について また1つのインスタンスに作成可能なデータベース数（リモートデータベースを含む）の上限は、15998個になります。なおライセンスの種類によっては、作成可能な数に制限が設けられています。 詳細については、以下ドキュメントをご参照ください。ドキュメント：ネームスペースの構成ドキュメント：ローカル・データベースの構成

これは、InterSystems FAQサイトの記事です。システム日付の変更をすると、InterSystems Data Platform(以下IRIS)が正常に開始しなくなる場合があります。 IRISは開始時にジャーナルファイル削除処理を行いますが、システム日付を変更すると不正な日付のジャーナルファイルが作成されます。 ジャーナルファイル削除処理では、ジャーナルファイル内部に記録された前後のファイルの情報も参照し処理を進めます。 システム日付けの変更によりジャーナルファイルの繋がりに矛盾が生じると、削除処理でループ状態となり、IRISの開始処理が完了しなくなることがありますので、ご注意ください。 システム日付を変更することはIRISに限らず、OSやミドルウェア、その上で動作するアプリケーションの依存性など様々な影響の可能性が考えられます。 テスト・検証などの関係で、どうしてもシステム日付を変更しなければならない場合には、IRISのアンインストールや再インストールが自由に行える環境（仮想環境など）でテストされることを推奨致します。 テストの基本的な流れは、以下のようになります。 システム日付変更 IRISのインストール テスト実施 IRISの停止 IRISの完全アンインストール（※） システム日付変更（現在日時に戻す） IRISのインストール （※）アンインストール後も、IRISのインストールディレクトリには一部のファイルが残されるため、IRISのインストールフォルダを全て削除する必要があります。 IRISのアンインストールや再インストールができない環境にて日付変更テストを行ってしまった場合は、IRISの復旧作業が必要となる場合があります。 詳細はカスタマーサポートセンターまでご連絡ください。 カスタマーサポートセンターについて

InterSystems API Manager (IAM) バージョン2.3がリリースされました IAMコンテナや以前のバージョンからアップグレードに必要な関連ソフトウェアは全てWRCソフトウエア配布サイトの「Components」エリアからダウンロードできます。 このリリースのビルド番号は IAM 2.3.3.2-1 です。 このリリースはKong Enterprise バージョン2.3.3.2を基にしています。 InterSystems API Manager バージョン2.3を使用することで、セキュアな方法でのデプロイや高可用性対応がより簡単に実現できます。IAMは以下の内容を含め、さまざまな新機能があります。 ハイブリッドモードの紹介 Docker secretの広域サポート ハイブリッドモードはデータプレーンとコントロールプレーンのIAMノードをデプロイできます。データプレーンがAPIトラフィックを扱っている間にコントロールプレーンはデータプレーンノードを設定したり、データプレーンからのテレメトリーを観察するのに使われます。これは導入時における柔軟性とHAシナリオを容易に実現できます。ハイブリッドモードの詳細はこちら。この機能はインターシステムズ開発者コミュニティで後ほど詳しく紹介されます。 IAM 2.3のドキュメントはこちら。このドキュメントはIAMに特化した部分のみとなります。製品内のドキュメントは直接Kong Enterpriseのドキュメントにリンクされています。 IAM 1.5.0.9からのアップグレードは2つの中間リリースを経由したインクリメンタルアップグレードが必要です。詳細についてはこのドキュメントをご参照ください。 IAMはDockerコンテナフォーマットなどのOCI(Open Container Initiative)コンテナのみとなります。コンテナイメージはLinux x84-64、Linux ARM64でのOCI準拠のランタイムエンジンのみ実行可能です。詳細はサポートプラットホームをご参照ください。 よろしくお願いいたします。 Stefan

これは 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についてインターシステムズ製品のプロセス・メモリについて 一般的に多量のローカル変数を使うと、システムが稼動するために必要なメモリ量も増加します。 大規模システムの場合には、そのことが原因でメモリ不足が発生することもあり得るため注意が必要です。 その様な事態を避けるために、なるべく、余計なローカル変数を使用しないようなシステム設計が望まれます。 多量のローカル変数が必要な場合には、プロセスプライベートグローバルで代替することを推奨します。 bbsiz の設定は管理ポータルより行います。 管理ポータル：[システム管理] > [構成 > [システム構成] > [メモリと開始設定] ： [プロセスあたりの最大メモリ（KB)] 以下の関連トピックもあわせてご参照ください。 【FAQ】InterSystems製品のプロセスが使用するメモリ量を教えてください。 【FAQ】<STORE>エラーが発生します。対処法を教えて下さい。

開発者の皆さん、こんにちは。インターシステムズ　マーケティング担当の徳江です。 弊社では来週2月16日（木）InterSystems Supply Chain Innovation Forum 2023 と題しオンラインセミナーを開催いたします。 テーマは「VUCA時代を勝ち抜くデータドリブンアプローチによるサプライチェーン変革」です。 当セミナーでは高い技術力で日本のロジスティクスを支える株式会社PALTAC様をお迎えし、インターシステムズIRISを活用した次世代物流システムへの取り組みについてお話しいただきます。また弊社セールスマネージャー佐藤比呂志より、不確実な時代を乗り切るためのデータドリブンアプローチによるサプライチェーン改革についてお話しさせていただきます。 この機会に是非ともご参加賜りたく、ご案内申し上げます。 ＜お申込みはこちらから＞　https://www.event-info.com/supplychain2023/ InterSystems Supply Chain Innovation Forum 2023　VUCA時代を勝ち抜くデータドリブンアプローチによるサプライチェーン変革開催日時：2023年2月16日（木）13:30 –14:45開催形式：オンライン形式　ライブ配信参加費用：無料（事前登録制）主 催：インターシステムズジャパン株式会社 ＜プログラム＞13:30-13:35 開会挨拶　　 インターシステムズジャパン株式会社カントリーマネージャー林雅音13:35-14:00 「次世代物流システムへの挑戦」株式会社 PALTAC情報システム本部 基幹システム部部長　吉田 啓悟 様14:05 -14:40「VUCA時代を勝ち抜くデータドリブンアプローチによるサプライチェーン変革」インターシステムズジャパン株式会社　セールスマネージャー　佐藤比呂志14:40～14:45 閉会挨拶 ※お申込みサイトと少々時間が異なっておりますが、こちらのご案内が最終版です。

これはInterSystems FAQサイトの記事です。 ISCLOG を有効にすることにより、CSP（REST）アクセスに関連するログ情報を収集できます。これを使用して CSP(REST)でのトラブル時の調査を行うことが可能です。 ◎このツールをトラブルシューティングに使用する場合は、基本的に、エラーを(意図的に)再現できる状況で使用します。　他のウェブアクセス等がない状態で、単体実行してエラーを発生させ、このログを取得して調査します。手順は以下のとおりです。 ① ログをクリアします。 //IRIS Kill ^ISCLOG //Caché Kill ^%ISCLOG ② ロギングレベルを設定します。 Set ^%ISCLOG=3 ------------------------------------#0 ― ログを記録しません。#1 ― 例外的なイベント (エラー・メッセージなど) のみをログに記録します。#2 ― 'method ABC invoked with parameters X,Y,Z and returned 1234' などの詳細な情報をログに記録します。#3 ― HTTP 要求から受け取ったデータなどの未処理のデータをログに記録します。------------------------------------ ③ CSPでエラーになる処理を行います。 ④ ロギングを無効に設定します。 Set ^%ISCLOG=0 ⑤ 詳細ログは、^ISCLOGグローバル(Cachéでは^%ISCLOG)に保存されます。 ISCLOGの詳細については、以下のドキュメントをご参照ください。ドキュメント：埋め込み言語による開発 > Web API および Web アプリケーション > CSP > ログ ログの内容について、インターシステムズで解析が必要な場合には、以下の手順でグローバルをエクスポートし、カスタマーサポートセンターまでご連絡ください。 【グローバルエクスポート手順】ターミナルで以下の要領で ^ISCLOG グローバル(Cachéでは、^%ISCLOGグローバル)をエクスポートします。USER>zn "%SYS"%SYS>d ^%GOFWrite globals to file/tape for fast input to InterSystems IRISDevice: e:\temp\isclog.gof file format: ("UNW*") => Maximum media size (bytes): (No maximum)Enter a short description of the contents of this tape or fileDescription:All Globals? No => NoGlobal ^ISCLOGGlobal ^1 global selected from 61 available globals. All globals that are mapped to another namespace will not be saved.Use %GO or GUI Cache format to save this data.^%ISCLOG 1 data block written1 blocks written in 0 minutes, 0 seconds%SYS> 上記で出力されたグローバルエクスポートファイル（isclog.gof）をお送りください。

開発者の皆さん、こんにちは。 今日はAzure上でIRIS for Healthをデプロイし、FHIRリポジトリを構築する方法をご紹介したいと思います。 AzureのMarketPlaceで「InterSystems」をキーワードに検索していただくと、以下のように複数のInterSystems製品がヒットします。 今日はこの製品の中から、InterSystems IRIS for Health Community Editionを選択し、FHIRリポジトリを構築します。 仮想マシンのサイズや、ディスク、ネットワーク等には特に制約や条件はありません。Azureで提供されている最小の構成でもIRIS for Healthを動かすこともできます。 IRIS for Health Community Editionのデプロイに成功するとこのような画面に遷移します。私の例では、コンピュータ名をIRIS4HFHIRSERVERとしています。パブリックIPアドレスはマスクしていますが、このIPアドレスを使ってIRIS管理ポータルにアクセスしてみましょう。http://<パブリックIPアドレス>:52773/csp/sys/UtilHome.csp 52773は管理ポータルにアクセスするためのポート番号であり、Azure上でデプロイするとこのポート経由でアクセスできるように既に構成が変更されています。 管理ポータルには初期パスワード _SYSTEM/SYS　でログインすることができます。ログインするとすぐに初期パスワード変更画面が表示されますので、任意のパスワードに変更してください。 ネームスペース/データベースの作成 ログインできたら、まずはFHIRリポジトリを作成する前にネームスペース・データベースを作成しましょう。私の例ではネームスペース・データベースともにFHIRSERVERという名前にしています。IRISやCache'でネームスペース/データベースの作成を経験したことがない方はこちらのドキュメントも参考にしてみてください。 FHIRリポジトリの構築 ネームスペースの作成が完了したら、管理ポータルのトップページから　Health →　<作成したネームスペース名> → FHIR Configurationと進み、FHIR SERVER CONFIGURATION　ページを表示します。 このGUIの構成ページはIRIS for Health 2020.2 から追加になりました。それ以前のバージョンではコマンドラインからFHIRリポジトリを構築する必要があります。こちらのドキュメントをご覧ください。2019.x 以前のバージョン / 2020.1 Server Configuration画面へ進み、＋アイコンをクリックして、構成画面を表示します。 Metadata Set画面で、構築するFHIRリポジトリが対応するバージョンを選択します。R4の場合はHL7v40、STU3の場合はHL7v30を選択します。Interaction strategy、URLはデフォルトのまま進み、OKを押すとFHIRリポジトリの構築がはじまります。 作成が完了するとURLをクリックして構成変更画面を表示することができます。今日は変更せずこのまま使用します。 それでは早速FHIRリポジトリにアクセスしてみましょう！ FHIRリポジトリのエンドポイントは http://<パブリックIPアドレス>:52773/csp/healthshare/fhirserver/fhir/r4 となります。 初期状態では当然データは入っていませんが、テストとしてPatientリソースをリクエストしてみましょう！私の例ではPOSTMANを使っていますが、他のRESTツールからももちろん実行可能です。 まずエンドポイントの後ろに /Patient を追加してGETメソッドを実行します。ユーザ認証が必要なので、Authorization→Basic Auth　を選択し、管理ポータルログインでも使用した_SYSTEMアカウントを指定します。 結果は0件ですが、FHIR のBundleを取得することができました！ 次はPatientリソースをPOSTしてみましょう。 日本語を含むデータを送りたいので、Content-Typeでcharsetまで指定します。 Content-Type=application/json+fhir;charset=utf-8 Bodyタブを選択して、Patientリソースを貼り付けます。私の例では、この記事の最後に記載したPatient.jsonサンプルを使っています。 POSTが成功すると、HTTP Statusが201 Createdと表示されます。 それではもう一度GETして今POSTしたPatientリソースが本当に登録されている確認しましょう！ 取得できました！ いかがでしたか？ IRIS for Health Community Editionを使用すると、簡単にFHIRリポジトリを構築することができ、すぐに使い始めることができます。Azureだけなく、AWSやGCPなどのクラウド上でもIRIS for Health Community Editionは公開されています。また、InterSystems Docker hub からはIRIS for Health Community EditionのDocker imageを入手することもできますので、この記事の内容をローカル環境で実行することもできます！ なお、InterSystems開発者コミュニティで開催されているプログラミングコンテストの2020年8月のテーマはFHIRです！詳細はこちらをご覧ください。コンテストテンプレートも公開されますのでぜひご利用ください。 Patient.json { "resourceType": "Patient", "address": [ { "postalCode": "1600023", "text": "東京都新宿区西新宿6丁目" } ], "birthDate": "1970-01-01", "gender": "male", "identifier": [ { "value": "1001" } ], "name": [ { "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/iso21090-EN-representation", "valueCode": "IDE" } ], "use": "official", "text": "山田 太郎", "family": "山田", "given": [ "太郎" ] }, { "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/iso21090-EN-representation", "valueCode": "SYL" } ], "use": "official", "text": "ヤマダ タロウ", "family": "ヤマダ", "given": [ "タロウ" ] } ], "telecom": [ { "value": "0312345678" } ] }

NoSQLデータベースという言葉を聞かれたことがあると思います。色々な定義がありますが、簡単に言えば、文字通りSQLを使わない、つまりリレーショナルデータベース(RDB)以外のデータベースのことを指すのが一般的です。 InterSystems IRIS Data Platformでは、テーブルを定義してSQLでデータにアクセスできます。ですから、InterSystems IRIS Data Platformは厳密にNoSQLデータベースというわけではありません。しかし、InterSystems IRISの高パフォーマンスを支える「グローバル」は、40年も前からInterSystemsのコア技術として、現代で言うNoSQLデータベースを提供してきました。本稿では、InterSystems IRISの「グローバル」でグラフ構造を作り、それをPythonでアクセスする方法を紹介します。 本稿で説明する内容は動画でも公開しています。ぜひご覧ください。 NoSQL NoSQLに分類されるデータベースには様々なデータモデルを扱うものがあります。以下に代表的なものを挙げます。 Key-Value: キーと値の対応関係を保持する。代表的なデータベース: Redis Document: JSONやXMLをデータモデルとするもの。代表的なデータベース: MongoDB Graph: 辺とノードからなるグラフ構造をモデルとするもの。代表的なデータベース: Neo4j その他、数え切れないほどのデータモデルと製品が存在します。 NoSQL登場の背景 なぜNoSQLというものが登場し、普及に至っているのでしょうか？本稿では、次のような理由を挙げたいと思います。 テーブルで表すのが自然ではないデータ構造がある： 理論的にはどんなデータ構造もテーブルで表し、SQLでアクセスできますが、SQLが複雑になったり、パフォーマンスが出ないなどの問題が発生するケースがあります。そのような場合、テーブルではなく、その構造に合ったデータモデルを使用するほうが良い結果を生みます。 分散環境への最適化：NoSQLの活用が活発になった一つの分野はFacebookなどのSNSのインフラです。大量のデータ、多数のユーザをサポートし、高可用性を得るため、データベースを分散させるのが必須です。RDBは、必ずしも分散環境で最適な能力を発揮できません。また、次に挙げるRDBのトランザクションに対する考え方も、分散環境では実装が難しくなる要因です。 トランザクション処理に対する要求：トランザクション処理とデータの整合性は、RDBが得意とする機能です。銀行口座を管理するシステムなどでは、トランザクション処理とデータの整合性の厳密なサポートが必須なのは言うまでもありません。しかし、トランザクション処理におけるデータの整合性の維持は、分散環境では実装が大変困難で、特にパフォーマンス性能との両立が難しいと言われています。したがって、厳密な整合性の維持よりも、分散環境におけるパフォーマンスや可用性の向上を優先したい場合、RDBよりもNoSQLの方がニーズにマッチする場合があります。 グローバル InterSystems IRISでは、グローバルと呼ばれるデータ構造がデータベースのコアに採用されています。グローバルは、次の図のように、配列変数のようなモデルです。 グローバルは事前に定義が必要ありません（スキーマレス）ので、データ構造を非常に柔軟に設計できます。また、ディスク上、メモリキャッシュ上、どちらにおいても、データは常にサブスクリプト（キー）の順にソートされていますので、データアクセスの局所化・高速化、断片化の防止を図れます。 グローバルは配列変数のような形をしていますが、実際、IRIS ObjectScriptというIRISのスクリプト言語では、メモリ上の変数とほぼ同じシンタックスで使用でき、プログラム開発の見通しが良くなります。グローバルの詳細については、グローバル使用法のドキュメントを参照してください。 Pythonからアクセス Python Native APIを使って、Pythonからグローバルを操作する例を紹介します。 題材としては、Standford大学のSNAPにある"WikiSpeedia"のデータを利用します。WikiSpeediaとは、与えられた言葉から目標とする言葉に、Wikipediaのリンクだけを辿ってたどり着く速さを競うゲームです。SNAPには、実際のユーザが辿ったリンクの情報が約11万件ありますので、それをInterSystems IRISのグローバルに格納しました。 グラフ構造 ここで、グラフ構造について説明します。 図に示したのがグラフ構造の基本です。グラフは、ノードと辺から構成されます。辺は、2つのノードを結びつけるものです。 例えば、Facebookの友達の関係は、ノード=ユーザ、辺=友達関係　とすれば表現できます。また、ノード=駅、辺=ある駅の隣の駅、辺のプロパティ=駅と駅の距離 とすれば、路線検索に使えるデータ構造が実現できます。 本稿の例では、ノード=Wikipediaの記事（見出し語）、辺=WikiSpeediaのユーザがリンクをクリックした元の記事とリンク先の記事の関係 としてグラフ構造を利用します。 グローバルの構造 グローバルの構造を見てみましょう。 ^Links("Tokyo", "18th_century")="" ^Links("Tokyo", "London")="" ^Links("Osaka", "Aquarium")="" 例えば、一番上の行は、ユーザが"Tokyo"という記事から"18th_century"（18世紀）という記事へのリンクをクリックしたことを表します。また、3行目は、"Osaka"から"Aquarium"（水族館）へクリックしたことを表します。 グローバルは、サブスクリプト（キー）の左から右の方向でアクセスすることに最適化されています。したがって、 ^Links("元記事”,"クリック先の記事")="" という構造が最適であることが分かると思います。また、今回は値は""ですが、辺に何らかの属性を持たせたい場合は、それをグローバルの値に設定すれば良いと思います。 Pythonのコード Pythonのコードについて説明します。まずは、importです。 import irisnative import networkx as nx Python Native APIを使用するためには、irisnativeモジュールをインポートします。このモジュールは、IRISをインストールした際、dev/pythonディレクトリに置かれる.whlファイルをpipコマンドでpythonの環境にインストールしておきます。また、グラフ構造保持のために、NetworkXを使用していますので、それもimportしておきます。 connection = irisnative.createConnection("localhost", 9091, "user", "horita","horita") iris_native = irisnative.createIris(connection) この2行では、createConnection()でIRISへの接続を行い、createIris()でグローバル操作のインターフェースオブジェクトを生成しています。 def addNodes(key, g, d): g.add_node(key) if d > 3: return iter = iris_native.iterator("Links", key) nodelist = [k for k,v in iter.items()] # デモのため、辿るリンクを3つに限定　 random.shuffle(nodelist) nodelist = nodelist[0:3] edgelist = [(key, n) for n in nodelist] g.add_nodes_from(nodelist) g.add_edges_from(edgelist) for subk in nodelist: addNodes(subk, g, d + 1) addNodes()関数の定義です。この関数は、与えられたグラフのノードからリンクを辿ってグラフ構造をNetworkXのオブジェクトとして構築する関数です。再帰呼び出しによって、3階層目まで辿るようにしています。一番のポイントは、 iter = iris_native.iterator("Links", key) nodelist = [k for k,v in iter.items()] という箇所です。iris_native.iterator("Links", key)では、Python Native APIによって、サブスクリプトのイテレータを作成しています。例えば、key='Tokyo'の場合は、^Links("Tokyo", *)の*の部分にある文字列について繰り返すイテレータになります。 そのイテレータをPythonのforで繰り返し、リストを作ります。このように、グローバルのイテレータがPythonの繰り返しモデルにうまく適合して、シンプルなコードになっていることが分かります。 curkey = 'Tokyo' G = nx.Graph() addNodes(curkey, G, 1) そして、"Tokyo"という言葉をキーとしてaddNodes()を呼び出します。これで、"Tokyo"という言葉から辿られたリンクの繋がりが得られます。それが次の図です。 "Tokyo"という言葉からクリックされた言葉のネットワークが表現されています。 まとめ InterSystems IRISのグローバルは、NoSQLデータベースが選択されるようなニーズで力を発揮します。また、Python Native APIによって、Pythonのプログラムから自然な形でグローバルを操作することが可能になります。 ぜひ一度試してみてください。また、質問などをこの記事のコメントに書いて頂ければ大変嬉しいです。

デベロッパーエコシステムサマーニュースへようこそ！ この夏、インターシステムズのデベロッパーエコシステムにおいて、たくさんのエキサイティングなイベントやアクティビティがありました。その中でも最もホットなニュースやトピックを厳選してお届けします。 ここでは、この時期にあった注目すべきことを、一目でわかるようにまとめました。どうぞご覧ください！ ニュース 🎉 １万件の投稿、1万1千人のメンバー、500万リードを達成しました​​​ 💡 インターシステムズアイデアが発表されました 🆕 「はじめに」ページを一新しました 🆕 DC企画: "インターシステムズミーム" (+part 1) 🆕 DC企画: 重要な質問 ⛱ 探求心の夏！ 質問ポイントが２倍！ ☕️ Dev Random Coffee - グローバルマスターズでの新たなネットワークづくりにご参加ください！ 🔗 フランス語DC > < グローバルマスターズ API 統合が始まりました コンテスト、イベント 🔥 インターシステムズグローバルサミット 2022 アナウンス サミットからのライブ中継: パート1, パート2 InterSystems Developers at the Summit: how it was? キーノートが公開されました 🏆 インターシステムズ Full Stack コンテスト 2022 ルールと賞金 Kick-off Webinar 受賞者発表 Meetup with winners 🏆 インターシステムズ 技術文書コンテスト Python バージョン ルールと賞金 New contest bonuses introduced 受賞者発表 🧩 コードゴルフチャレンジ ⏯ DC主催ウェビナー: ECPを使ったAmazon Webサービスでのスケールアウト 👩‍💻 ウーマンヘルス - インターシステムズ主催のFemTech panel 👋 Pythonインターオペラビリティに関するインターシステムズ開発者ミートアップ in Boston 最新リリース ⬇️ インターシステムズ IRIS、IRIS for Health、HealthShare Health Connect 2022.2 開発者プレビュー プレビュー 1 プレビュー 2 プレビュー 3 プレビュー 4 プレビュー 5 プレビュー 6 ⬇️ インターシステムズ IRIS、IRIS for Health、 HealthShare Health Connect 2022.1 ⬇️ インターシステムズ API マネージャ 2.8.1 🆕 開発者コミュニティリリース 2022年7月 🆕 Open ExchangeでのUX/UI の変更 🆕 新たな Open Exchangeの機能 - ObjectScript Quality status ベストプラクティス、主要な質問 🔥 2022年夏のベストプラクティス SQLゲートウェイを使ったデータベース移行 SystemPerformance Utility (pka pButtons) API (and REST API) [and sample UI] Ensemble Orphaned Messages Python のみを使用した InterSystems のインターオペラビリティフレームワーク %SYSTEM.Encryption クラスを習得する Method to recompile classes and routines after a major upgrade ❓ 2022年夏の主要な質問 7月, 8月 人々 👋 新たなDCモデレータ - 黄 念刚 (Niangang Huang) 🌟 2022年夏のグローバルマスターズ 6月, 7月, 8月 求人情報 💼 シニアアプリケーション開発アナリスト - The Ohio State University Wexner Medical Center 💼 IインターシステムズIRIS開発者 - フランス語が話せる方 - 勤務地：パリ 💼 Potential HealthShare opportunity 💼 Senior Software Developer - International Healthcare 💼 Looking for a Fully Remote InterSystems IRIS Developer これらが私たちの考える最も重要で興味深い内容です！ あなたにとって、今年の夏、冬のハイライトは何でしょうか？コメント欄で共有して、喜びを思い出してください！​​​​​

Google Cloud Platform（GCP）は、IaaS（サービスとしてのインフラストラクチャ）向けの機能性豊かな環境をクラウドとして提供しています。最新の InterSystems IRIS データプラットフォームなど、InterSystems の全製品に完全に対応していますが、 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 この記事では、こういった各分野の詳細について説明しています。 以下の概要と詳細は Google が提供しているものであり、こちらから参照できます。   概要 ### GCP リソース GCP は、コンピュータやハードドライブといった一連の物理アセットと、仮想マシン（VM）といった仮想リソースから構成されており、世界中の Google データセンターに保管されています。 それぞれのデータセンターの場所は 1 つのグローバルリージョンにあります。 そして、それぞれのリージョンはゾーンのコレクションであり、これらのコレクションはリージョン内で互いに分離されています。 各ゾーンには、文字識別子とリージョン名を合わせた名前が付けられています。 このようなリソースの分散には、障害発生に備えて冗長性を得たり、リソースをクライアントに近い場所に配置することでレイテンシを軽減できたりなど、さまざまなメリットがあります。 また、このような分散によって、リソースをどのように合わせて使用できるかに関するルールも導入することができます。 ### GCP リソースへのアクセス クラウドコンピューティングでは、物理的なハードウェアとソフトウェアがサービスとなります。 これらは基盤リソースへのアクセスを提供するサービスです。 InterSystems IRIS ベースのアプリケーションを GCP で開発する場合、必要としているインフラストラクチャを得られるようにこれらのサービスを組み合わせ、コードを追加することで、構成しようとしているシナリオを実現することができます。 利用可能なサービスの詳細は、こちらを参照してください。 ### プロジェクト 割り当てて使用する GCP は、プロジェクトに属するものである必要があります。 プロジェクトは、設定、権限、およびアプリケーションを説明するその他のメタデータで構成されます。 単一のプロジェクト内のリソースは、リージョンとゾーンのルールに従って、内部ネットワークを介した通信などによって簡単に連携することができます。 各プロジェクトに含まれるリソースは、プロジェクトの境界で分離されたままであるため、外部ネットワーク接続を介してしか相互接続することはできません。   サービスとの対話 GCP でサービスとリソースを操作するには、基本的に 3 つの方法があります。 #### コンソール Google Cloud Platform Console は、Web ベースのグラフィカルユーザーインターフェースを提供しており、ユーザーは、それを使用して GCP のプロジェクトとリソースを管理することができます。 GCP Console を使用する場合、新規プロジェクトを作成するか既存のプロジェクトを選択すると、作成するリソースをプロジェクトの文脈で使用できます。 複数のプロジェクトを作成できるため、ユーザーに意味のある方法で、プロジェクトを使用して分類することができます。 たとえば、リソースにアクセスできるユーザーを特定のチームメンバーに限定する場合は新しいプロジェクトを開始し、すべてのチームメンバーは引き続き別のプロジェクトのリソースにアクセスすることができます。   コマンドラインインターフェース ターミナルウィンドウで作業する場合、Google Cloud SDK の gcloud コマンドラインツールを使用して、必要なコマンドにアクセスすることができます。 gcloud ツールでは、開発ワークフローと GCP リソースの両方の管理を行えます。 gcloud のリファレンスについては、こちらをご覧ください。 GCP には、Cloud Shell という、ブラウザで使用する GCP 向けのインタラクティブシェル環境も用意されています。 Cloud Shell には、GCP Console からアクセスできます。 以下に、Cloud Shell の特徴を示します。 一時的な Compute Engine 仮想マシンインスタンス Web ブラウザからインスタンスへのコマンドラインアクセス ビルトインのコードエディタ 5 GB の永続ディスクストレージ プレインストールされた Google Cloud SDK およびその他のツール Java、Go、Python、Node.js、PHP、Ruby、および .NET 言語のサポート Web プレビュー機能 GCP Console プロジェクトとリソースへのアクセスの組み込み認証   クライアントライブラリ Cloud SDK には、リソースを簡単に作成して管理できるクライアントライブラリが含まれています。 GCP クライアントライブラリは、主に 2 つの目的で API を公開しています。 アプリ API はサービスへのアクセスを提供します。 アプリ API は、Node.js や Python といったサポート対象の言語用に最適化されています。 ライブラリは、サービスのメタファーを軸に設計されているため、ユーザーはサービスをより自然に操作し、より少ないボイラープレートコードを記述することができます。 ライブラリは、認証と承認のヘルパーも提供しています。 詳細は、こちらを参照してください。 管理 API は、リソース管理機能を提供します。 たとえば、独自の自動化ツールを構築する場合、管理 API を使用できます。 また、Google API クライアントライブラリを使用して、Google マップ、Google ドライブ、および YouTube といった製品用の API にアクセスすることもできます。 GCP クライアントライブラリの詳細は、こちらを参照してください。   InterSystems IRIS サンプルアーキテクチャ この記事の一部として、アプリケーション固有のデプロイメントの出発点として、GCP 向けの InterSystems IRIS サンプルデプロイメントを提供しています。 デプロイメントの可能性には多数ありますが、これらのサンプルをガイドラインとしてご利用ください。 このリファレンスアーキテクチャでは、規模の小さなデプロイメントから非常にスケーラブルなワークロードまで、コンピューティングとデータの両方の要件に対応する非常に堅牢なデプロイメントオプションを紹介しています。 このドキュメントでは、高可用性と災害復旧に関するオプション、そしてその他の推奨システム運用について説明しています。 組織の標準的なやり方やセキュリティポリシーに応じて変更してください。 InterSystems では、ユーザー固有のアプリケーションについて、GCP ベースの InterSystems IRIS デプロイメントに関するご相談またはご質問をお受けしています。   * * * サンプルリファレンスアーキテクチャ 以下のサンプルアーキテクチャでは、キャパシティと機能を高めるさまざまな構成を提供します。 小規模な開発、本番、大規模な本番、およびシャードクラスタを使用した本番を検討してください。開発作業用の規模の小さな構成から、ゾーン全体に適した高可用性とマルチリージョン災害復旧を備えた非常にスケーラブルなソリューションへと構成が増大していく様子を確認できます。 さらに、SQL クエリの超並列処理によるハイブリッドワークロードに対する InterSystems IRIS データプラットフォームの新しいシャーディング機能を使用するサンプルアーキテクチャも用意されています。 ###   小規模開発の構成 この例では、最小構成を使用して、開発者数最大10 人と 100 GB のデータに対応できる小規模な開発環境を示します。 仮想マシンのインスタンスの種類を変更し、永続ディスクのストレージを適切に増加するだけで、より多くの開発者とデータ量を簡単にサポートできるようになります。 これは、開発作業をサポートし、InterSystems IRIS の機能性と、必要であれば Docker コンテナの構築とオーケストレーションに慣れる上で十分な構成です。 小規模な構成では通常、データベースミラーリングによる高可用性を使用することはありませんが、高可用性が必要な場合にはいつでも追加することができます。   小規模な構成のサンプル図 以下の図 2.1.1-a のサンプル図は、図 2.1.1-b のリソーステーブルを示します。 含まれているゲートウェイは単なる例であり、組織の標準的なネットワークに合わせて調整できます。     以下の GCP VPC プロジェクト内のリソースは、最低限の小規模構成としてプロビジョニングされています。 GCP リソースは必要に応じて追加または削除することができます。   小規模構成の GCP リソース 以下のテーブルは、小規模構成 GCP リソースのサンプルを示しています。     VPC への不要なアクセスを防止するには、適切なネットワークセキュリティとファイアウォールのルールを検討する必要があります。 Google は、これに取り掛かるためのネットワークセキュリティに関するベストプラクティスをこちらで提供しています。   注意: VM インスタンスが GCP サービスにアクセスするには、パブリック IP アドレスが必要です。 このやり方では懸念を生じてしまう可能性がありますが、Google は、ファイアウォールのルールを使用して、これらの VM インスタンスへの受信トラフィックを制限することを推奨しています。   セキュリティポリシーで VM インスタンスが完全に内部化されていることが要求されている場合、ネットワークと対応するルートに手動で NAT プロキシを設定し、内部インスタンスがインターネットにアクセスできるようにする必要があります。 SSH を使用して、完全に内部化された VM インスタンスを直接接続することはできないことに注意しておくことが重要です。 そのような内部マシンに接続するには、外部 IP アドレスを持つ踏み台インスタンスをセットアップしてから、それを通過するトンネルをセットアップする必要があります。 外部に面する VPC へのエントリポイントを提供する踏み台ホストをプロビジョニングすることができます。 踏み台ホストの詳細は、こちらを参照してください。   本番構成 この例では、InterSystems IRIS データベースミラーリング機能を組み込んで高可用性と災害復旧をサポートする本番構成の例として、より大規模な構成を示しています。 この構成には、自動フェイルオーバーを行うための、region-1 内で 2 つのゾーンに分割された InterSystems IRIS データベースサービスの同期ミラーペアと、GCP リージョン全体がオフラインになるという稀なイベントにおいて災害復旧を行うための、region-2 の 3 番目の DR 非同期ミラーメンバーが含まれます。 InterSystems Arbiter と ICM サーバーは、回復力を得るために、別の 3 番目のゾーンにデプロイされています。 サンプルアーキテクチャには、Web 対応アプリケーションをサポートするためのオプションとして、一連の負荷分散された Web サーバーも含まれています。 InterSystems Gateway を備えたこれらの Web サーバーは、必要に応じて個別に拡張することができます。   本番構成のサンプル図 以下の図 2.2.1-a のサンプル図は、図 2.2.1-b のリソーステーブルを示します。 含まれているゲートウェイは単なる例であり、組織の標準的なネットワークに合わせて調整できます。     以下の GCP VPC プロジェクト内のリソースは、シャードクラスタをサポートするための最低推奨事項として推奨されています。 GCP リソースは必要に応じて追加または削除することができます。   本番構成の GCP リソース 以下のテーブルは、本番構成 GCP リソースのサンプルを示しています。     大規模な本番の構成 この例では、InterSystems IRIS の機能を拡張することで、InterSystems Cache プロトコル（ECP）を使用したアプリケーションを導入してユーザーの大規模な水平スケーリングも提供できる、大規模な構成を示しています。 この例にはさらに高レベルの高可用性が含まれており、データベースインスタントのフェイルオーバーが発生した場合でも ECP クライアントがセッション情報を保持できるようになっています。 複数のリージョンにデプロイされた ECP ベースのアプリケーションサーバーとデータベースメンバーには、複数の GCP ゾーンが使用されています。 この構成では、毎秒数千万件のデータベースアクセスと数テラバイトのデータをサポートできます。   大規模な本番構成のサンプル図 図 2.3.1-a のサンプル図は、図 2.3.1-b のリソーステーブルを示します。 含まれているゲートウェイは単なる例であり、組織の標準的なネットワークに合わせて調整できます。 この構成には、フェイルオーバーミラーペア、4 つ以上の ECP クライアント（アプリケーションサーバー）、およびアプリケーションサーバー当たり 1 つ以上の Web サーバーが含まれます。 フェイルオーバーデータベースミラーのペアは、同一のリージョン内で 2 つの異なる GCP ゾーンで分割されており、3 番目のゾーンに個別にデプロイされた InterSystems Arbiter と ICM サーバーでフォールトドメインの保護を確立し、さらなる回復力を備えています。 災害復旧は、前の例と同様に、2 番目の GCP リージョンとゾーンに拡張されています。 複数の DR リージョンは、必要に応じて複数の DR 非同期ミラーメンバーターゲットと使用できます。     以下の GCP VPC プロジェクト内のリソースは、大規模な本番デプロイメントをサポートするための最低推奨事項として推奨されています。 GCP リソースは必要に応じて追加または削除することができます。   大規模な本番構成の GCP リソース 以下のテーブルは、大規模な本番構成 GCP リソースのサンプルを示しています。     InterSystems IRIS シャードクラスタを使用した本番構成 この例では、SQL を使用したハイブリッドワークロード向けに水平スケーリングされた構成を示しています。InterSystems IRIS の新しいシャードクラスタ機能が含まれており、複数のシステムをまたぐ SQL クエリとテーブルの大規模な水平スケーリングを提供しています。 InterSystems IRIS のシャードクラスタとその機能の詳細については、この記事の後半で説明します。 InterSystems IRIS シャードクラスタを使用した本番構成 図 2.4.1-a のサンプル図は、図 2.4.1-b のリソーステーブルを示します。 含まれているゲートウェイは単なる例であり、組織の標準的なネットワークに合わせて調整できます。 この構成には、データノードとして 4 つのミラーペアが含まれます。 それぞれのフェイルオーバーデータベースミラーのペアは、同一のリージョン内で 2 つの異なる GCP ゾーンで分割されており、3 番目のゾーンに個別にデプロイされた InterSystems Arbiter と ICM サーバーでフォールトドメインの保護を確立し、さらなる回復力を備えています。 この構成では、クラスタ内のあらゆるデータノードからすべてのデータベースアクセスメソッドを利用することができます。 大規模な SQL テーブルのデータは、すべてのノード間で物理的に分割されているため、クエリ処理とデータ量の大規模な並列化が実現されます。 これらすべての機能を組み合わせることで、単一の InterSystems IRIS データプラットフォーム内で、新しいデータの取り込みと同時に大規模な分析 SQL クエリを実行するなど、あらゆる複雑なハイブリッドワークロードをサポートできるようになります。   上の図と、下のテーブルの「リソースタイプ」列にある「Compute [Engine]」とは、このドキュメントのセクション 3.1 で説明されているとおり、GCP（仮想）サーバーインスタンスを表す GCP 用語です。 この記事の後半で説明するクラスタアーキテクチャでの「計算ノード」の使用を表したり暗示するものではありません。 以下の GCP VPC プロジェクト内のリソースは、シャードクラスタをサポートするための最低推奨事項として推奨されています。 GCP リソースは必要に応じて追加または削除することができます。 シャードクラスタを使用した本番構成の GCP リソース 以下のテーブルは、シャードクラスタ構成 GCP リソースのサンプルを示しています。     * * * クラウドの基礎概念 Google Cloud Platform（GCP）は、IaaS（サービスとしてのインフラストラクチャ）向けの機能性豊かなクラウド環境を提供しています。新しい InterSystems IRIS データプラットフォームによるコンテナベースの開発運用など、InterSystems の全製品に完全に対応していますが、 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、システム運用、高可用性、災害復旧、セキュリティ制御、およびその他の管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 このドキュメントでは、Compute、Storage、および Networking という、すべてのクラウドデプロイメントの 3 つの主要コンポーネントについて説明します。   Compute Engine（仮想マシン） GCP 内には、仮想 CPU とメモリの仕様と関連するストレージオプションを数多く備えた Compute Engine リソースで利用できるオプションがいくつかあります。 GCP 内で注意する項目の 1 つとして、あるマシンタイプの vCPU 数は、1 つの vCPU に相当することです。これはハイパーバイザー層にある物理ホスト上の 1 つのハイパースレッドということになります。 このドキュメントでは、n1-standard* と n1-highmem* インスタンスタイプが使用されており、ほとんどの GCP デプロイメントリージョンで最も広く利用できるインスタンスです。 ただし、大量のデータをメモリにキャッシュする非常に大型の作業データセットにおいては、n1-ultramem* インスタンスタイプを使用することが優れたオプションと言えます。 特記されている場合を除き、インスタンス可用性ポリシーなどのデフォルトのインスタンス設定やその他の高度な機能が使用されています。 さまざまなマシンタイプの詳細は、こちらを参照してください。   ディスクストレージ InterSystems 製品に最も直接関係しているストレージタイプは、永続ディスクタイプですが、データ可用性の制限を理解して対応できる場合には、ローカルストレージを使用して高度なパフォーマンスを実現することができます。 Cloud Storage（バケット）といったその他のオプションもいくつかありますが、それらは InterSystems IRIS データプラットフォームの運用をサポートするというよりも、個別のアプリケーションの要件に特化したオプションです。 ほかのほとんどのクラウドプロバイダと同様に、GCP でも、各 Compute Engine に関連付けられる永続ストレージの容量に制限があります。 これらの制限には、各ディスクの最大サイズ、各 Compute Engine に接続される永続ディスクの数量、永続ディスク当たりの IOPS 量と各 Compute Engine インスタンスの総合的な IOPS 限界などがあります。 さらに、ディスク容量 1 GB あたりの IOPS 制限もあるため、希望する IOPS レートを得るには、より多くのディスク容量をプロビジョニングする必要があります。 これらの制限は、時間の経過とともに変化する可能性があるため、適宜、Google に確認する必要があります。 ディスクボリュームの永続ストレージタイプには、標準永続ディスクと SSD 永続ディスクの 2 種類があります。 予測可能な低レイテンシ IOPS とより高いスループットを必要とする本番ワークロードには、SSD 永続ディスクがより適しています。 標準永続ディスクは、非本番環境の開発とテストやアーカイブタイプのワークロード向けのより経済的なオプションです。 さまざまなディスクタイプと制限の詳細については、こちらを参照してください。   VPC ネットワーキング InterSystems IRIS データプラットフォームの多様なコンポーネントのサポートとともに、適切なネットワークセキュリティコントロール、各種ゲートウェイ、ルーティング、内部 IP アドレス割り当て、ネットワークインターフェース分離、およびアクセス制御を提供するには、仮想プライベートクラウド（VPC）ネットワークの使用が強く推奨されます。 VPC の例は、このドキュメントに含まれる例で詳しく説明します。 VPC ネットワーキングとファイアウォールの詳細については、こちらを参照してください。   * * * 仮想プライベートクラウド（VPC）の概要 GCP VPC はほかのクラウドプロバイダとは少し異なり、簡素化とより優れた柔軟性を実現しています。 概念の比較は、こちらを参照してください。 GCP プロジェクト内では、プロジェクトごとに複数の VPC を使用でき（現在、プロジェクトあたり最大 5 個）、自動モードとカスタムモードの 2 つのオプションで VPC ネットワークを作成できます。 それぞれの詳細は、こちらを参照してください。 ほとんどの大規模なクラウドデプロイメントでは、複数の VPC をプロビジョニングして、さまざまなゲートウェイタイプをアプリケーション中心の VPC から分離し、インバウンドとアウトバウンドの通信に VPC ピアリングを活用しています。 会社で使用されているサブネットと組織のファイアウォールルールの詳細について、ネットワーク管理者に相談することを強くお勧めします。 VPC ピアリングについては、このドキュメントで説明していません。 このドキュメントに含まれる例では、3 つのサブネットを持つ単一の VPC を使用して、予測可能なレイテンシと帯域幅、およびさまざまな InterSystems IRIS コンポーネントのセキュリティ分離を得るために、コンポーネントのネットワーク分離を行っています。   ネットワークゲートウェイとサブネットの定義 このドキュメントでは、インターネットとセキュア VPN 接続をサポートするために、2 つのゲートウェイを使用した例を示しています。 アプリケーションに適度なセキュリティを提供するために、各侵入アクセスには、適切なファイアウォールとルーティングのルールが必要です。 ルートの使用方法に関する詳細については、こちらを参照してください。 InterSystems IRIS データプラットフォーム専用のアーキテクチャ例では、3 つのサブネットが使用されています。 これらの個別のネットワークサブネットとネットワークインターフェースを使用することで、セキュリティコントロールと帯域幅の保護に柔軟性を持たせ、上記の 3 つの主要コンポーネントをそれぞれ監視することができます。 さまざまな使用事例に関する詳細は、こちらを参照してください。 複数のネットワークインターフェースを備えた仮想マシンインスタンスの作成に関する詳細は、こちらを参照してください。   これらの例には、次のサブネットが含まれます。 インバウンド接続ユーザーとクエリ用のユーザースペースネットワーク シャードノード間通信用のシャードネットワーク 各データノードの同期レプリケーションと自動フェイルオーバーを使用して高可用性を実現するミラーリングネットワーク   注意: フェイルオーバー同期データベースミラーリングは、単一の GCP リージョン内で相互接続のレイテンシが低い複数のゾーンでのみ推奨されます。 リージョン間のレイテンシは非常に高いことが通例であるため、特に更新が頻繁に行われるデプロイメントにおいては、良好なユーザーエクスペリエンスを提供することができません。   ### 内部ロードバランサー ほとんどの IaaS クラウドプロバイダーには、自動データベースフェイルオーバー設計で一般的に使用される仮想 IP（VIP）アドレスに対応できる能力が欠けています。 これを解決するために、ミラー対応かつ自動化する VIP 機能に依存しないように、最も一般的に使用されるいくつかの接続方法（特に ECP クライアントや Web ゲートウェイ）が InterSystems IRIS 内で強化されています。 xDBC、ダイレクト TCP/IP ソケット、またはその他のダイレクトコネクトプロトコルなどの接続方法には VIP のようなアドレスを使用する必要があります。 そういったインバウンドプロトコルをサポートするために、InterSystems のデータベースミラーリング技術では、<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span> というヘルスチェックステータスページを使って、それらの接続方法の自動フェイルオーバーを GCP 内で提供できるようになっています。VIP のようなロードバランサーの機能性を達成するためにロードバランサーと対話し、アクティブなプライマリメンバーにのみトラフィックをダイレクトすることで、完全かつ堅牢な高可用性設計を GCP 内で作り上げています。     ロードバランサーを使用して VIP のような機能を提供する方法の詳細については、こちらを参照してください。   VPC トポロジの例 以下の図 4.3-a では、すべてのコンポーネントを組み合わせて、次の特性を持つ VPC のレイアウトを示しています。 高可用性を得るために、リージョン内の複数のゾーンを活用する 災害復旧を可能にするために、2 つのリージョンを提供する ネットワーク分離を実施するために、複数のサブネットを使用する インターネットと VPN の両方の接続を得るために、個別のゲートウェイを含める ミラーメンバーが IP フェイルオーバーを行えるように、クラウドロードバランサーを使用する   * * * 永続ストレージの概要 はじめに説明したとおり、GCP 永続ディスク、特に SSD 永続ディスクタイプの使用をお勧めしています。 読み取りと書き込みの IOPS レートがより高く、トランザクションと分析用のデータベースワークロードに必要なレイテンシが低いため、SSD 永続ディスクが推奨されています。 特定の状況で ローカル SSD を使用できることもありますが、ローカル SSD のパフォーマンス向上には、可用性、耐久性、および柔軟性のトレードオフが伴うことに注意してください。 ローカル SSD データ永続性の詳細については、こちらを参照してください。ローカル SSD データが保持される場合とされない場合を理解することができます。   LVM ストライピング ほかのクラウドプロバイダと同様に、GCP においても、IOPS、容量、および仮想マシンインスタンス当たりのデバイス数に関してストレージに対する制限を課しています。 GCP ドキュメンテーションで現在の制限を確認してください。こちらから参照できます。 これらの制限により、データベースインスタンスの単一ディスクデバイスの IOPS 以上に最大化するために、LVM ストライピングが必要となります。 提供されている仮想マシンインスタンスの例では、以下のディスクレイアウトが推奨されています。 SSD 永続ディスクに関連するパフォーマンス制限については、こちらを参照してください。   注意: 現在の仮想マシンインスタンス当たりの最大永続ディスク数は 16 個ですが、GCP では「ベータ版」として 128 個への増加を記載しています。喜ばしい拡張です。     LVM ストライピングのメリットによって、ランダムな IO ワークロードをより多くのデバイスに分散し、ディスクキューを継承することができます。 以下は、データベースボリュームグループに対して、Linux で LVM ストライピングを使用する方法の例を示しています。 この例では、物理エクステント（PE）サイズが 4 MB の LVM PE ストライプで 4 つのディスクを使用します。 または、必要に応じて、より大きな PE サイズを使用することもできます。   手順 1: 必要に応じて、標準または SSD 永続ディスクを作成します 手順 2: “lsblk -do NAME,SCHED” を使用して、各ディスクデバイスの IO スケジューラが NOOP であることを確認します 手順 3: “lsblk -do KNAME,TYPE,SIZE,MODEL” を使用して、ディスクデバイスを識別します 手順 4: 新しいディスクデバイスでボリュームグループを作成します vgcreate s 4M   例: vgcreate -s 4M vg_iris_db /dev/sd[h-k] 手順 4: 論理ボリュームを作成します lvcreate n -L -i -I 4MB 例: lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db 手順 5: ファイルシステムを作成します mkfs.xfs K 例: mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01 手順 6: ファイルシステムをマウントします 次のマウントエントリで /etc/fstab を編集します /dev/mapper/vg_iris_db-lv_irisdb01    /vol-iris/db    xfs  defaults 0 0 mount /vol-iris/db 上記の表を使用すると、各 InterSystems IRIS サーバーに、SYS 用ディスク 2 個、DB 用ディスク 4 個、プライマリジャーナル用ディスク 2 個、および代替ジャーナル用ディスク 2 個を備えた以下の構成が作られます。   成長に関しては、LVM では中断することなく、必要に応じてデバイスと論理ボリュームを拡張できます。 LVM ボリュームの継続的な管理と拡張のベストプラクティスについては、Linux のドキュメンテーションを参照してください。   注意: データベースと書き込みイメージジャーナルファイルの両方で非同期 IO を有効にすることを強くお勧めします。 Linux での有効化に関する詳細については、次のコミュニティ記事を参照してください: https://community.intersystems.com/post/lvm-pe-striping-maximize-hyper-converged-storage-throughput   * * * プロビジョニング InterSystem IRIS に InterSystems Cloud Manager（ICM）という新しいツールがあります。 ICM は、多くのタスクを実行し、InterSystems IRIS データプラットフォームをプロビジョニングするためのオプションを多数提供しています。 ICM は Docker イメージとして提供され、堅牢な GCP クラウドベースのソリューションをプロビジョニングするために必要なすべての機能を含んでいます。 ICM は現在、以下のプラットフォームでのプロビジョニングをサポートしています。 Google Cloud Platform（GCP） GovCloud を含む Amazon Web Services（AWS / GovCloud） 政府を含む Microsoft Azure Resource Manager（ARM / MAG） VMware vSphere（ESXi） ICM と Docker は、デスクトップ/ノートブックワークステーションから実行することも、小規模な専用の集中型「プロビジョニング」サーバーと集中型レポジトリを持つことも可能です。   アプリケーションのライフサイクルにおける ICM の役割は、 定義 -> プロビジョン -> デプロイ -> 管理です。 ICM のインストールと Docker との使用に関する詳細は、こちらを参照してください。   注意: クラウドデプロイメントでは、ICM を使用する必要はありません。 tar-ball ディストリビューションを使用した従来のインストールとデプロイメントは完全にサポートされており、提供されていますが、 クラウドデプロイメントでのプロビジョニングと管理を簡単化できる ICM の使用をお勧めします。   コンテナの監視 ICM には、コンテナベースのデプロイメント向けに Weave Scope を使用した基本的な監視機能が含まれています。 デフォルトではデプロイされないため、defaults ファイルの Monitor フィールドを使用して指定する必要があります。 ICM を使用した監視、オーケストレーション、およびスケジューリングに関する詳細は、こちらを参照してください。 Weave Scope の概要とドキュメンテーションは、こちらをご覧ください。   * * * 高可用性 InterSystems のデータベースミラーリングは、あらゆるクラウド環境で最も高度な可用性を提供します。 直接インスタンスレベルである程度の仮想マシンの回復力を提供するオプションがあります。 GCP で利用できる各種ポリシーに関する詳細は、こちらを参照してください。 前の方のセクションでは、クラウドロードバランサーがデータベースミラーリングを使用して仮想 IP（VIP のような）機能に自動 IP アドレスフェイルオーバーを提供する方法について説明しました。 クラウドロードバランサーは、前の「内部ロードバランサー」セクションで述べた mirror_status.cxw というヘルスチェックステータスページを使用します。 データベースミラーリングには、自動フェイルオーバー付きの同期ミラーリングと非同期ミラーリングとうい 2 つのモードがありますが、 この例では、同期フェイルオーバーミラーリングについて説明しています。 ミラーリングの詳細については、こちらを参照してください。 最も基本的なミラーリング構成は、アービター制御構成で一組のフェイルオーバーミラーメンバーを使用する構成です。 アービターは同一リージョン内の 3 番目のゾーンに配置されており、アービターと片方のミラーメンバーに影響を与える可能性のあるゾーンの停止から保護します。 ネットワーク構成でミラーリングをセットアップする方法はたくさんありますが、 この例では、このドキュメントの「ネットワークゲートウェイとサブネットの定義」セクションで定義したネットワークサブネットを使用します。 IP アドレススキームの例は以下のセクションで提供しています。このセクションでは、ネットワークインターフェースと指定されたサブネットについてのみ示しています。   * * * 災害復旧 InterSystems のデータベースミラーリングは、高可用性機能を拡張することで、別の GCP 地理リージョンへの災害復旧もサポートし、GCP の全リージョンがオフラインになるという万が一の事態に備え、運営の弾力性をサポートします。 アプリケーションがそのような停止にどのようにして耐えるかは、目標復旧時間（RTO）と目標復旧ポイント（RPO）によって異なります。 これらは、適切な災害復旧計画を作成するために必要な分析の初期フレームを提供するものです。 以下のリンクでは、アプリケーションの災害復旧計画を作成する際に検討すべき項目のガイドが提供されています。 https://cloud.google.com/solutions/designing-a-disaster-recovery-plan および https://cloud.google.com/solutions/disaster-recovery-cookbook   非同期データベースミラーリング InterSystems IRIS データプラットフォームのデータベースミラーリングは、GCP ゾーンとリージョン間のデータレプリケーションを非同期に実行する堅牢な機能を提供しているため、災害復旧計画の RTO と RPO の目標をサポートする上で役立ちます。 非同期ミラーメンバーの詳細については、こちらを参照してください。 前の高可用性のセクションと同様に、クラウドロードバランサーは、自動 IP アドレスフェイルオーバーを仮想 IP（VIP のような）機能に提供して、前の「 内部ロードバランサー 」セクションで述べたのと同じ mirror_status.cxw ヘルスチェックステータスページを使用してDR 非同期ミラーリングも提供することができます。 この例では、DR 非同期フェイルオーバーミラーリングは、InterSystems IRIS デプロイメントが稼働しているゾーンやリージョンに関係なく、上流システムとクライアントワークステーションに単一のエニーキャスト IP アドレスを提供する GCP Global Load Balancing サービスの導入とともにカバーされるようになります。 GCP のメリットの 1 つは、ロードバランサーがソフトウェアによって定義されたグローバルリソースであり、特定のリージョンにバインドされないことです。 このため、そしてインスタンスやデバイスベースのソリューションでないため、リージョン全体で単一のサービスを活用できる特有の機能が可能になります。 単一のエニーキャスト IP を使用した GCP Global Load Balancing の詳細については、こちらを参照してください。   上の例では、3 つすべての InterSystems IRIS インスタンスは GCP Global Load Balancer に渡され、ゾーンやリージョンに関係なく、プライマリミラーとして動作しているミラーメンバーにのみトラフィックが転送されるようになります。   * * * シャードクラスタ InterSystems IRIS には包括的な機能セットが含まれており、ワークロードの性質とワークロードが直面している特定のパフォーマンスの課題に応じて、単独または組み合わせて適用できます。 機能セットの 1 つであるシャーディングは、データとその関連するキャッシュの両方を複数のサーバーに分割することで、クエリとデータの取り込みを行うための柔軟で安価なパフォーマンスの拡張を行いながら、リソースを非常に効率的に利用することで、インフラストラクチャの価値を最大化することができます。 InterSystems IRIS のシャードクラスタは、広範なアプリケーション、特に以下の 1 つ以上の項目を含むワークロードを使用するアプリケーションに、大きなパフォーマンスのメリットを提供できます。 大量または高速データ取り込み、またはその両方。 比較的大規模なデータセット、大量のデータを返すクエリ、またはその両方。 ディスク上の大量のデータをスキャンしたり、重要な計算作業を伴ったりなど、大量のデータ処理を行う複雑なクエリ。 こういった要因は、それ自体でシャーディングから得られる可能性のある利益に変化をもたらしますが、これらが組み合わさった場合はそのメリットがさらに高まる可能性があります。 たとえば、大量データの迅速な取り込み、大規模なデータセット、および大量のデータを取得して処理する複雑なクエリという 3 つのすべての要因が組み合わさった場合、今日の分析ワークロードの多くでシャーディングを利用する価値が非常に高くなります。 これらの特性はすべてデータに関係しています。InterSystems IRIS のシャーディングの主な機能は、データボリュームに対して拡張することだからです。 ただし、シャードクラスタには、一部またはすべてのデータ関連の要因が伴うワークロードで、多数のユーザーから非常に高いクエリ量が発生する場合に、ユーザーのボリュームに合わせて拡張する機能も含められます。 シャーディングは、垂直スケーリングと組み合わせることもできます。   運用の概要 シャードアーキテクチャの目的は、データとそれに関連するキャッシュを複数のシステム間で分割することにあります。 シャードクラスタは、データノードと呼ばれる複数の InterSystems IRIS インスタンス間で、大量のデータベーステーブルを物理的に水平に（行ごとに）分割します。その一方で、アプリケーションが任意のノードを介してこれらのテーブルに透過的にアクセスし、1 つの論理的な結合としてデータセット全体を捉えられるようにします。 このアーキテクチャには、次の 3 つのメリットがあります。   並列処理: クエリは、データノードで並列に実行され、結果は、アプリケーションが接続されたノードによってマージ、結合され、完全なクエリ結果としてアプリケーションに返されます。多くの場合、実行速度が大幅に改善されます。 分割されたキャッシュ: 単一のインスタンスのキャッシュをデータセット全体で使用するのではなく、各ノードにそれが格納するシャーディングされたテーブルのデータ分割専用の独自キャッシュがあります。そのため、キャッシュのオーバーフローやパフォーマンスを低下するディスク読み取りのリスクが大幅に軽減されます。 並列読み込み: データをデータノードに並列に読み込めるため、取り込みワークロードとクエリワークロード間のキャッシュとディスクの競合が緩和され、両者のパフォーマンスが改善されます。   InterSystems IRIS のシャードクラスタの詳細については、こちらを参照してください。   シャーディングの要素とインスタンスタイプ シャードクラスタは、少なくとも 1 つのデータノードと、特定のパフォーマンスやワークロード要件に必要な場合は、オプションの数の計算ノードで構成されます。 これら 2 つのノードタイプは単純なビルディングブロックで、シンプルで透過的かつ効果的なスケーリングモデルを提供しています。   データノード データノードはデータを格納します。 物理レベルでは、シャーディングされたテーブル [1] のデータはクラスタ内のすべてのデータノードに分散され、シャーディングされていないテーブルのデータは、最初のデータノードのみに物理的に格納されます。 この区別は、ユーザーに透過的です。最初のノードのストレージ消費量はほかのノードに比べてわずかに高いことがあるという唯一の例外がありますが、シャーディングされたテーブルデータは通常、シャーディングされていないテーブルデータをわずかに上回る程度であるめ、この差は無視することができます。 シャーディングされたテーブルデータは、必要に応じて、通常は新しいデータノードを追加した後で、クラスタ全体で再調整できます。 この調整により、分散するデータが均等になるようにノード間でデータの「バケツ」が移動されます。 論理レベルでは、シャーディングされていないテーブルデータとシャーディングされたテーブルのすべてのデータの結合はあらゆるノードから可視状態であるため、クライアントは接続しているノードに関係なく、データセット全体を見ることができます。 メタデータとコードも、すべてのデータノードで共有されます。 シャードクラスタの基本的なアーキテクチャ図は、クラスタ全体で均一に見えるデータノードで構成されています。 クライアントアプリケーションは、任意のノードに接続でき、データがローカルであるかのように処理されます。 [1] 便宜上、ドキュメントを通して「シャーディングされたテーブルデータ」という用語によって、シャーディングとしてマークされる、シャーディングをサポートするデータモデルの「エクステント」データを表しています。 「シャーディングされていないテーブルデータ」と「シャーディングされていないデータ」は、シャーディング可能なエクステントにあり、そのようにマークされていないデータ、またはシャーディングをまだサポートしていないデータモデルのデータを指します。     データノード 低レイテンシが必要となる高度なシナリオでは、潜在的にデータの一定した流入が発生する可能性があるため、クエリを処理するための透過的なキャッシング層を提供するために計算ノードを追加することができます。 計算ノードはデータをキャッシュします。 各計算ノードは、対応するシャーディングされたテーブルデータをキャッシュするデータノードに関連付けられています。さらに、そのデータに加え、クエリを満たすために必要に応じてシャーディングされていないテーブルデータもキャッシュします。     計算ノードは物理的にデータを格納せず、クエリ実行をサポートすることを目的としているため、メモリと CPU に重点を置いてストレージを最小限に抑えるなどによって、そのハードウェアプロファイルをニーズに合わせて調整することができます。 取り込みは、ドライバー（xDBC、Spark）で直接、または計算ノードで「ベア」アプリケーションコードが実行されるときにシャーディングマネージャーコードによって暗黙的にデータノードに転送されます。   * * * シャードクラスタの図説 シャードクラスタのデプロイにはさまざまな組み合わせがあります。 以下の概要図は、最も一般的なデプロイメントモデルを説明しています。 これらの図には、ネットワークゲートウェイと詳細は含まれておらず、シャードクラスタコンポーネントのみに焦点が当てられています。   基本的なシャードクラスタ 以下の図は、単一のリージョンと単一のゾーンにデプロイされた 4 つのデータノードを持つ最も単純なシャードクラスタです。 クライアント接続をシャードクラスタノードに分散するために、GCP Cloud Load Balancer が使用されています。     この基本モデルでは、単一の仮想マシンとそれに接続された SSD 永続ストレージに GCP が提供するものを超える回復力や高可用性は提供されていません。 インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィックとシャードクラスタ通信間の帯域幅分離の両方を提供するには、2 つのネットワークインターフェイスアダプターを個別に用意することをお勧めします。   高可用性を備えた基本的なシャードクラスタ 以下の図は、単一のリージョンにデプロイされた 4 つのミラーデータノードとゾーン間で分岐した各ノードのミラーを持つ最も単純なシャードクラスタです。 クライアント接続をシャードクラスタノードに分散するために、GCP Cloud Load Balancer が使用されています。 高可用性は、リージョン内のセカンダリゾーンで同期的に複製されたミラーを維持する InterSystems のデータベースミラーリングを使用して提供されています。 インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィック、シャードクラスタ通信、およびノードペア間の同期ミラートラフィック間の帯域幅分離を提供するには、3 つのネットワークインターフェイスアダプターを個別に用意することをお勧めします。     このデプロイメントモデルでは、このドキュメントの前のセクションで説明したミラーアービターも導入されています。   個別の計算ノードを持つシャードクラスタ 以下の図は、大規模なユーザー/クエリ同時実行向けに、個別の計算ノードと 4 つのデータノードを持つシャードクラスタを拡張しています。 Cloud Load Balancer サーバープールには、計算ノードのアドレスのみが含まれます。 更新とデータの取り込みは、以前と同様にデータノードに直接更新され続け、超低レイテンシパフォーマンスを維持し、リアルタイムデータ取り込みによるクエリ/分析ワークロード間のリソースの干渉と輻輳を回避します。 このモデルでは、計算/クエリと取り込みを個別にスケーリングできるようにリソースの割り当てを微調整することで、計算またはデータをスケーリングするためだけにリソースを不要に無駄にする代わりに、必要なときに「ジャストインタイム」でリソースを最適化し、経済的でありながらも単純なソリューションを維持することができます。 計算ノードは GCP 自動スケールグループ（自動スケーリング）を非常に簡単に使用できるため、負荷の増減に基づいて、管理されたインスタンスグループへのインスタンスの追加または削除を自動的に実行することができます。 自動スケーリングは、負荷が高まるとインスタンスグループにインスタンスを追加し（アップスケーリング）、インスタンスのニーズが低下するとインスタンスを削除（ダウンスケーリング）します。 GCP 自動スケーリングの詳細については、こちらを参照してください。     自動スケーリングを使用すると、クラウドベースのアプリケーションは、トラフィックの増加を適切に処理し、リソースのニーズが低下するとコストを削減するのに役立ちます。 自動スケーリングポリシーを定義するだけで、オートスケーラーは、測定された負荷に基づいて、自動的にスケーリングを実行します。   * * * バックアップ操作 バックアップ操作には、いくつかのオプションがあります。 InterSystems IRIS を使用した GCP デプロイメントでは、次の 3 つのオプションを使用できます。 最初の 2 つのオプションは、以下で説明するとおり、スナップショットを作成する前にデータベースによるディスクへの書き込みを一時停止し、スナップショットに成功したら更新を再開するというスナップショットタイプの手順を使用しています。 いずれかのスナップショット方式を使用してクリーンなバックアップを作成するには、次のおおまかな手順を実行します。 データベースの External Freeze API 呼び出しにより、データベースへの書き込みを一時停止する。 OSとデータディスクのスナップショットを作成する。 External Thaw API 呼び出しにより、データベースの書き込みを再開する。 バックアップファシリティはバックアップ場所にアーカイブする。 External Freeze/Thaw API に関する詳細は、こちらを参照してください。   注意: このドキュメントにはバックアップのサンプルスクリプトは含まれていませんが、InterSystems 開発者コミュニティに掲載される例を定期的に確認してください。 www.community.intersystems.com   3 つ目のオプションは、InterSystems Online のバックアップです。 これは、非常にシンプルな使用事例とインターフェイスを備えたより小規模なデプロイメント向けのエントリーレベルのアプローチです。 ただし、データベースのサイズが大きくなるにつれ、スナップショットテクノロジーを使った外部バックアップがベストプラクティスとして推奨されます。外部ファイルのバックアップ、より高速な復元時間、エンタープライズ全体のデータビューと管理ツールなどのメリットがあります。 クリーンで一貫したバックアップを確保するために、整合性チェックなどの追加手順を定期的に追加することができます。 どのオプションを使用するかという決定ポイントは、組織の運用要件とポリシーによって異なります。 さまざまなオプションをさらに詳しく検討するには、InterSystems にご相談ください。   GCP 永続ディスクスナップショットのバックアップ バックアップ操作は、GCP gcloud コマンドライン API と InterSystems External Freeze/Thaw API 機能を使用して実行できます。 これにより、本来の 24 時間 365 日の運用弾力性とクリーンな定期バックアップの保証が可能になります。 GCP 永続ディスクスナップショットの管理と作成および自動化の詳細については、こちらを参照してください。   論理ボリュームマネージャー（LVM）のスナップショット 別の方法として、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VM そのものにバックアップエージェントを展開し、論理ボリュームマネージャ（LVM）のスナップショットと組み合わせてファイルレベルのバックアップを活用することができます。 このモデルには、Windows または Linux ベースの VM をファイルレベルで復元できるというメリットがあります。 このソリューションで注意すべき点は、GCP やほとんどの IaaS クラウドプロバイダはテープメディアを提供しないため、すべてのバックアップリポジトリは、短期アーカイブ用のディスクベースであり、長期保管（LTR）には BLOB またはバケットタイプの低コストストレージを活用できるということです。 このモデルを使用する場合は、ディスクベースのバックアップリポジトリを最も効率的に使用できるように、重複除去テクノロジーをサポートするバックアップ製品を使用することを強くお勧めします。 こういったクラウド対応のバックアップ製品には、Commvault、EMC Networker、HPE Data Protector、Veritas Netbackup などさまざまな製品があります。 注意: InterSystems では、これらの製品の比較検証や推奨は行っておりません。 個々のお客様の責任の下、バックアップ管理ソフトウェアをお選びください。   Online Backup 小さなデプロイメントでは、組み込みの Online Backup ファシリティもオプションとして考えられます。 InterSystems のデータベースオンラインバックアップユーティリティは、データベース内のすべてのブロックをキャプチャしてデータベースファイルにデータをバックアップし、出力をシーケンシャルファイルに書き込みます。 この、InterSystems 独自のバックアップメカニズムは、本番システムのユーザーにダウンタイムを引き起こさないように設計されています。 Online Backup の詳細については、こちらを参照してください。 GCP では、オンラインバックアップが完了した後、バックアップ出力ファイルとシステムで使用中のほかのすべてのファイルを、その仮想マシンインスタンスの外部にあるほかのストレージの場所にコピーする必要があります。 これには、バックアップ/オブジェクトストレージが適しています。 GCP Storatge バケットを使用するには、2 つのオプションがあります。 gcloud スクリプト API を直接使用して、新しく作成したオンラインバックアップ（とほかの非データベース）ファイルをコピーして操作する。詳細は、こちらを参照してください。 Cloud Storage バケットはオブジェクトストレージですが、ストレージバケットをファイルシステムとしてマウントし、永続ディスクと同様に使用する。 Cloud Storage FUSE を使って Cloud Storage バケットをマウントする詳細については、こちらを参照してください。    

Windows と Mac で InterSystems IRIS 2019.1 (および 2018.1.2) の SSL/TLS 設定に認証局 (CA) の証明書を簡単に追加する新しい方法ができました。  IRIS にオペレーティングシステムの証明書ストアを使用することを要求するために、 %OSCertificateStore を "信頼された証明書機関 X.509 証明書を含むファイル" のフィールドに入力します。   以下はポータルでそれを実行する方法を示した画像です。  また、これについて説明した[ドキュメントへのリンクはこちら](https://irisdocs.intersystems.com/irislatestj/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_createedit)です。  "信頼された証明書機関の証明書を含むファイル" のオプションの中を探してください。 必要な操作はこれだけです！  これで、OS 証明書ストアに載っているすべての CA の証明書をこの設定に使用することができます。

これは InterSystems FAQ サイトの記事です。 クライアントからターミナルにログイン（接続）できない時、ターミナル接続を可能にするサービスが有効になっていないことが原因として考えられます。 ターミナル接続を可能にするサービスが有効になっていないことが原因として考えられます。 管理ポータル ：[ホーム] > [システム管理] > [サービス] 有効になっていない場合は、リンクをクリックしてサービス定義編集画面を開き、"サービス有効"にチェックを入れて保存します。 もう一つの原因としてはOSのファイアウォールによりターミナル接続が遮断されている場合が考えられます。 リモートでターミナル接続される場合はファイアウォールの設定を無効にしてお使い下さい。

これはInterSystems FAQ サイトの記事です。 LAST_IDENTITY()　SQL関数を使用すると取得できます。※ この関数は、埋め込み SQL または ODBC 利用時に使用できます。ダイナミック SQL、SQL シェル、または管理ポータルの SQL インタフェースによる値には設定されません。 簡単な埋め込み SQL での例をご紹介します。 Class Test.SQL{ClassMethod GetLastID() As %Integer [ SqlProc ]{ //ソースコードコンパイル時に存在しないテーブルがあるので実行時にコンパイル #SQLCompile Mode=Deferred //テーブル作成 &sql(CREATE TABLE Sample.Students ( StudentName VARCHAR(30), StudentAge INTEGER, StudentID IDENTITY)) //データ登録 &sql(INSERT INTO Sample.Students (StudentName,StudentAge) values('生徒１',16)) &sql(INSERT INTO Sample.Students (StudentName,StudentAge) values('生徒２',17)) //最後に更新したIDを取得 &sql(SELECT LAST_IDENTITY() into :lastid from Sample.Students) return lastid}} ストアドプロシージャとして実行した結果は以下の通りです（管理ポータルで実行しています）。 詳細は下記ドキュメントページもご参照ください。LAST_IDENTITY【IRIS】LAST_IDENTITY

これは、InterSystems FAQ サイトの記事です。 小数点桁数を指定しない単純な整数への切り上げ・切り捨ては、それぞれ、以下の関数で実行できます。 (SQL関数) 切り上げ：CEILING切り捨て：FLOOR (ObjectScript関数) 切り上げ： $system.SQL.Functions.CEILING()切り捨て： $system.SQL.Functions.FLOOR() USER>write $system.SQL.Functions.CEILING(168.5)169USER>write $system.SQL.Functions.FLOOR(168.5)168 ※バージョン2021.1以前は以下のメソッドを使用します。 　切り上げ： $system.SQL.CEILING()　切り捨て： $system.SQL.FLOOR() 小数桁数を指定して切り上げ・切り捨てを行いたい場合は、2つの関数を組み合わせ、以下のようなメソッドを作成して対応します。 Class Sample.Utility Extends %RegisteredObject { ClassMethod Floor(val As %Numeric, scale As %Integer) As %Numeric [ Language = objectscript ] { Set multi=$select(scale>0:scale-1,1:scale) Set tmpval=$system.SQL.Functions.FLOOR(val*(10**multi)) Quit tmpval*(10**-multi) } ClassMethod Ceiling(val As %Numeric, scale As %Integer) As %Numeric [ Language = objectscript ] { Set multi=$select(scale>0:scale-1,1:scale) Set tmpval=$system.SQL.Functions.CEILING(val*(10**multi)) Quit tmpval*(10**-multi) } } 【実行例】 0.122 を小数点第3位で切り上げる USER>write ##class(Sample.Utility).Ceiling(0.122,3).13 0.122 を小数点第3位で切り捨てる USER>write ##class(Sample.Utility).Floor(0.122,3).12