もっと賢く使えるテーブル統計

この記事では、2025.2リリースで導入された、IRIS SQL処理の重要な要素、InterSystems IRISのテーブル統計処理の大きな改善について紹介します。 まず最初に、テーブル統計とは何か、どのように利用されるのか、そしてなぜ今回の改善が必要だったのかを簡単におさらいします。 その後、テーブル統計を収集・保存するための新しいインフラの詳細を掘り下げてから、この変更が実際にアプリケーションにどのような影響を与えるのかを詳しく見ていきます。 最後に、新しいモデルで可能になったパターンに関する追加の注意点をいくつか紹介し、今回の初期リリースに続く次のフェーズに期待をつなげます。

SQLを使わないのに、この記事を読む必要があるのか？もっともな質問ですが、この記事には知っておくと役立つ情報があるかもしれません。 IRISのより高いレベルの機能、特にInteroperabilityは内部でIRIS SQLを活用しており、動作の一部変更により、新しいメンテナンスタスクを有効にしたほうがよい場合があります。 以下の「テーブル統計の自動収集」セクションをご覧ください。

テーブル統計の基本

SQLはStructured Query Language（構造化照会言語）の略です。 SQLは、どのようにしたいか（クエリ結果を取得するコード）ではなく、何をしたいか（クエリ）を表現する言語です。 結果をどのように取得するかはデータベースのクエリエンジンが判断し、最適と考えられる実行計画を選択して応答します。 最適な実行計画を決定するために、クエリオプティマイザーが必要とするのは大きく分けて2つです。1つは、データが格納されている場所や利用可能なインデックスなど、テーブル構造に関する情報。そしてもう1つは、テーブル内のデータ自体に関する情報、つまりテーブル統計です。 これらのテーブル統計には、テーブルの推定サイズや各フィールドの選択性などの情報が含まれます。選択性は、特定のフィールド値がテーブルで平均的にどの程度の割合を占めるかを示します。 これらは、クエリの実行計画を適切に判断するうえで非常に重要です。 例えば、特定の郵便番号に住む女性顧客数を調べる必要がある場合、性別または郵便番号のインデックスのどちらから始めるかを選ぶことができます。 性別のインデックスの選択性はだいたい50%ですが、郵便番号のインデックスは1%以下の場合もあり、後者から検索を始めたほうが、参照する行をより速く絞り込むことができます。

テーブル構造は当然ながらアプリケーションの一部であり、アプリケーションコードとしてパッケージ化できますが、テーブル統計については必ずしもそうとは限りません。 前の例が小さな書店向けアプリケーションの場合、そのフィールドの選択性の値はアプリケーションがデプロイされるすべての書店でほぼ同じである可能性が高いです。しかし、それが電子カルテシステムの場合、性別フィールドの選択性は産科クリニックと一般診療所で異なり、郵便番号の数（したがってその選択性）も病院がサービスを提供する地域の規模によって変わります。 つまり、統計やそれに基づくクエリ実行計画は、アプリケーションがデプロイされる環境の実際のデータに基づいて作成される必要があります。

IRISでのテーブル統計（2025.2以前）

IRISでは、テーブル統計は従来、クラス定義の一部として保存されてきました。 これにはいくつかの欠点があります。

• 前述の通り、データの分布は、アプリケーションをデプロイする環境によって大きく異なる可能性があります。 これは、推定テーブルサイズや選択性だけでなく、外れ値情報やヒストグラムなどのより高度な統計情報においてはさらに顕著です。
• アプリケーションの更新版をデプロイする際には、通常、既存の統計を保持することをお勧めします。ただし、それらの統計がデプロイ先環境の実際のデータに基づいている場合に限ります。 統計がコードの一部として保存されている場合は、より厄介です。もちろん、開発環境やテスト環境のテーブル統計を誤って顧客システムにデプロイしたくはありません。
• アプリケーションコードが読み取り専用データベースの形でデプロイされている場合や、IRISシステムライブラリ（例えば、Interoperabilityメッセージ）の一部として含まれている場合、それらのテーブルの統計を更新する適切な方法はありません。

上記の内容についてもう少し詳しく知りたい場合は、こちらの過去の記事をご覧ください。 これらは、IRISにおけるテーブル統計の管理方法を再設計することにした理由の一部です。新しいインフラストラクチャは、InterSystems IRIS 2025.2に組み込まれています。

変更内容

収集統計 vs 固定統計

前の例で説明した通り、統計をアプリケーションコードの一部として保存するのは、極めて限定された管理下の環境でのみ理にかなっています。 ほとんどの場合、統計はコードの一部として固定するよりも、収集元のデータと一緒に保持する方が望ましいため、新しいモデルではその方法を採用しています。 常に実際のデータに基づき、エクステントインデックス（テーブルデータに関する他のレジストリ形式の情報と共に格納されるグローバルで、エクステントとも呼ばれます）に格納される収集統計と、アプリケーション開発者によってクラス定義にハードコーディングされ、実際のデータに基づく場合もあれば、ある程度の推定に基づく場合もある固定統計とを区別しています。 言うまでもなく、固定統計は2025.2以前のテーブル統計管理モデルに対応しています。

