メインコンテンツまでスキップ
バージョン: 4.1 Preview

PhoenixAI バージョン 26.2

26.2.0​

リリース日: 2026年9月16日

アップグレードと互換性​

v26.2 は v4.1 からのアップグレードをサポートしています。アップグレードが想定どおりに進まなかった場合は、v4.1 の最新パッチリリースにロールバックできます。

アップグレードする前に、このセクションをお読みください。6 つのデフォルト値が変更され、1 つの設定オプションが削除され、クラウドネイティブ（共有データ）主キーテーブルでは 1 つのテーブルプロパティが受け付けられなくなりました。各項目には、その動作を制御する設定と、変更前後のデフォルト値を記載しています。ここに記載されている内容は、アップグレード時に特別な操作をしなくても自動的に有効になります。

既存のテーブルは、アップグレードによって書き換えられたり再分散されたりすることはありません。

  • グローバル遅延マテリアライゼーションがデフォルトで有効になりました。

    ネイティブテーブルスキャンにおいて、述語で使用されないカラムは、述語評価と同時にではなく、評価後に読み込まれるようになります。選択性の高いクエリでは読み込むデータ量が大幅に減少しますが、ほとんどの行を返すクエリでは行位置に対する 2 回目のパスが追加されます。これに伴いクエリプロファイルの形も変わるため、v4.1 で保存したプロファイルとそのまま比較することはできません。この動作はセッション変数 enable_global_late_materialization によって制御され、デフォルト値は false から true に変わります。また、クエリごとにオプティマイザが判断できるようにする enable_global_late_materialization_cost_based も併せて導入されます。

  • JDBC 結合プッシュダウンがデフォルトで有効になりました。

    JDBC 外部テーブル間の結合は、PhoenixAI が両方のテーブルを読み込んでローカルで結合するのではなく、ソースデータベース側で実行され、結果のみが返されるようになります。これにより、多くの場合は処理が大幅に高速化され、転送されるデータ量も大幅に削減されます。一方で処理の一部がソースシステム側に移るため、そのシステムのキャパシティに余裕がない場合やトランザクション処理のトラフィックと共有されている場合は、事前に確認しておく価値があります。この動作を制御するセッション変数は、本リリースで新たに追加された enable_jdbc_join_push_down で、デフォルトは true です。この変数は SHOW VARIABLES には表示されませんが、セッション単位でもグローバルにも設定できます。

  • Avro データは、JNI リーダーではなくネイティブリーダーで読み込まれるようになりました。

    これは Hive および Iceberg テーブル内の Avro ファイルに影響します。デフォルトが変更される前に、JNI リーダーの CHAR の扱いはネイティブリーダーに合わせて調整済みであるため、結果は同一になるはずです。ただし性能特性は異なるため、JNI リーダーを前提にチューニングされたワークロードは再計測することをお勧めします。セッション変数 avro_use_jni_reader のデフォルトは true から false に変わります。以前のリーダーに戻すには、true に設定し直してください。

  • Iceberg のスキャンプランニングは、デフォルトでローカルに実行されるようになりました。

    プランニングはクエリごとに選択されるのではなく、コーディネーター上で行われるようになります。これによりプランニング時間の予測が可能になります。特に、マニフェストリストが大きいテーブルでは、自動選択によって遅い方のパスがまれに選ばれてしまうことがあったため、この変更が重要になります。セッション変数 plan_mode のデフォルトは auto から local に変わります。以前の動作に戻すには plan_mode = auto を設定してください。

  • クラウドネイティブ主キーテーブルは、クラウドネイティブ永続インデックスのみを使用するようになりました。

    これらのテーブルでは、LOCAL 永続インデックスがサポートされなくなります。既存テーブルのメタデータは、アップグレード後に FE がロードされる際に自動的にクラウドネイティブインデックスへ正規化されるため、移行作業は不要です。ただし、クラウドネイティブ（共有データ）主キーテーブルに明示的に設定された persistent_index_type = LOCAL は無視されるようになり、新規テーブルではこの設定自体が拒否されます。

  • 水平コンパクション（Horizontal compaction）は、ローカルデータキャッシュを埋めなくなりました。

    水平コンパクションは、入力の各バイトをちょうど 1 回だけ読み込み、その直後に入力ロウセットを置き換えます。そのため、このデータをキャッシュしてもクエリでよく使われるホットなデータを追い出してしまうことがほとんどで、さらにキャッシュミスのたびにローカルディスクへのインラインの書き込みが発生していました。これを取りやめることで、水平コンパクションは他のフルスキャン型のバックグラウンド処理と足並みが揃うことになります。新しい BE 設定項目 lake_enable_horizontal_compaction_fill_data_cache のデフォルトは false です。以前の動作に戻すには true に設定してください。カラムグループごとに入力を 1 回スキャンする垂直コンパクションは変更されていません。

  • インデックス構築時に、ベクトルインデックスキャッシュへのデータ投入が行われなくなりました。

    インデックスの構築ではキャッシュのウォームアップが行われなくなるため、構築処理によってクエリが利用しているキャッシュデータが追い出されることはありません。クエリ実行時のキャッシュ動作は変わらず、キャッシュミス時にはクエリをブロックすることなく非同期にロードできます。新しい BE 設定項目 enable_vector_index_cache_on_build のデフォルトは false です。

  • enable_experimental_vector は削除されました。

    ベクトルインデックスは実験的機能ではなくなったため、それを制御していた設定項目も廃止されました。**アップグレードする前に、fe.conf からこの項目を削除してください。**FE はこの設定を認識しません。

  • 主キーテーブル以外のテーブルに対する DELETE は、情報メッセージを返すようになりました。

    文の動作自体は以前とまったく同じですが、これまでのように黙って成功するのではなく、実行内容を説明するようになります。

  • セグメントインデックスのサイドカーファイルが、外部クラスタースナップショットに含まれるようになりました。

    ベクトルインデックスやその他のセグメントレベルのインデックスを保持する .vi および .idx 拡張子のファイルは、これまで外部クラスタースナップショットにコピーされておらず、そのスナップショットから復元したクラスターにはこれらのファイルが含まれていませんでした。ベクトルインデックスを使用していて、復旧を外部クラスタースナップショットに依存している場合は、アップグレード後に新しいスナップショットを取得してください。アップグレード前に取得したスナップショットは不完全です。

  • より厳格な暗黙キャストチェックが利用可能になりましたが、デフォルトでは無効です。

    新しい sql_mode 値 FORBID_INVALID_IMPLICIT_CAST を使用すると、これまで成功していたものの予期しない値を生成していた暗黙キャストが拒否されるようになります。これを有効にすると、v4.1 で実行できていたクエリがエラーになることがありますが、それこそがこの機能の狙いです。既存のワークロードよりも先に、新規のワークロードで有効化を検討することをお勧めします。

