【新機能まとめ】RisingWave v2.3登場：Iceberg統合、Elastic Disk Cache、ワークロード分離など

**RisingWave v2.3** のリリースを発表できることを嬉しく思います。今回のリリースでは、ストリーム処理ワークフローにさらに強力な機能と柔軟性が加わりました。本リリースでは、Apache Icebergベースのカラムナ型ストレージ、ワークロード管理のためのリソースグループ、新しいSQL関数など、多くの新機能が導入されています。

以下では、本バージョンリリースの注目機能についてご紹介します。v2.3のすべての更新内容についてご興味のある方は、[リリースノート](https://docs.risingwave.com/changelog/release-notes) をご覧ください。

## カラムナ型データストレージ向けIcebergテーブルエンジン

RisingWaveは、デフォルトの**行指向内部ストレージ**と、**Apache Icebergを基盤とするカラムナストレージエンジン**の2種類のストレージをサポートしています。Icebergテーブルエンジンを使用することで、データをIcebergフォーマットで外部保存しつつ、RisingWave内でテーブルをネイティブに作成・管理できます。このアプローチには、テーブル管理機能の組み込み、Icebergによるカラムナストレージ、データパイプラインの簡素化、他システムとの互換性向上といった複数の利点があります。

Icebergテーブルエンジンの設定と使用方法については、[Icebergテーブルエンジンの使用ガイド](https://docs.risingwave.com/store/iceberg-table-engine) をご参照ください。Icebergの機能全般や、RisingWaveエコシステム内での役割について広く理解するには、[Iceberg概要](https://docs.risingwave.com/iceberg/overview) をご覧ください。ストレージオプションの全体像については、[ストレージ概要](https://docs.risingwave.com/store/overview) を参照してください。

## Icebergソース・シンク・テーブルエンジン向けS3 Tables統合

RisingWaveをAmazon S3 Tablesに直接接続できるようになりました。S3 Tablesは、互換性のあるREST APIを介して管理されたIcebergカタログとして使用可能です。  
RisingWaveの**Icebergソース**を設定してS3 Tables管理のテーブルを読み込んだり、**Icebergシンク**を使用して書き込んだり、または**Icebergテーブルエンジン**と組み合わせてS3 Tablesをカタログとして活用したりできます。主な利点は、S3 Tablesの自動データコンパクションを利用してメンテナンスを簡素化し、ストレージ最適化が図れる点です。これにより、AWS上でのIcebergワークフローに強力なマネージドカタログオプションが追加されます。

この統合の設定方法については、[概要ページ](https://docs.risingwave.com/iceberg/overview#use-amazon-s3-tables-as-an-iceberg-catalog) および関連機能ドキュメントをご確認ください。

## Elastic Disk Cache（エラスティックディスクキャッシュ）

データがメモリキャッシュを超えた場合に発生するS3コストの増大やレイテンシー問題に直面していませんか？  
v2.3では新機能として、**Elastic Disk Cache** が導入されました。これは、メモリとS3の間にローカルディスクキャッシュ層を追加する機能です。これにより、高価なS3リードを大幅に削減（最大90％のコスト削減を観測）し、大規模な状態を持つストリーミングタスクのパフォーマンスを向上させ、スケーリングとリカバリーの速度を加速させます。

この機能はPremium Edition限定です。詳細は[Elastic Disk Cache](https://docs.risingwave.com/get-started/disk-cache)をご参照ください。

## ワークロードの分離と相互運用

これまでは、同一RisingWaveクラスタ内で一つのデータベースに障害が発生すると、他のデータベースにも影響を与える可能性がありました。

RisingWave v2.3では、この課題に対応するために、**ワークロードの分離と相互運用**のための包括的な機能群が導入され、堅牢なワークロード分離と柔軟な相互運用を実現しています：

1. **データベースの分離**：デフォルトでデータベース間の耐障害性を備えるための中核的な改善。
2. **リソースグループ**：データベースを専用のコンピュートノードプールに割り当て、強力な障害分離、パフォーマンスチューニング、リソースガバナンスを実現。
3. **クロスデータベースクエリ**：異なるデータベース間でテーブルやマテリアライズドビューをクエリでき、データを重複保存することなく統合分析が可能に。特に、分離された環境と組み合わせると強力です。

データベースの分離とリソースグループはいずれもPremium Edition限定機能です。RisingWave Cloudでは自動的に有効化されています。セルフホスト環境でも、コンピュートキャパシティが4コア以下のクラスタであれば、ライセンスなしでPremium Edition機能を試用できます。

詳細は[ワークロードの分離と相互運用](https://docs.risingwave.com/operate/workload-isolation-interaction) をご覧ください。近日中にこの機能に関する詳細なブログ記事も公開予定ですので、ご期待ください。


## 非同期およびバッチ処理に対応したJavaScript UDF

v2.3から、RisingWaveは**非同期およびバッチ処理対応のJavaScriptユーザー定義関数（UDF）** を導入しました。これにより、非同期操作や複数の入力データを一度に処理できるようになり、I/Oバウンドタスクや外部API呼び出しなどに理想的な選択肢となります。

これを実現するために、拡張された `CREATE FUNCTION` 構文を使用し、`WITH`句内でオプションの`async`および`batch`設定を指定してJavaScript UDFを定義します。

詳細は[非同期およびバッチ処理対応のJavaScript UDF](https://docs.risingwave.com/sql/udfs/use-udfs-in-javascript#async-and-batched-javascript-udfs) をご参照ください。

## **バッチクエリ向けASOF JOINの強化**

RisingWaveは、v2.1でストリーミングクエリに対してASOF JOINをサポートしましたが、v2.3では**バッチクエリ**に対するASOF JOINサポートも追加しました。  
注意点として、バッチモードでは、右側のテーブルで複数の行が最も近い値に一致する場合、実行ごとに結果が異なることがあります。

詳しくは[ASOF JOIN](https://docs.risingwave.com/processing/sql/joins#asof-joins) をご覧ください。


## 結論

ここまで、v2.3に含まれる主な新機能について紹介してきました。  
ソースおよびシンクコネクタの更新を含む、すべてのアップデート一覧については、[リリースノート](https://docs.risingwave.com/changelog/release-notes) をご参照ください。

来月も引き続き、新機能を盛り込んだアップデートを予定していますので、どうぞご期待ください。[RisingWave GitHubリポジトリ](https://github.com/risingwavelabs/risingwave) で最新開発情報やリリース計画をチェックできます。

また、[月刊ニュースレター](https://www.risingwave.com/risingwave-cloud/) にご登録いただければ、RisingWaveの最新情報を常に受け取ることができます。  ぜひ[Twitter](http://go.risingwave.com/twitter)や[LinkedIn](http://go.risingwave.com/linkedin)でもフォローしてください。世界中のストリーミング愛好家とつながるには、[Slackコミュニティ](http://go.risingwave.com/slack) にもご参加ください。