新しいCOLLECT STATISTICS FOR TABLE t コマンド（既存のTUNE TABLEコマンドと100%同義で、用語を標準化しただけです）を使用して、テーブル内の現在のデータに基づいた新しい統計を作成してください。 テーブル統計は非常に小さいため、以前の統計を上書きしません。新しい統計セットを保存し、古い統計はデフォルトのパージ条件を満たすまで、あるいは明示的にパージされるまで、参考情報としてすぐに使えるように保存します。 固定モデルに切り替える場合は、ALTER TABLE t FIX STATISTICSを使用してクラス定義に収集統計を保存できます。 これらの統計がターゲット環境に適合することを確信でき、静的モデルを使用する場合は、アプリケーションパッケージング手順に含めることができます。

デフォルトでは、固定統計は収集統計よりも優先されます。 これにより後方互換性が確保され、最終的な判断は引き続き開発者が行えるようになっています。 実際のところ、たとえ1つのフィールドに固定統計が設定されているだけでも、収集統計は無視されます。また、固定統計がないフィールドについては、そのフィールドのデータ型に基づいた安全な推定値にフォールバックします。 固定統計を削除せずに収集統計でテストしたい場合は、クエリテキストのFROM句に%NOFIXEDSTATSヒントを含めて収集統計のみに基づいたクエリ実行計画を取得するか、ALTER TABLE t SET RUNTIME IGNOREFIXEDSTATS = TRUEを使用してテーブルレベルでこの動作を設定できます。

テーブル統計の自動収集

収集統計の導入により、冒頭で述べたパッケージングやデプロイ時の多くの不便さがすでに解消されています。 しかし、顧客において最も一般的な問題のひとつである、最新の統計の欠如には十分対応できていません。 前述の通り、正確な統計は特定のデータ分布に最適なクエリ実行計画を取得するために重要です。 統計をまったく収集していない場合、オプティマイザーはフィールドのデータ型に基づいた大まかなデフォルト値を使用しますが、すべてのケースにおいてこれらがアプリケーション固有の条件を正しく反映するとは限りません。 2021.2 以降、IRISは統計情報がない高速サンプリング手法の対象となるテーブルに対して、クエリ実行時に自動で統計を収集するようになりましたが、これは一度限りで、テーブルにまだ代表的なデータが格納されていない場合に実行される可能性があります。 統計が適切なタイミングで収集されていた場合でも、データ分布は時間の経過とともに変化します（特にヒストグラム）。そのため、古い統計に基づいたクエリ実行計画が最適でないことが顧客の間で非常に多く見られます。

2025.2では、新しいシステムタスクを導入します。このタスクは夜間メンテナンスの時間帯に実行され、各ネームスペースごとに、統計がまったく存在しないテーブル、最新の統計が無効化されているテーブル（例えば、テーブルのストレージ定義を変更して再コンパイルした場合）、または統計収集以降にテーブルデータの少なくとも25%が変更されたテーブル（概算で、DML 操作によるテーブルの合計ROWCOUNTに基づいて測定されます）を対象として処理を行います。 統計はこれらのテーブルに対して1つずつ、またはメンテナンスタスク（構成可能）の最大期間に到達するまで収集されます。 その他の構成オプションには、固定統計があるテーブルを対象にするかどうか（デフォルトではオン）、リモートストレージにマッピングされているテーブルを対象にするかどうか（デフォルトではオフ）、および高速サンプリング手法の対象外のテーブルを含めるかどうか（デフォルトではオフ）があります。 必要であれば、個々のテーブルにSKIPAUTOMATICSTATSCOLLECTIONクラスパラメーター（または同等のランタイムフラグ）を使用するよう設定すると、このシステムタスクによりスキップされます（この新しいフラグは既存のAutoTuneの動作にも影響します）。

2025.2では、これによる実際のシステムのIOパターンへの影響を顧客とともに評価したいため、このシステムタスクはデフォルトでオフになっています。今後のリリースでデフォルトでオンに切り替える前に必要な調整を行えるよう、システムタスクを有効化していただき、システム負荷に関するご意見をお寄せいただくことをお勧めします。 その時点で、クエリ処理中に発動する可能性のある従来のAutoTuneの動作は廃止される予定です。

テーブル統計の手動収集はもちろん従来どおりサポートされており、大規模なデータロードやパージ後にCOLLECT STATISTICSを実行することは、変わらず推奨されるベストプラクティスです。

これはあなたのアプリケーションにとって何を意味するのか？