新機能​

検索と AI​

  • 共有データクラスターでのベクトル検索

    これまで、ベクトルインデックスは共有なしクラスタ内のテーブルでのみ利用可能であったため、AI ワークロードをウェアハウスの他の部分と同じストレージアーキテクチャ上に置くことができませんでした。v26.2 では、クラウドネイティブ（共有データ）テーブル上でベクトルインデックスの構築、書き込み、読み込みが可能になり、テーブルを再作成しなくても ALTER TABLE で既存のテーブルにインデックスを追加できるようになります。インデックスファイルは、それを所有するタブレットの名前で管理され、共有データのメタデータで追跡されるため、インデックスを削除するとストレージが正確に解放され、範囲分散テーブルでのタブレット分割・マージの際にもインデックスは維持されます。インデックスのバックエンドとしては L2 距離と内積の両方が利用可能で、インデックス作成時に選択します。クエリが HNSW グラフをどの程度探索するかを制御する ef_search は、グローバルに固定された値ではなく、クエリから導出されるようになりました。要求された k と検索対象データのサイズに応じてスケールするため、多くの結果を要求するクエリのためにセッション変数を手動でチューニングする必要がなくなり、結果が不足する検索は、短い結果セットを返すのではなくフォールバックするようになります。また、クエリベクトルは CAST(? AS ARRAY<FLOAT>) を使ってパラメータとしてバインドすることもできるため、アプリケーション側で数百個の浮動小数点数をインライン展開した SQL テキストを組み立てる代わりに、プリペアドステートメントを使用できます。ベクトルインデックスはもはや実験的フラグの配下にはありません - 詳細については、アップグレードと互換性をご覧ください。

  • ベクトルインデックスは非同期に構築されます

    HNSW インデックスの構築は CPU と I/O を大量に消費する処理であり、これをインラインで行うと、大規模な構築処理がそれを引き起こしたデータ取り込み自体を遅くしてしまうことがありました。インデックス構築は、バックグラウンドタスクとして実行されるようになります。構築の並行度、構築処理が消費できる CPU の最大割合、インデックスを構築しない行数のしきい値は、いずれも設定可能です。構築処理はコンパクションを考慮してスケジューリングされるため、両者が同じ I/O を奪い合うことはなく、また書き込みが行われた場所ではなく、そのテーブル自身のウェアハウスで実行されるため、インデックスのメンテナンスをクエリ用のキャパシティから切り離すことができます。information_schema.partitions_meta は各パーティションのインデックスがどのバージョンで構築されたかを報告するため、インデックスが直近の書き込みに追いついているかどうかを確認できます。

  • メモリと再現率（recall）のトレードオフを制御するインデックス量子化

    SQ4、SQ8、PQ の各量子化方式は、再現率の低下と引き換えにインデックスが占有するメモリ量を削減します。量子化されたインデックスは近似ベクトルを格納するため、結果をオプションで元のベクトルに対して精緻化（refine）することができます。この精緻化は、設定によって挙動が変わる暗黙的な動作ではなく、使用している量子化方式に紐づいた、ユーザーが制御可能なオプションになりました。そのため、このトレードオフは後になって判明するのではなく、インデックス作成時に明示的に決定されます。

  • フィルタ付きベクトル検索

    述語と組み合わせた最近傍探索は、これまで先に検索を行ってから後でフィルタリングする必要があり、その結果、返される行数が少なくなりすぎるか、それを補うために大幅に大きな検索を強いられるかのいずれかになっていました。v26.2 ではプリフィルタ戦略がサポートされ、述語が検索自体を制約するようになります。これは、ほとんどすべてのベクトルクエリが特定の 1 つのテナントに限定されるマルチテナントテーブルにおいて特に重要です。

