本記事では、OBKV Enterprise版の各バージョンに関するリリースノートをご紹介します。
V4.4.2 BP1
バージョン情報：
リリース日：2026年04月20日
バージョン番号：V4.4.2 BP1
RPMバージョン番号：oceanbase-4.4.2.1-101000192026041623
OBKV-TableとOBKV-HBaseで変更ログのフィルタリングがサポートされました
V4.4.2 BP1では、KVシナリオにおいてCDC変更ログのフィルタリング機能が新たに追加され、TTLタスクの変更ログがCDCリンクのリソースに与える負荷を軽減します。詳細はOBKV-Table TTL-変更ログのフィルタリングおよびOBKV-HBase TTL-変更ログのフィルタリングを参照してください。
V4.4.2
バージョン情報：
- リリース日：2026年2月10日
- バージョン番号：V4.4.2
- RPMバージョン番号：oceanbase-4.4.2.0-100000252026020915
バージョン概要：
V4.4.2では、KVシナリオにおいてOBKVの機能を継続的に改善し、弱い整合性読み取り、TTLタスクのインデックススキャン対応、ホットキークエリの最適化などの新機能を追加しました。また、OBKV-HBaseの監視指標も整理し、同時アクセスの多いKVおよび時系列シナリオにおいて、より低いレイテンシと高い可観測性を提供します。
OBKVは弱い整合性読み取りと最寄りデータセンターからの読み取りをサポート
- 弱い整合性読み取り：業務が非リーダーレプリカ（フォロアー）からデータを読み取ることを許可します。これらのレプリカは最新ではない可能性があるため、読み取ったデータはリーダーレプリカのバージョンよりも古くなる場合があります。
- 最寄りデータセンターからの読み取り：クライアントは現在の地理的位置やネットワークトポロジーに基づき、自身に最も近いデータセンターから優先的にデータを読み取り、ネットワーク遅延を削減して応答速度を向上させます。
詳細については、OBKV-Tableの弱い整合性読み取りと最寄りデータセンターからの読み取りおよびOBKV-HBaseの弱い整合性読み取りと最寄りデータセンターからの読み取りを参照してください。
TTL（Time To Live）タスクのインデックススキャン対応
ユーザーが指定したインデックスを使用して、TTLデータのクリーンアッププロセスを高速化できます。デフォルトの主キースキャンシナリオでは、TTLタスクはテーブル全体をスキャンし、完全な行を読んで有効期限が切れているかどうかを判断する必要があります。有効期限を表す列にローカルインデックスを構築することで、テーブル全体をスキャンして完全な行を読むことによるI/Oオーバーヘッドを削減し、スキャン速度を向上させることができます。使用方法の詳細については、OBKV-Table TTLおよびOBKV-HBase TTLを参照してください。
OBKV-HBaseのメトリクス強化
OBKV-HBaseのメトリクス機能が強化され、主な変更点は以下のとおりです：
- HBaseのgetとscanをQPS、RT、ヒストグラムの監視で区別し、それぞれ独立したメトリクスを使用して追跡する。
- バッチシナリオで、単一のputと単一のdelete操作を区別し、より細かい粒度の監視統計を提供する。
- OBKV-HBaseクライアントに、対応する操作のOPS、RT、P90、P95、P99データの返却を追加する。
新規メトリクスの説明については、OBKV-HBaseの監視指標を参照してください。
時系列モデルでput操作をサポート
時系列モデルの
V列はJSON型であり、LOBの制限によりput操作をサポートできませんでした。時系列モデルのput操作は、insertインターフェースに基づいて実装されています。insertインターフェースの実行時には主キー競合チェックが行われますが、SSモードの負荷テストでは、この主キー競合チェックが読み取り帯域幅の大部分を消費していることが判明しました。コールドデータがOSSに移動すると、競合チェックではsstableに対してget操作を実行する必要があり、その際の読み取り遅延が非常に高くなります。同時に、ランダム書き込みシナリオ（ほとんどのユーザーシナリオ）では、マイナーコンパクションとメジャーコンパクションがI/O帯域幅の大部分を消費します。これら二つの要因が重なることで、クラウドディスクの帯域幅がすぐに上限のボトルネックに達し、書き込み制限がトリガーされます。そのため、V4.4.2バージョンではput操作をサポートし、上記の問題を解決しました。
V4.4.1
バージョン情報：
- リリース日：2025年9月26日
- バージョン番号：V4.4.1
- RPMバージョン番号：oceanbase-4.4.1.0-100000242025092415
バージョン概要：
OBKV-Tableヒープ組織テーブル
ヒープ組織テーブルはOBKV-Tableのもう一つのテーブル構造であり、書き込みパフォーマンスとストレージ効率に高い要求があるシナリオ、特にデータのパーティションストレージが必要な場合に適しています。ヒープ組織テーブルでは、書き込みプロセス中に主キー競合の検証を行わないため、書き込み性能が向上し、追加のI/O消費が削減されます。また、データのソートを強制しない特性から、マイナーコンパクション・メジャーコンパクション段階でのI/Oリソースの使用を大幅に削減できます。そのため、LOBなど書き込みスループットとストレージコストに敏感なシナリオに特に適しています。OBKV-Tableはヒープ組織テーブルをサポートし、書き込みプロセス中の主キー競合やマイナーコンパクション・メジャーコンパクションによる大量のI/O帯域幅消費という問題を解決しました。詳細はOBKV-Tableを参照してください。
OBKV-HBaseリバーススキャンの強化
リバーススキャン機能はサブパーティションテーブルに対応しており、異なるパーティションタイプのサブパーティションテーブルでもリバーススキャン機能を使用できます。詳細はOBKV-HBaseを参照してください。
OBKV-TableがJSON型をサポート
OBKV-TableはJSON型をサポートしており、ユーザーはテーブル内にJSON列を作成し、OBKV-TableのJavaクライアントインターフェースを使用してJSONデータの読み書きを行えます。現在はJSONテキストの読み書きのみをサポートしており、関連するJSON式はサポートしていません。詳細はOBKV-Tableデータ型を参照してください。
OBKV-Tableがテーブル識別フラグをサポート
OBKV-Tableはテーブル識別フラグをサポートしており、ユーザーはテーブルに
kv_attributes='{"Table": {}}'設定を追加することで、OBKV-Tableテーブルとして正しく認識されるようにできます。これにより、パーティションの分割やOBCDC同期などのシナリオでOBKVテーブルを識別できます。詳細はOBKV-Tableのデータモデルを参照してください。その他の強化
- OBKV-HBaseの分散実行スイッチがデフォルトでオフからオンに調整されました。
- 新バージョンでは、OBKV-HBaseの互換性に関する一連の機能強化が行われました。
Admin、RegionLocator、RegionMetricsなどの新しいインターフェースを追加し、アプリケーションと関連ツールを含むHBase環境全体のOBKV-HBaseへのスムーズな移行をサポートします。 - OBKV-HBaseのほとんどのシナリオはIoTシナリオであり、データ量はPBレベルです。ユーザーはコスト削減のため共有ストレージを選択します。IoTシナリオでは書き込みが多く読み取りが少なく、かつホットデータの読み取りに偏ります。ユーザーのニーズを満たすため、新バージョンのOBKV-HBaseは共有ストレージモードでホットパーティションを指定してクエリを実行する機能をサポートしています。
- さらに、新バージョンではhbase put操作の最適化、パーティション計算ロジックの最適化、クライアントlsopリクエストのシリアライズ最適化など、複数の最適化手法によりOBKV-HBaseの性能が向上しています。
V4.4.0
バージョン情報：
- リリース日：2025年7月8日
- バージョン番号：V4.4.0
- RPMバージョン番号：oceanbase-4.4.0.0-100000562025070723
バージョン概要：
共有ストレージアーキテクチャ
Shared-Nothing形式のクラウドディスクと比較して、Shared-Storage形式は独立した低コストのストレージメディアを使用します。全量データがオブジェクトストレージに配置され、低コストで大量データを容易に保存できます。OBServerに小容量のクラウドディスクをマウントし、アクセス頻度や業務ルールに基づいてホットデータを特定・キャッシュすることで、クラウドディスクキャッシュがヒットするシナリオにおける計算性能がShared-Nothing形式と比べて低下しないよう保証します。共有ストレージアーキテクチャに基づき、ユーザーの業務特性や導入環境に応じて、KV業務は2Fの2アベイラビリティゾーン構成または1Fの単一アベイラビリティゾーン構成を選択可能で、いずれも無損失ディザスタリカバリ（RPO=0）を保証します。ストレージと計算が分離されたことで、ストレージノードと計算ノードの独立したスケーラビリティを実現し、計算リソースの水平スケーリング時に物理的なデータ移動が不要となり、高い伸縮性を実現できます。
マルチクラウドネイティブデータベースとして、共有ストレージはAmazon S3、Alibaba Cloud OSSなどの主要なオブジェクトストレージをサポートし、すべての主要なクラウドプラットフォームに対応しています。
共有ストレージアーキテクチャの利点は、低コスト、高性能、高い伸縮性、従量課金などであり、大規模なデータ量を扱い、レイテンシのジッターに敏感ではなく、ホットデータとコールドデータの分離が明確なシナリオに非常に適しています。KV業務において、共有ストレージアーキテクチャは、履歴注文データベース、膨大なユーザー行動記録、監視用時系列データの格納に最適で、コスト削減と効率向上が図れます。
単一レプリカ形態
独立したログサービスが提供するAZ間ディザスタリカバリ機能を活用し、V4.4.0では単一レプリカ構成のKV製品形態が導入されました。単一レプリカアーキテクチャでは、ログサービスとOceanBaseクラスタは1:1でデプロイされます。計算層では、一般テナントは単一レプリカで構成されますが、SYSテナントは単一レプリカ障害時の自動ディザスタリカバリを実現するために、3レプリカの高可用性形態でデプロイする必要があります。ログストレージ層では、ログサービスを3レプリカでデプロイします。
単一レプリカアーキテクチャでは、データベースはデータセンターレベルのディザスタリカバリを提供します。単一AZで障害が発生した場合、無損失の自動ディザスタリカバリにより、RPO=0、RTOは数分レベルを保証します。