IRIS 2025.2にアップグレードするSQLアプリケーションに対しては、何も変更されないように新しいモデルは慎重に設計されています。 事前に存在する統計は固定統計として扱われるようになり、バックグラウンドで自動的に収集される統計よりも優先されます。 新しいモデルにアップグレードするお客様には、以下の3つの推奨事項を検討することをお勧めします。

アップグレード後に固定統計を削除する

アプリケーション、または任意のテーブルにアップグレード前の統計が存在している場合（ベストプラクティスに従っていればすべてのテーブルが該当します）、それらの統計を削除することを検討してください。 アップグレード後、それらの統計は固定統計と見なされ、明示的（例えば、TUNE TABLEを呼び出すカスタムスクリプトにより収集）または暗黙的に収集する統計よりも優先されます。 固定テーブル統計は、新しいALTER TABLE t DROP FIXED STATISTICSコマンドまたは同等のALTER SCHEMA s DROP FIXED STATISTICSを使用して削除できます。 ご希望であれば、%NOFIXEDSTATSヒントを使用して、事前に個々のクエリへの影響を確認することもできます。

現在のクエリ実行計画を維持するために、事前定義された統計をそのまま残す必要があり、データ分布に変化が見込まれない場合にのみ、固定統計を使用することが適切です。

システムクラスの統計を検討する

新しい収集統計モデルは、読み取り専用データベースに定義が存在するテーブルに適用できることに注意してください。これには、Ens.MessageHeaderなどのIRISシステムテーブルも含まれます。 これらのテーブルでは、以前はテーブル統計の維持が実用的でなかったり、ほぼ不可能でした。しかし、今後は収集統計が重要になり、システムタスクを有効化することで、自動的に統計が維持されるようになります。 Interoperability本番環境や、内部でSQLを利用している可能性のあるその他のIRISインフラストラクチャを使用する場合、アップグレード後は検索などの操作のパフォーマンスに注意し、統計を手動で収集するか、システムタスクを有効にすることをお勧めします。

メッセージ検索を使用した際、新しいモデルを採用した後にクエリのパフォーマンスが大幅に改善することが分かりました。これは、以前はおおまかなデフォルト値に頼っていた統計が、より現実的な選択性やその他の統計を使用できるようになったためです。 そのため、これらのシステムテーブルに含まれていた固定統計は削除されました。

バージョン間でインポートやエクスポートを行う際に注意する

テーブル定義を/exportselectivity=1フラグ（デフォルト）を使ってエクスポートすると、統計は固定統計および最新の収集統計の両方に対応した新しい形式で含まれますが、以前のバージョンとの互換性はありません。 以前のリリースを実行しているIRISへのインポートに対応するには、必要に応じて/exportversion=2025.1または/exportselectivity=0を使用してください。 この形式でエクスポートされた収集統計は、クラス定義のexportファイルに含まれていても、自動的に固定統計には変換されず、収集統計のままインポートされることに注意してください。 これらの点を考慮して、デプロイモデルに適した情報が確実に追跡されるよう、ソース管理戦略を見直すことをお勧めします。 クラス定義をインポートする際に使用できる、対称的な/importselectivityフラグにも注意してください。

$SYSTEM.SQL.Stats.TableクラスのImport()メソッドとExport()メソッドは、両方の統計タイプを適切に区別できるよう、追加の型引数に対応するよう拡張されました。 詳細については、クラス参照をご覧ください。

今後の作業

このリリースには、新しいモデルを活用するためのすべての関連インフラストラクチャが含まれています。 軽微な利便性向上は別として、次回リリース（おそらく2025.3）では、以下の2つのアップデートを予定しています。

自動収集タスクの自動化

前述の通り、夜間バッチの時間帯にテーブル統計を自動収集する新しいシステムタスクを導入しましたが、アップグレード後の予期せぬI/O負荷を避けるため、無効のままになっています。 次回リリースでは、顧客が既に有効化していない場合、デフォルトでこれをオンにする予定です。

よりスマートなサンプルサイズ

高速ブロックサンプリングアルゴリズムは、大規模テーブルの選択性が非常に高いフィールドにおいて、選択性を過大評価してしまう場合があります。そのため、最適であったとしても、オプティマイザーが対応するインデックスを使用しないことがあります。 サンプリング間での変動が大きい場合に、サンプルサイズを動的に調整するアルゴリズムを実装しています。 この変更は、前述の全体的なインフラ変更の影響を受けず、ほぼ独立して行われます。

あなたの体験をシェアしてください

この変更のリリースを長い間待ち望んでおり、IRIS 2025.2に含まれることとなり、本当にうれしく思っています。 この変更は多様な環境で十分にテストしており、新しいインフラストラクチャの堅牢性には自信がありますが、ネームスペースマッピングやコードパッケージングなど、特にカスタマイズされたデプロイ手法には影響を及ぼす可能性があることを理解しています。 そのため、皆様からのご意見をぜひお待ちしております。新しいインフラストラクチャによって作業がより快適になることを期待しています。