レイクハウス​

  • Iceberg の UPDATE

    v4.1 では Iceberg テーブルに対する DELETE が追加されました。26.2 では同じコミットパスを再利用する形で UPDATE が追加され、行レベルの DML が一通り揃います。これにより、外部ジョブでテーブルを書き直すのではなく、Iceberg テーブルをその場で修正できるようになります。更新処理は Iceberg の行デルタとしてコミットされるため、PhoenixAI 以外のエンジンを含め、そのテーブルを読み取る側は常に一貫したスナップショットを参照できます。更新処理の状況はメトリクスとして公開されます。

  • Iceberg の MERGE INTO

    MERGE INTO は、ソースクエリからの挿入・更新・削除を 1 つの文でまとめて適用するもので、CDC（Change Data Capture）によるロードや低速変化ディメンションにとって自然な形です。v26.2 では、一部の機能のみではなく、フルセットのセマンティクスが実装されます。ソース側に同一のターゲット行に一致する行が複数含まれている場合、そのうちのどれかを任意に適用するのではなく、文自体が失敗するようになります。この一意性チェックは結合の分散処理上で実行されるため、追加のシャッフルは発生しません。これにより、完全には制御できないソースに対しても MERGE INTO を安全に実行できます。

  • Iceberg v3 の削除ベクトル（deletion vectors）

    削除ベクトルは、Iceberg v3 で導入された、行レベルの削除をコンパクトに表現する仕組みです。v26.2 では、この削除ベクトルの読み書きの両方に対応します。DELETE は Puffin 形式でエンコードされた削除ベクトルを生成し、すでにテーブル上に存在する削除は、リーダーが別途参照しなければならない 2 つ目の仕組みとして残されるのではなく、ベクトルにマージされます。削除ベクトルはデータキャッシュを経由して提供されるため、削除が多いテーブルを繰り返し読み取っても、オブジェクトストレージから再取得されることはありません。書き込みの状況はメトリクスとして公開されます。

  • Iceberg VARIANT のシュレッディング（shredding）

    VARIANT カラムは、スキーマ上で形状が固定されていない半構造化データを保持します。シュレッディングは、よくアクセスされるフィールドを型付きの個別カラムとして Parquet ファイルに格納し、それ以外は不透明な値のまま保持する仕組みです。v26.2 では、シュレッディングされた VARIANT カラムとされていない VARIANT カラムの両方を読み取れます。1 つのフィールドに対するクエリでも、カラム全体をマテリアライズする必要はなくなりました。フィールドパスは型付きカラムから再構築され、プルーニングはパスを考慮した形で行われ、述語はシュレッディングされたカラムの Parquet 統計情報を使ってプッシュダウンされ、シュレッディングされたフィールドも通常のカラムと同様に低カーディナリティ辞書フィルタリングの対象になります。実質的に、これにより読み取り性能に関する VARIANT フィールドと実カラムとの差はほとんど解消されます。

  • Iceberg のメタデータメンテナンスが自動的に実行されるようになりました。

    Iceberg テーブルには、スナップショット、マニフェスト、孤立ファイルが蓄積されていき、放置するとプランニング時間が悪化し、ストレージも無駄になります。メンテナンス処理は、各テーブルが継承しつつ上書きも可能な Catalog レベルのプロパティに基づいてスケジューリングされるようになったため、Catalog ごとに 1 回設定するだけで済みます。統計情報とメトリクスはタスクごとに収集され、新しい information_schema.iceberg_maintenance_tasks テーブルには、いつ、何が、どのように実行されたかが表示されます。メンテナンス操作の中で最もコストが高い孤立ファイルのスキャンは並列化されます。

リアルタイムおよび共有データエンジン​

  • クラウドネイティブテーブルにおけるインクリメンタルマテリアライズドビュー

    インクリメンタルメンテナンスは、ビュー全体を再計算するのではなく、ベーステーブルの変更が影響する行のみを更新します。これは、変更量に比例したリフレッシュと、テーブル全体のサイズに比例したリフレッシュとの違いに相当します。v26.2 では、これまで Lake テーブルに対してのみ適用されていたインクリメンタルメンテナンスが、主キーベーステーブルを含む共有データのクラウドネイティブテーブルにも拡張されます。サポートされる形は、集計、トップレベルの内部結合およびクロス結合、トップレベルの UNION ALL、導出テーブルによるサブクエリ、そして取り消し可能（retractable）なメンテナンスを伴う単一テーブルの射影・フィルタビューです。集計ベースカラムに対する BITMAP_UNION、HLL_UNION、PERCENTILE_UNION のロールアップもサポートされます。集計は 2 回ではなく 1 回のスナップショットから再計算されるようになるため、各リフレッシュで必要となる処理量が削減されます。また、ビューは実際に使用している分散方式を報告するようになり、インクリメンタルビューでも範囲分散を利用できるようになります。

  • 範囲分散（Range distribution）が本番環境での利用に対応しました。

    ハッシュ分散では、バケット数はテーブル作成時に固定されます。バケット数を少なく見積もるとパーティションが利用可能な並列度を活かせなくなり、多く見積もると小さなパーティションが不要なメタデータを抱えることになり、変更するにはテーブルを再構築する必要があります。範囲分散は、データの増加に応じてタブレットを分割・マージするため、パーティションのタブレット数はあらかじめ決める必要がなく、固定的な上限もありません。v4.1 では範囲分散テーブルを作成できるものの、それを維持するための操作ができず、長期間使い続けるテーブルとしては実用的ではありませんでした。v26.2 では、不足していた操作が追加されます。クラウドネイティブの範囲分散テーブルでは、次のことが可能になります。

    • キーとソートキーの変更、キーカラムの追加・削除、および整数型ソートキーカラムの拡張
    • 独自のソートキーを持つロールアップを含む、複数のロールアップの作成
    • 非同期マテリアライズドビューの ORDER BY のオンラインでの変更
    • データの移行
    • インクリメンタルマテリアライズドビューでの範囲分散の使用

    タブレットの事前分割（pre-splitting）は、分割が発生するのを待つのではなく、サンプルからタブレットのサイズを決める機能で、ロールアップインデックスを持つ範囲テーブルや、範囲テーブルへの INSERT ... FROM にも対応するようになります。ベクトルインデックスと Lake インデックスデルタは、いずれもタブレットの分割・マージに追従します。範囲分散は引き続きオプトイン方式です。 テーブルごとに DISTRIBUTED BY で選択するものであり、アップグレードによって既存テーブルの分散方式が変わることはありません。

  • リジェクトされた行をクエリで参照できるようになりました。

    一括ロードが行をリジェクトした場合、これまではどの行がなぜリジェクトされたかを調べるには、そのロードのエラーファイルを取得する必要がありました。v26.2 では、リジェクトされた行がバックグラウンドデーモンによって維持されるシステムテーブルに記録されるため、SQL でクエリできるようになります。ロード単位でフィルタしたり、リジェクトの理由と併せて確認したり、原因の特定に必要な他の情報と結合したりすることが可能です。これにより、ロードの失敗は、クラスターへのアクセス権がなくてもアナリストが診断できるものになります。

  • VARCHAR が最大 2 GiB まで拡張

    VARCHAR の上限が、約 1 MB から 2 GiB マイナス 1 KiB に引き上げられます。これは、これまで複数のカラムに分割したり、ロード時に切り詰めたりする必要があった JSON ドキュメント、シリアライズされたペイロード、モデルの入力データ、長いテキストなどにとって重要な変更です。大きな文字列に対するページエンコーディングのオーバーヘッドも削減されているため、上限を引き上げても、値自体が小さいままであればストレージコストが比例して増えることはありません。これに合わせて、FILES()、translate()、および型に関するドキュメントも更新されています。

  • 軽量タブレット作成

    通常、テーブルを作成する際には、タブレットを保持することになるすべての Compute ノードが、文が完了する前にそのタブレットのメタデータを書き込む必要があり、これがタブレット数の多いテーブルの作成時間の大半を占め、一括でのテーブル作成を遅くする要因になっていました。新しいテーブルプロパティ light_weight_tablet_creation は、このステップをスキップします。メタデータはオンデマンドで生成され、存在しない場合は Compute ノード側でフォールバック処理が行われます。スキーマ変更やロールアップでも、対応するレプリカ作成の処理がスキップされます。このプロパティは後から戻すことも可能で、無効にすると書き込まれていなかったメタデータがバックフィルされます。

  • FILES() に対する明示的な読み取りスキーマ

    schema パラメータを使用すると、推論に頼るのではなくスキーマを明示的に指定できます。これは、ファイル集合内の最初のファイルが全体を代表していない場合や、カラムの型を既存テーブルと厳密に一致させる必要がある場合に重要です。

クエリ実行​

  • タブレット内でのよりきめ細かい並列スキャン

    スキャンの並列度は、クエリが対象とするタブレット数によって制限されていたため、大きなタブレットが少数しかないテーブルでは、利用可能な CPU コアを活かせませんでした。これは扱いにくい制約でした。というのも、タブレットが大きいこと自体は、メタデータが少なく、メンテナンスコストも低く抑えられるという点で本来望ましいことだからです。v26.2 では、単一のタブレット内でのスキャンが並列化されるため、スキャンの並行度は、テーブル作成時に決めた分散方式ではなく、ハードウェアによって決まるようになります。実質的には、タブレットのサイズはクエリ性能上の判断ではなくストレージ上の判断になり、スキャンを並列に保つためだけにバケット数を過剰に増やす必要がなくなります。

  • Lake テーブル向けの事前準備された物理分割スキャン

    Lake テーブルに対するスキャンの速度は、最も遅いスプリットによって決まるため、サイズが過大な、あるいは偏った 1 つのタブレットが、スキャン全体の所要時間を左右してしまいます。v26.2 では、実行前にスキャン範囲を準備します。プルーニングはシードメタデータに対して行われ、読み取り状態は一度構築されて再利用され、偏りのあるタブレットは、タブレット数ではなくサイズによって作業が分散されるよう分割されます。スプリットはスキャン実行中に判明するのではなく、開始前にあらかじめ最適化されます。なお、この処理は、同じクエリ内で同一テーブルに対する重複したスキャンが発生する場合には意図的に無効化されます。そのようなケースでは、2 回準備することのコストが、得られる効果を上回ってしまうためです。

  • ETL モードでのクエリキュー

    クエリキューは、短時間で、かつコストがおおむね同程度であるインタラクティブなクエリを想定して設計されていました。ETL 文はそのどちらの性質も持たないため、同じ扱いをすると、許可しすぎてメモリを使い果たすか、許可しなさすぎてクラスターがアイドル状態になるかのいずれかに陥っていました。v26.2 では、クエリキューに ETL モードが追加され、文が占有するスロットの見積もり方法も改善されます。これにより、一律の仮定ではなく、その文が実際に保持するリソースを反映した形で許可判断が行われるようになります。これにより、1 つのクラスター上で、単一の許可ポリシーのもとに ETL ワークロードとインタラクティブなワークロードを併走させることが現実的になります。

  • JDBC 集計プッシュダウン

    JDBC 外部テーブルに対する集計は、ソースデータベース側で実行されるようになります。そのため、大きなリモートテーブルに対する GROUP BY では、すべての行を転送してローカルで集計するのではなく、グループ化済みの行が返されます。前述の結合プッシュダウンのデフォルト変更と合わせて、これにより JDBC Catalog を、小規模なディメンションの参照にとどまらない用途にも使えるようになります。schema_resolver という Catalog プロパティは、ソース側でのスキーマの解決方法を制御するもので、スキーマと Catalog の概念がきれいに対応しないデータベースにおいて重要になります。ネイティブクエリパススルーは、変換を経由せずソース自身の方言やセマンティクスをそのまま使いたい場合に、文を変更せずソースへ送信します。

改善点​

このリリースには、さらに数百件の改善が含まれています。ワークロード上で特に体感しやすいと考えられるテーマは、以下のとおりです。

  • 低カーディナリティ辞書最適化

    低カーディナリティ辞書最適化の対象が、ARRAY_AGG とそのソートカラム、定数引数を持つ配列関数、構造体、定数文字列に対する UNION ALL、物理フィルタ、CTE 演算子、そして ifnull、STARTSWITH、ENDSWITH を含むより多くの文字列関数にまで拡大されました。グローバル辞書キャッシュは、エントリ数ではなくメモリ量を基準に制限されるようになったため、異なる文字列カラムが多いワークロードでも、予測できない形でエビクションが発生することがなくなります。

  • カーディナリティ推定

    複合述語、OR 述語、範囲比較・不等号比較、外部結合のキー、日付・時刻関数に関するカーディナリティ推定が改善され、Iceberg のカラム統計情報がオプティマイザの min/max ルールに供給されるようになりました。推定精度の向上は、多くの場合、より適切な結合順序という形で現れます。

  • コンパクションとバキューム

    コンパクションとバキュームには、重複のない出力に対する並列コンパクション、フルチェーンのコンパクションプロファイル、自動バキュームに対する公平なスケジューリング、そして主キーテーブルにおける大規模な削除を publish 時に高速化するパスが追加されました。

  • バンドルされているコネクタライブラリ

    Delta Lake カーネルは 4.0 のリリース候補版から 4.3.0 に、Apache Arrow は 24.0.0 にそれぞれアップデートされます。

  • ストレージ内部実装

    アダプティブな文字列オフセット、集計・ウィンドウパスにおける大きなバイナリカラムのサポート、文字列カラムに対するデルタオフセットエンコーディング、再利用可能なセグメントイテレータが追加されました。