このドキュメントでは、リアルタイム分析に関連するコア機能の変更点のみを記載しています。OceanBaseデータベースの全バージョンにおける機能強化とイテレーションの詳細については、リリースノート(Release Note)を参照してください。
V4.4.2
バージョン情報
- リリース日：2026年02月10日
- バージョン番号：V4.4.2
新機能・機能強化
マテリアライズドビューの機能強化
V4.4.2では、マテリアライズドビューの機能が引き続き改善されています。DDLレベルではRENAME操作とマテリアライズドビューのログ追加列をサポートし、MLOGテーブルの自動作成、置換、バックグラウンドでの冗長クリーンアップを実装しています。増分更新機能は大幅に拡張され、外部結合、UNION ALL、単一テーブルの非集計、LEFT JOINを含む集計などの複雑なクエリパターンを新たにサポートしています。MIN/MAX集計関数の処理が強化され、重複SELECT ITEMとGROUP BY列をサポートし、主キーのないベーステーブルのシナリオにも対応しています。AS OF PROCTIME()構文を導入し、次元テーブルの動的な更新免除（この構文を参照するビューをサポート）を実現し、ネストされたマテリアライズドビューの連鎖更新メカニズムを改善しました。同時に、UDT/UDF、minimalモード、md5_concat_ws関数へのサポートを強化し、ビュー内容の表示と作成エラーメッセージを最適化することで、複雑なクエリ、リアルタイム分析、運用管理におけるマテリアライズドビューの柔軟性、パフォーマンス、使いやすさを全面的に向上させました。
V4.4.1
バージョン情報
- リリース日：2025年09月26日
- バージョン番号：V4.4.1
新機能・機能強化
HMS Catalogのサポート
V4.4.1では、Icebergデータレイクのオープンテーブル形式をサポートし、HMS Catalogを通じてIcebergテーブル形式の外部テーブルやHiveテーブル形式の外部テーブルをクエリできるようになりました。HMS Catalogの導入は、HMSプロトコルと互換性のある統一メタデータ抽象化レイヤーを構築し、Hudi TimelineやIceberg Snapshotsなどの複数テーブル形式のメタデータを自動同期し、主要な計算エンジンとシームレスに接続することで、システム間のメタデータの曖昧さを解消することを目的としています。これにより、OceanBaseはデータレイクの「ストレージとコンピューティングの分離」から「メタデータ駆動型のガバナンス」へと進化するための重要なインフラとなります。
外部テーブルでJDBCプラグインをサポート
OceanBaseは外部テーブルを通じて、OSSに保存されたCSVファイルやODPSテーブルなど、さまざまな外部データソースに直接アクセスできます。V4.4.1では、JDBCプラグイン機能が新たに追加され、JDBC互換のデータソースに接続できるようになりました。現在はMySQLデータソースをサポートしています。
V4.4.0 Beta
バージョン情報
- リリース日：2025年07月08日
- バージョン番号：V4.4.0
新機能・機能強化
ODPS Storage APIのサポート
V4.4.0では、ODPS Storage APIのサポートが新たに追加され、ODPS外部テーブルがODPSの基盤ストレージに直接アクセスできるようになりました。これにより、Tunnel API方式では各パーティションのスキャンごとに独立したセッションを確立する必要があり、秒単位の初期化遅延が生じていた問題を回避し、小規模クエリや高頻度クエリシナリオにおける外部テーブルへのアクセス性能を大幅に向上させました。同時に、多様なアクセス要件を満たすため、Tunnel APIの互換性も維持しています。
SELECT INTO OUTFILEがHDFSパスをサポート
V4.4.0では外部テーブル機能が継続的に改善され、外部テーブルを通じて直接HDFSパスのファイルをクエリまたはインポートできるようになりました。新バージョンではさらにHDFS機能を統合し、データを直接HDFSにエクスポートできるようになりました。また、Kerberos認証を使用したHDFSアクセスもサポートしています。
V4.3.5 BP5
バージョン情報
- リリース日：2025年11月17日
- バージョン番号：V4.3.5 BP5
新機能・機能強化
マテリアライズドビュー機能の強化
V4.3.5 BP5では、Left Joinを含むポリマライズドビューの増分更新がサポートされました。主キーのない増分マテリアライズドビューに基づいてネストされたマテリアライズドビューを作成できるようになりました。また、集約増分マテリアライズドビューのMIN/MAX集約関数のパラメータとして非ベース列を指定できるようになりました。さらに、複数テーブル結合の増分マテリアライズドビューが、次元テーブル(AS OF PROCTIME())として宣言された通常のビューを参照できるようになりました。フル更新マテリアライズドビューがUDFを参照できるようになり、増分更新マテリアライズドビューがMinimal更新モードをサポートするようになりました(増分更新のDMLは、カラムストアテーブルの必要な列のデータの読み書きのみが必要)。また、マテリアライズドビューが固定されたセッション変数を使用して更新できるようになりました。
Delete-Insertテーブルの増分データクエリでSkip Indexをサポート
V4.3.5 BP5では、Delete-Insertテーブルの事前生成増分データでSkip Indexをサポートします。増分データを処理する際のクエリでは、Skip Indexを使用してデータを事前にトリミングできるため、クエリ効率が大幅に向上します。Skip Index機能の適用範囲は、テナントレベル構成パラメータdefault_skip_index_levelで制御できます。
パーティション交換機能の拡張
V4.3.5 BP5以前では、パーティションと非パーティションテーブルの間で、パーティションをサポートするテーブルと非パーティションテーブルの間で、サブパーティションテーブルのサブパーティションと非パーティションテーブルの間で、サブパーティションテーブルのパーティションとパーティションテーブルの間での交換をサポートしていました。V4.3.5 BP5では、List/List Columnsパーティションテーブルのパーティションと非パーティションテーブルのパーティションとの交換機能を拡張しました。
V4.3.5 BP4
バージョン情報
- リリース日：2025年09月10日
- バージョン番号：V4.3.5 BP4
新機能・機能強化
マテリアライズドビュー機能の強化
V4.3.5 BP4では、マテリアライズドビュー機能の改善を継続しています。機能面では、増分更新マテリアライズドビューの更新時に次元テーブルを更新しないようにしました。マテリアライズドビュー作成時に、更新不要のテーブルを指定するために新しいAS OF PROCTIME()構文を追加しました。これにより、マテリアライズドビューの増分更新実行時に、そのテーブルの増分データを更新しなくなりました。単一テーブル集約の増分更新マテリアライズドビューがMIN()/MAX()集約関数をサポートします。使いやすさの観点からは、MLOGの自動化管理をサポートしています。増分更新マテリアライズドビュー作成時に、基準テーブルに必要なMLOGテーブルを自動的に作成・置き換え、バックグラウンドで冗長なMLOGテーブルを定期的にクリーンアップします。また、マテリアライズドビューのビュー内容とマテリアライズドビュー作成時のエラーメッセージを最適化しました。
APパラメータテンプレートでデフォルトでフルダイレクトロードが有効になる設定を無効に
V4.3.5 BP3
バージョン情報
- リリース日：2025年07月21日
- バージョン番号：V4.3.5 BP3
新機能・機能強化
外部データソースと統合の最適化
ODPS外部テーブルがStorage APIに対応
Tunnel APIをベースとしたODPS外部テーブルでは、実行段階で各パーティションをスキャンするたびに独立したセッションを開始する必要があり、セッションの開始には秒単位の遅延が生じていました。これにより、本来はごく短時間で終わるはずのクエリが、セッションの準備段階で時間を費やしてしまうという問題がありました。ODPSはTunnel APIに加え、ODPSの基盤ストレージに直接アクセスできるオープンなStorage APIも提供しており、より多くの最適化戦略と優れた読み取り性能を実現します。そのため、新バージョンではODPS Storage APIに対応し、外部テーブルへのアクセス性能をさらに向上させました。
オブジェクトストレージがAzure Blobをサポート
Azure Blobプロトコルを使用してAzure Blobオブジェクトストレージにアクセスできるようになりました。
マテリアライズドビューの全面的な強化
マテリアライズドビュー機能の強化
新バージョンでは、マテリアライズドビューの機能を継続的に改善しています。主な強化点として、マテリアライズドビューがRENAMEをサポートするようになったこと、増分更新が外部結合/UNION ALL/非集約単一テーブル機能をサポートするようになったこと、マテリアライズドビューのログが列の追加をサポートするようになったこと、ネストされたマテリアライズドビューが連鎖更新機能をサポートするようになったことが挙げられます。同時に、DROP MATERIALIZED VIEWが停止する問題など、複数の不具合を修正し、マテリアライズドビューの安定性を向上させています。
ストレージとパーティション管理の最適化
パーティション交換がパーティションテーブルとサブパーティションテーブル間で可能に
パーティション交換機能は、サブパーティションテーブルのパーティションとパーティションテーブルとの交換をサポートします。
オプティマイザーとクエリ性能の向上
統計情報の強化
V4.3.5 BP3以前のバージョンでは、統計情報収集において、パーティションレベルおよびテーブルレベルの各列についてMIN/MAX/NULL COUNT/NDVなどの集計データを収集し、サンプリングによってデータの分布を推定していました。これにより誤差が大きくなるという課題がありました。新バージョンでは、ストレージ層のSkip Index機能を活用し、カラムストアのすべての列に対してブロックレベルでより正確な列集計データを収集することで、オプティマイザーがより正確な実行計画の生成と最適化を行えるよう支援します。また、大規模なパーティションテーブルにおける統計情報収集時間の長さが原因でタイムアウトする問題を解決するため、パーティションごとに段階的に統計情報を収集する方式を導入し、システムの安定性とデータのリアルタイム性を向上させています。
データインポートの高速化
ダイレクトロードのパフォーマンス最適化
新バージョンでは、ダイレクトロードの実行ロジックに関するパフォーマンス最適化を行っています。これには、ダイレクトロードのソートアルゴリズム、ベクトル化パス、CSV解析、column_conv式、cs encoding関連の最適化が含まれます。これにより、カラムストアの非パーティションヒープテーブルにおいて、最大で10%のパフォーマンス向上が見られます。
V4.3.5 BP2
バージョン情報
- リリース日：2025年05月15日
- バージョン番号：V4.3.5 BP2
製品形態
Shared-Storage AP製品形態の追加
V4.3.5 BP2バージョンから、Shared-Storageデプロイメント形態のOceanBaseデータベースをAP業務に利用できるようになりました。Shared-Storage AP形態は、Shared-Nothingデプロイメントモードでの主要なAP機能をサポートしており、例えばカラムストアテーブル、増分ダイレクトロード、マテリアライズドビュー、全文インデックス、複数値インデックスなどが含まれます。また、Shared-Storage形態でのI/O読み取り方式についても特化した最適化が施されています。Shared-Storage AP製品形態は、データにホット/コールド特性があり、ストレージコストを削減したいAP業務に推奨されます。
機能強化
データ復元能力の強化
テーブルレベル復元でカラムストアテーブルの復元をサポート
このバージョン以前では、テーブルレベル復元機能は行ストアテーブルへの復元のみをサポートしていました。新バージョンでは、Share Nothingデプロイメントモードにおけるテーブルレベル復元機能が改善され、カラムストアテーブルや行列混合テーブルへの復元がサポートされるようになりました。
パフォーマンス最適化
ヒープテーブルのダイレクトロードパフォーマンスの最適化
ヒープテーブルのダイレクトロードにおいて、新規一意インデックス作成プロセスの一意性検証フローが最適化されました。これにより、ヒープテーブルの全量ロードにおいて、非パーティションテーブルのパフォーマンスがインデックス主キーテーブルと同等以上になりました。
ハードパースのパフォーマンス最適化
一部のAPシナリオや大中小規模アカウントシナリオにおいて、Plan Cacheを無効にしてハードパースを行うことで、不良計画の使用を減らすことができます。しかし、Plan Cacheを無効にすると、ハードパースのパフォーマンスに対する要求が高まります。新バージョンでは、リゾルバ段階のホットスポット関数の最適化、グローバルコスト検証が不要なシナリオの局所コスト検証への置き換え、式のメモリ使用量の削減、不要な式型推論操作の除去などの手法により、オプティマイザーのリゾルブやリライトなどの段階のパフォーマンスが向上しました。
マテリアライズドビューの強化
フル更新マテリアライズドビューで外部テーブルに基づく構築をサポート
V4.3.5 BP2バージョン以前では、OceanBaseデータベースはユーザーテーブルとマテリアライズドビューに基づいてマテリアライズドビューを作成することをサポートしていました。新バージョンでは、フル更新シナリオにおいて、ベーステーブルが外部テーブルの場合のマテリアライズドビューをサポートし、マテリアライズドビューの適用シナリオを拡張しました。
マテリアライズドビュー診断能力の強化
新たに
CDB/DBA_MVIEW_RUNNING_JOBSシステムビューが追加され、リフレッシュタスクやMLOGクリーンアップタスクなど、実行中のマテリアライズドビューのタスクを表示できるようになりました。新たにDBA_MVIEW_DEPSシステムビューが追加され、マテリアライズドビューの依存オブジェクト情報を表示できるようになりました。CDB/DBA/ALL/USER_MVIEWSシステムビューには、マテリアライズドビューのリフレッシュポイントとリフレッシュ遅延時間の記録が追加されました。CDB/DBA/ALL/USER_MVIEW_LOGSビューには、MLOGクリーンアップで使用される並列度と所要時間情報が追加されました。マテリアライズドビューのタスク接続におけるリソース分離
マテリアライズドビューのリフレッシュやPurgeなどの操作はシステムリソースを消費し、フロントエンドタスクのパフォーマンスに影響を与える可能性があります。新バージョンでは、Resource Managerに基づき、マテリアライズドビューの増分リフレッシュやMLOG Purgeに対してリソース分離機能を提供し、ユーザーはマテリアライズドビューのタスクで使用するリソースの上限を設定できます。
パーティション管理
動的パーティション管理
業務では、日付や時間をRangeパーティションキーとして選択し、異なる時間帯のデータを異なるパーティションに分割することが一般的です。現在は、DBAが将来の時間のパーティションを定期的に事前作成する必要がありました。DBAが何らかの理由で事前作成を忘れた場合、パーティションが存在しないためデータの書き込みに失敗し、業務に影響を与える可能性があります。そのため、新バージョンでは動的パーティション管理機能を提供し、テーブルに動的パーティション管理属性を指定することで、カーネルレベルで将来の時間のパーティションを自動的に事前作成し、DBAの負担を軽減します。同時に、動的パーティション管理は、業務上不要になった期限切れのパーティションの自動削除もサポートし、ストレージを節約します。
インデックスとクエリの最適化
全文インデックスのNGRAM2トークナイザー
全文インデックスに組み込みの
NGRAM2トークナイザーが追加され、min_ngram_sizeからmax_ngram_sizeの範囲内でNGRAMトークニングをサポートします。NGRAM2トークナイザーは、パフォーマンスとストレージ容量に対する要求が比較的低く、異なる長さのtokenに対する検索が必要なシナリオに適しています。固定長のtokenにはNGRAMトークナイザーを使用できます。
データ型とストレージの最適化
Mapデータ型
Mapデータ型は、無秩序なキー・バリュー・ペア（key-value pair）を格納するために使用されます。例えば、{a:1, b:2, c:3} のような形式です。一般的な使用シナリオとしては、設定オプション情報、ユーザー属性、製品情報などの保存が挙げられます。OceanBaseは4.3.5BP2バージョンでArrayフレームワークに基づいてMapデータ型を実装し、Mapコンストラクタおよび map_keys、map_values、=/!= などの関数と演算子をサポートしています。
MySQLモードのJSON半構造化ストレージ
半構造化データは現在、すべてバイナリ文字列として格納されており、エンコーディングによる圧縮が難しい状況です。各データが自己解釈可能となるようにするために、実際には一部のデータメタを冗長的に格納しているため、ストレージ圧縮率は低くなっています。JSONは典型的な半構造化データであり、強い構造化特性を持っています。理論上、半構造化データを論理的に複数の基本型の列に分割し、分割できない部分を1つのBinary列に配置することができます。構造化された列ではエンコーディングを利用して圧縮率を向上させることができ、分割できない部分もデータメタを抽出したことで従来よりも空間占有量が削減されます。これを「半構造化列の構造化ストレージ」と呼んでいます。OceanBaseは4.3.5BP2でJSON型の半構造化ストレージをサポートし、対応するエンコーディング方式を実装することで、ストレージ容量の節約とJSONサブカラムに対するクエリフィルタリング性能の最適化を図りました。しかし、JSONが複数のサブカラムに分割されて格納されるため、元のJSONデータを頻繁に読み取る必要があるシナリオでは、マージによるオーバーヘッドが発生し、パフォーマンスが低下する可能性があります。この機能を有効にするかどうかは、業務の種類に応じて判断する必要があります。
クエリ実行
Plan Cacheの適応
Plan CacheはTPシナリオにおいて極めて重要な機能であるため、デフォルトで有効になっています。しかし、一部のAPシナリオでは、プランの実行時間がプラン生成時間の数倍に達する場合があります。このような状況では、オプティマイザーが毎回プランを生成する方が、プランの再利用よりも優れた実行計画を得て、より良い実行性能を実現できることが多いです。異なるシナリオ、特にHTAP混合負荷シナリオでは、AP寄りのSQLはハードパースを行わせ、TP寄りのSQLはプランを再利用してハードパースによるオーバーヘッドを省く方法を提供する必要があります。そのため、OceanBaseの新バージョンでは、SQLの実行時間と時間分布の特性に基づいて、そのSQLのPlan Cacheを使用するかどうかを判断するPlan Cache適応機能をサポートしています。
外部データソースの統合
MySQLモードのODPS（MaxCompute）Catalog
各種外部データソースに格納されたデータのクエリを容易にするため、新バージョンではExternal Catalogフレームワークをサポートし、第一弾としてODPS Catalog機能をサポートしました。OceanBaseの既存の内部オブジェクトはInternal Catalogに属します。ユーザーは自身でExternal Catalogを作成して外部データソースに接続し、外部データのメタ情報を取得できます。External Catalog下のテーブルデータに対する直接クエリ、例えば select col1 from catalog1.database1.table1; がサポートされています。権限要件を満たす場合、任意のCatalog間のテーブル結合クエリもサポートされます。データのインポートや個別の外部テーブルの作成を行う必要がなくなり、外部データへのアクセスの使い勝手が向上しました。
データインポート
Load DataによるURL CSV外部テーブルのフォールトトレランスモード
Load Data方式でデータをインポートする際、現在はデータ型の不互換性や精度の不一致などの問題が発生すると、直接エラーが返されます。新バージョンでは、フォールトトレランスインポートを行うためのLOG ERRORSコマンドが追加されました。MySQLモードでは失敗行が記録され、show warningsコマンドで誤ったデータを確認し、エラー診断を行うことができます。
V4.3.5 BP1
バージョン情報
- リリース日：2025年03月18日
- バージョン番号：V4.3.5 BP1
新機能・機能強化
データのインポートとエクスポート
増分ダイレクトロードでヒープテーブルの一意インデックスをサポート
ダイレクトロードは、フルダイレクトロードと増分ダイレクトロードに分かれています。テーブルに既存データがある場合、増分ダイレクトロードの方がフルダイレクトロードよりもパフォーマンスが優れています。しかし、以前は増分ダイレクトロードでは一意インデックスを持つヒープテーブルへのデータインポートがサポートされていませんでしたが、新バージョンでは、部分的に一意なインデックスを持つヒープテーブルへのデータインポート機能がサポートされています。
ダイレクトロードでHASHパーティションとパーティションの並列インポートをサポート
V4.3.5 BP1バージョンから、HASHタイプのパーティションレベルダイレクトロードがサポートされます。同時に、増分ダイレクトロードでは複数パーティションの並列インポートが可能になりましたが、複数のインポートタスクで重複するパーティションがある場合、パーティションの並列インポートはサポートされませんでした。
ダイレクトロードのパフォーマンス最適化
ベクトル化による最適化、一時ファイル処理の簡略化、各段階での計算パフォーマンス最適化により、clickbenchテーブルのインポートパフォーマンスはV4.3.5に比べて17%向上しました。
外部データソースの統合
外部テーブルでHDFSファイルの読み取りをサポート
HDFSはデータレイクアーキテクチャで最も一般的なストレージ媒体であり、マルチエンジン間でデータを共有するプラットフォームです。そのため、OceanBaseの新バージョンでは、外部テーブルを通じてHDFS上のファイルを直接読み取ることができるようになりました。また、関連設定を通じてKerberos認証を備えたHDFSクラスタへの接続もサポートしています。
外部テーブルでMaxCompute（ODPS）データソースの読み書きをサポート
新バージョンでは、外部テーブルまたはURL外部テーブルを通じてMaxComputeからデータを読み取ることができるほか、OceanBaseのデータをMaxComputeに書き戻すこともサポートしています。
URL外部テーブル
OceanBaseで外部データソースにアクセスする際、通常はまず外部テーブルを作成し、その後SQLクエリを実行します。4.3.5BP1ではURL外部テーブル機能が新たに追加され、selectステートメントを使用して外部のCSV/Parquet/ORCおよびMaxcomputeデータを直接クエリできるようになりました。これにより、外部テーブルを作成する必要がなくなりました。さらに、この機能を基盤として、load data構文にURL外部テーブルを直接参照するデータインポートが拡張され、データインポートの運用手間が削減されました。
インデックスの最適化
全文インデックス機能の強化
OceanBase V4.3.1バージョンからMySQLモードで全文インデックスがサポートされ、バージョンの進化に伴い徐々に機能の補完と拡張が行われてきました。V4.3.5 BP1では、組み込みの中国語
IK分かち書き辞書が追加され、smart、max_wordの2種類の分かち書きモードをサポートしています。さらに、プラグイン形式での分かち書き辞書の追加もサポートしています。全文インデックスの分かち書き辞書属性が追加され、テーブルレベルのPARSER_PROPERTIES設定をサポートしています。既存の全文インデックスクエリの自然言語モードに加え、ブールモードも新たに追加されました。MATCH AGAINSTでIN BOOLEAN MODEキーフレーズを使用して有効にでき、+、-、（）、無操作子などのブール演算子や演算のネストをサポートしています。同時に、今回のリリースでは全文インデックスのIndex Mergeへの参加もサポートされ、インデックスunion mergeの計算によりクエリパフォーマンスが向上しました。また、メインテーブルの全文インデックス列に対する更新/削除シナリオが最適化され、更新/削除のパフォーマンスが向上しました。
マテリアライズドビューの強化
マテリアライズドビューの強化
マテリアライズドビューのリフレッシュ並列度は、増分/フルリフレッシュの効率と密接に関連しています。新バージョンでは完全な並列度制御メカニズムをサポートしており、
mview_refresh_dopシステム変数、DBMS_MVIEW.refreshサブプログラム、またはマテリアライズドビュー作成時のPARALLEL指定によりリフレッシュ並列度を設定できます。新バージョンの増分マテリアライズドビューではLOB型をサポートし、マテリアライズドビューまたはマテリアライズドビュー属性の直接変更も可能になりました。ALTER MATERIALIZED VIEW/ALTER MATERIALIZED VIEW LOGコマンドを使用して、マテリアライズドビューの並列度、バックグラウンドリフレッシュタスクの時間間隔、MLOGテーブルの並列度、MLOGテーブルのバックグラウンドクリーンアップタスクの時間間隔、MLOGのLOBインラインストレージ長のしきい値などを変更できます。また、ベーステーブルにMLOGを作成した後は、ベーステーブルに列を追加する操作ができなくなり、MLOGを削除してからDDLを行う必要があり、手順が複雑でした。そのため、新バージョンではMLOGベーステーブルに列を追加する操作をサポートしており、末尾への列追加と途中への列追加の両方を含みます。さらに、新バージョンではMLOGクリーンアップのパフォーマンスも向上し、増分リフレッシュのエラーメッセージも最適化されました。
テーブル構造とストレージの最適化
ヒープテーブルの組織モード
OceanBaseは集約インデックステーブルモデルを採用しており、この設計はOLTP環境で優れたパフォーマンスを発揮します。これにより、主キーと主テーブルデータが同一のテーブルに格納され、主キークエリの速度と一意性検証のパフォーマンスが最適化されます。しかし、このモデルは効率的なデータインポートと複雑なデータ分析が求められるOLAPシナリオでは、一定の制限があります。インポートプロセスでは全量データのソートが必要であり、クエリ時には主キー行の融合を行わなければならないため、これらがパフォーマンスに影響を与えます。新バージョンではヒープテーブルの組織モードをサポートするようになりました。主キーは一意性制約に使用され、クエリは主テーブルに依存します。ユーザーデータが時間順にソートされている場合、skip indexをより効果的に活用してクエリ効率を向上させることができます。また、主キーとデータを分離することで、インポートプロセスで主テーブルデータをソートする必要がなくなり、データインポートのパフォーマンスが向上しました。
データ型とストレージの最適化
MySQLモードでStringデータ型が追加
一部のAP業務では列長に対する許容度が高く、しばしば不定長文字列型を使用してデータを格納し、主キーまたはインデックスキーとしても使用します。OceanBaseでは、char/varchar型は文字列を格納し主キーまたはインデックスキーとして使用できますが、長さを指定する必要があります。mediumtext/textなどのLOB型は不定長文字列を格納できますが、主キーまたはインデックスキーとしては使用できません。AP業務のニーズにより適切に応えるため、Stringデータ型が追加されました。長さを指定する必要がなく、デフォルトで最大16MBです。列長が16KB未満でlob_inrow_threshold以下の場合、主キーまたはインデックスキーとして使用できます。
ARRAY型関連関数の拡張
OceanBaseは4.3.3バージョンでARRAYデータ型をサポートし、いくつかの一般的な関数や演算子をサポートしました。新バージョンでは関連関数がさらに拡張され、
array_prepend、array_concat、array_compact、array_filter、array_sort、array_sortby、array_length、array_range、array_sum、array_first、array_difference、array_min、array_max、array_avg、array_position、array_slice、reverseなどの関数が追加されました。
パラレルクエリの最適化
PX計算ノードとデータノードの分離
現在のシステムアーキテクチャでは、ストレージリソースと計算リソースは高度に結合しています。既存のPXスケジューリングメカニズムでは、Non-Leaf DFOに対して、データが存在するマシンのみを選択して計算タスクを割り当てます。この密接な結合は、特定のシナリオではマシンリソースの十分な活用を制限します。大規模SQLがより多くのマシンの計算を利用できるようにするため、新バージョンではPX計算ノードとデータノードの分離をサポートしています。構成パラメータまたはhint（PX_NODE_POLICY）を使用してNon-Leaf DFOの候補リソースプールを決定でき、hint（PX_NODE_ADDRS、PX_NODE_COUNT）を使用してNon-Leaf DFOが割り当てられる具体的なマシンまたはマシン数を強制的に指定することもできます。
クエリの最適化とプッシュダウン
行ストアデータに列を追加したシナリオでのクエリプッシュダウンのサポート
行ストアSCANプロセスでは、交差するデータがない場合、つまりmajor sstableや他の場所にrowidが同じデータがない場合、SCANをストレージ層にプッシュダウンします。メジャーコンパクション後に新しい列が追加された場合、理論上はSCANをプッシュダウンできますが、新しい列の解析失敗によりプッシュダウンが失敗し、パフォーマンスの低い行単位の読み取りに戻ることがあります。新バージョンではこのシナリオに特化した最適化を施し、クエリをストレージ層にプッシュダウンしてクエリパフォーマンスを向上させることをサポートしています。
カラムストアストレージの最適化
カラムストアレプリカの最適化
V4.3.3バージョンでリリースされたカラムストアレプリカ機能には、単一のCレプリカのみをサポートし、Cレプリカへのカラムストアデータの全量直接インポートができない、ユーザー使い勝手が不十分であるなどの制限がありました。新バージョンではこれらの制限を解消し、1つのクラスタで複数のCレプリカを指定できるようにし、Cレプリカへのカラムストアデータの直接全量ダイレクトロードをサポートしました。同時に、パーティションレベルおよびログストリームレベルのカラムストアレプリカ変換進捗状況を表示するシステムビュー
CDB/DBA_OB_CS_REPLICA_STATSを新規追加し、ユーザーがカラムストアレプリカの状態を観察しやすくしました。
バージョン変更点
APパラメータテンプレートでNLJを無効化
オプティマイザーがネストドループ結合計画を生成した後、ドライブテーブルの行数に敏感であり、ドライブテーブルの行数推定が小さすぎると、計画の実際の実行パフォーマンスが大幅に低下する可能性があります。OLAPシナリオでは、データ量が一般的に大きく、ネストドループ結合計画を使用しても得られる利点は限定的です。そのため、APシナリオではデフォルトでハッシュ結合計画を生成するように変更され、等価でない結合シナリオでのみネストドループ結合計画が生成されます。
V4.3.5
バージョン情報
- リリース日：2024年12月31日
- バージョン番号：V4.3.5
新機能・機能強化
マテリアライズドビューの強化
ネストされたマテリアライズドビューをサポート
V4.3.5以前のバージョンでは、通常のユーザーテーブルに対してのみマテリアライズドビューの作成が可能でした。データウェアハウスのシナリオでは、マテリアライズドビューを用いてデータ加工が行われます。軽量なリアルタイムデータウェアハウスシナリオをサポートするため、V4.3.5バージョンでは既存のマテリアライズドビューに基づいて新しいマテリアライズドビューを作成すること、すなわちネストされたマテリアライズドビューをサポートします。ネストされたマテリアライズドビューがサポートするリフレッシュ方式は、非ネストされたマテリアライズドビューと同様に、フルおよび増分リフレッシュを含みます。そのため、V4.3.5ではマテリアライズドビューに基づいてマテリアライズドビューのログを作成することが可能です。ネストされたマテリアライズドビュー内のデータの鮮度はベーステーブルデータの鮮度に関連しています。上位レベルのマテリアライズドビューのデータ鮮度を保証するためには、ユーザーがまず下位レベルのマテリアライズドビューをリフレッシュする必要があります。
詳細については、マテリアライズドビューの作成（MySQLモード）またはマテリアライズドビューの作成（Oracleモード）のネストされたマテリアライズドビューの作成セクションを参照してください。
データのインポートとエクスポート
指定パーティションのダイレクトロードをサポート
V4.3.5バージョン以前では、OBServerはテーブル全体のデータインポートにおいてのみダイレクトロード経路をサポートし、インポートを高速化していました。ユーザーが一部のパーティションのデータのみをインポートしたい場合、パーティション交換という方法を用いる必要がありました。これは、まずフルダイレクトロードでパーティションのデータを非パーティションテーブルにインポートし、次に対応する非パーティションテーブルとターゲットパーティションをパーティション交換するという手順でした。この操作はユーザーにとってやや面倒でした。パーティションレベルでのデータインポートをより適切にサポートするため、V4.3.5では
LOAD DATAおよびINSERT INTO SELECT構文を使用して、特定のパーティションのダイレクトロード経路を指定できるようになりました。ただし、最終レベルのパーティションタイプがHash/Keyであるパーティションの指定はサポートされません。詳細については、フルダイレクトロードまたは増分ダイレクトロードを参照してください。
select into outfile機能の強化V4.3.5では
select intoエクスポート機能が改善され、select intoによるparquetおよびorc形式へのエクスポートがサポートされました。また、select intoによるcsv形式へのエクスポート時に圧縮アルゴリズムを指定できるようになり、select intoに新しい構文が追加されました。- format構文を使用したエクスポートオプションの設定
- csv形式ファイルのエクスポート時の圧縮アルゴリズム指定
- parquet形式ファイルのエクスポート
- orc形式ファイルのエクスポート
インデックスの強化
全文インデックス機能の強化
V4.3.5は、V4.3.4の基盤の上で全文インデックス機能を継続的に改善しており、主な内容は以下の通りです：
CREATE FULLTEXT INDEXまたはALTER TABLE ADD FULLTEXT INDEXステートメントを使用した全文インデックスの作成をサポートします。- コストに基づく全文インデックス計画の選択をサポートします。
MATCH AGAINSTを含む複数のfilter（フィルター）を持つSQLに対して、コストに基づいてスキャンにかかるオーバーヘッドが小さいインデックスを選択して実行することをサポートします。 - Functional Lookupをサポートします：
- クエリステートメントに複数の
MATCH AGAINST式を含めることをサポートします。 - 全文インデックスを利用しながら他のインデックスも利用することをサポートします。
- filter意味を持たない
MATCH AGAINSTを投影列として出力することをサポートします。 - filter意味を持つ
MATCH AGAINSTで、<=/<などの記号を使用したフィルタリングをサポートします。 - filter意味を持つ
MATCH AGAINSTと、他のfilter意味を持つロジックとのAND/OR結合をサポートします。
- クエリステートメントに複数の
詳細については、MATCH AGAINSTを参照してください。
外部データソースの統合
外部テーブルの拡張
V4.3.5バージョンでは、外部テーブルがORC形式ファイルの読み取りをサポートします。
詳細については、外部テーブルの作成（MySQLモード）または外部テーブルの作成（Oracleモード）を参照してください。
カラムストアのストレージ最適化
- 読み取り専用カラムストアレプリカ
V4.3.3バージョンでサポートされた読み取り専用カラムストアレプリカ機能は実験的な機能でしたが、V4.3.4およびV4.3.5バージョンのイテレーションを経て、V4.3.5バージョンではGA要件を満たしています。
行ストアからカラムストアへの変換操作で非同期オンラインDDLをサポート
V4.3.0バージョンでは、テーブルの3種類のストレージ形式（行ストア/純粋カラムストア/行列混合ストア）をサポートしていました。行ストアテーブルを行列混合ストアテーブル/カラムストアテーブルに変換するには、オフラインDDLが必要でした。オフラインDDLが顧客に与える影響を軽減するため、V4.3.5バージョンでは行ストアからカラムストアへの変換を非同期オンラインでサポートします。DDL実行時にキーワード
delayedを指定することで、テーブルスキーマ情報をリアルタイムに変更でき、ユーザーのデータ書き込みをブロックせずにオンラインを実現します。その後、カラムストアのベースラインデータの再編成は、ベースラインデータのメジャーコンパクション時に非同期で実行されます。V4.3.5では、行ストアテーブルからカラムストアテーブルへの変換および行ストアテーブルから行列混合ストアテーブルへの変換もオンラインDDLとしてサポートします。
パフォーマンス最適化
ダイレクトロードの書き込みパスのベクトル化
V4.3.5バージョン以前では、ダイレクトロードの実装にベクトル化が行われておらず、書き込み関数はすべて行単位で処理されていたため、関数呼び出しのオーバヘッドが非常に大きかったです。また、SSTLEへの書き込みはバックグラウンドプロセスであり、一部の操作に対しては特化した最適化が施されていませんでした。V4.3.5バージョンでは、ダイレクトロードパスにベクトル化を導入し、カラムストアエンコーディングを最適化することで、ダイレクトロードのパフォーマンスを向上させました。検証の結果、主キーのないカラムストアテーブルのシナリオにおけるダイレクトロードのパフォーマンスは約2倍向上することが確認されています。
データ型とストレージの最適化
JSON複数値インデックスが複雑なDMLをサポート
V4.3.5のJSON複数値インデックスは、複雑なDMLステートメントへのサポートを完全に改善しました。
update、deleteなどのステートメントで複数値述語をサポートし、複数値インデックスでテーブルに戻る複雑なDMLもサポートしています。より豊富なARRAY式をサポート
OceanBaseはV4.3.3バージョンでARRAYデータ型をサポートしました。業務におけるARRAY型の利用をより効果的に支援するため、V4.3.5バージョンでは、業務の多様なシナリオのニーズを満たすために、より多くのARRAY式をサポートしています。新バージョンでは、
array_append、array_distinct、arrayMap、array_remove、cardinality、element_at、array_contains_all、array_overlaps、array_to_string、array_agg、unnest、rb_buildなどのARRAY式が追加されています。
V4.3.4
バージョン情報
- リリース日：2024年10月31日
- バージョン番号：V4.3.4
新機能/機能強化
ストレージアーキテクチャの最適化
共有ストレージ（実験的機能）
パブリッククラウド環境でユーザーによりコストパフォーマンスの高いデータベースサービスを提供するため、OceanBase V4.3.4は汎用オブジェクトストレージに基づき、初めてShared-Storage Cluster共有ストレージアーキテクチャを導入しました。テナントのマルチレプリカが標準オブジェクトストレージ上で共通のベースラインデータとログデータを共有し、自動ホット/コールド分離メカニズムにより、ホットデータをクラウドディスクやローカルSSDに、コールドデータを標準オブジェクトストレージに格納することで、データベースのストレージコストを削減します。テナントの各レプリカがローカルストレージ上でホットデータとログのみをキャッシュするため、コンピューティングノードの迅速なスケーリングが可能です。共有ストレージアーキテクチャは、現在、ホットデータとコールドデータの区別が明確なTP業務、および業務がレイテンシに敏感でないシナリオ（例：履歴データベース、バックアップデータベースなど）やKVおよび時系列業務に適用されます。
V4.3.4ではこの機能は実験的機能として定義されており、今後のバージョンで正式な本番機能として継続的に改善される予定です。
インデックス機能の強化
全文インデックス機能の強化
OceanBaseはバージョン4.3.1から全文インデックス機能をサポートしており、テキスト内容を事前処理してキーワードインデックスを構築することで、全文検索の効率を大幅に向上させています。しかし、全文インデックスを伴う複雑なDMLシナリオでは、いくつかの制限があり、業務運用上の不便が生じていました。業務の発展をより良く支援するため、4.3.4バージョンでは複雑なDML機能が改善され、全文インデックスを含むメインテーブルに対して、INSERT INTO ON DUPLICATE KEY、REPLACE INTO、複数テーブルの更新・削除、更新可能なビューなどの複雑なDML操作がサポートされるようになりました。さらに、新バージョンではベクトル実行やTAAT処理戦略の拡張などにより全文検索のパフォーマンスが最適化され、MATCH AGAINST句のトークン数制限が撤廃され、主キーのないパーティションテーブルに対しても全文インデックスの作成が可能になりました。同時に、新バージョンではトークナイズ関数を用いて分かち書き結果を確認できるようになり、分かち書きシステムのデバッグを支援します。
複数値インデックス機能の強化
現在、複数値インデックスは事前に作成されたインデックスのみをサポートしており、DMLやDDLなどの操作にはいくつかの制限がありました。業務利用をより良く支援するため、V4.3.4バージョンでは一部の制限を撤廃し、機能を強化しました。主に、
INSERT INTO ON DUPLICATE KEY、REPLACE INTO、複数テーブルの更新・削除、更新可能なビューDML機能などの複雑なDML操作をサポートします。詳細については、複数値インデックスの作成を参照してください。
データインポートの最適化
増分ダイレクトロードが非一意のローカルインデックスをサポート
OceanBaseはフルダイレクトロードと増分ダイレクトロードをサポートしており、テーブルに既存データがある場合、増分ダイレクトロードの方がフルダイレクトロードよりもパフォーマンスが優れています。以前は増分ダイレクトロードではインデックス付きテーブルへのデータインポートがサポートされていませんでしたが、V4.3.4では、非一意のローカルインデックスを持つテーブルへのデータインポート機能がサポートされました。
ダイレクトロードのパフォーマンス最適化
ダイレクトロードでデータをインポートする際、主キーを持つテーブルでソートが必要な場合、データはまず一時ファイルに書き込まれ、その後一時ファイルからメモリに読み込まれてソートとマージ処理が行われ、最終的にsstableに書き込まれます。この方法では、データのインポートを「データ書き込み段階」と「ソート・マージ段階」の2段階に分けています。データが完全に書き込まれていない場合、後続のソート・マージ段階を開始できません。また、書き込みI/Oがボトルネックに達すると、間接的にダイレクトロードのパフォーマンスもボトルネックに達します。V4.3.4ではデータのインポート方式を最適化し、データを一時ファイルに書き込むことなく、直接メモリに書き込んだ後、その後のソートとマージ処理を行います。この最適化により、データのインポートとソートがパイプライン式に連続して行われるため、前段階が後段階に影響を与えることがなくなります。主キーを持つテーブルのシナリオでは、データ量1Tの場合、インポート全体のパフォーマンスが35%向上し、最適化効果は顕著です。メモリとCPUが大きいほど、データの処理とローテーションのプロセスでのパフォーマンス向上が大きくなるため、この最適化は大規模テナントシナリオに非常に適しています。同時に、小規模テナントではパフォーマンスが明らかに低下することはありません。
データ型とストレージの最適化
Bitmap機能の強化
Bitmap、別名ビットマップは、集合内に特定の要素が存在するかどうかを効率的に格納および処理するためのデータ構造です。OceanBase V4.3.2、V4.3.3は順次RoringBitmapの一部機能をサポートし、V4.3.4ではさらに完備し、
rb_iterateとrb_selectの式を新たに追加しました。rb_iterateはroaringbitmap型を要素数に応じて1列多行に展開するために使用され、rb_selectは条件に基づいてroaringbitmap型内の要素をフィルタリングし、新しいroaringbitmap型を返すために使用されます。
V4.3.3
バージョン情報
- リリース日：2024年9月30日
- バージョン番号：V4.3.3
新機能・機能強化
カラムストアストレージの最適化
読み取り専用カラムストアレプリカ（実験的機能）
OceanBase V4.3.0からカラムナストレージがサポートされ、業務タイプに応じてカラムストアテーブル、行ストアテーブル、または行列混合テーブルを作成できるようになりました。どのテーブル形式で定義されているかに関わらず、レプリカモードはテナント内の異なるゾーン間で一貫しています。例えば、テナントXのユニットが1:1:1に分散しており、T1が行列混合テーブルの場合、T1テーブルは3つのゾーンすべてに行ストアレプリカとカラムストアレプリカがそれぞれ1つずつ存在します。HTAPハイブリッドワークロードシナリオにおいて、TPとAPリソースの物理的強制分離要件を満たすため、V4.3.3では新しいデプロイメント形態を導入し、既存クラスタの基盤上に、読み取り専用カラムストアレプリカ（Column Store Replica、略称：Cレプリカ）を格納するための単独ゾーンを拡張できるようにしました。このゾーン上のすべてのユーザーテーブルはカラムストア形式で保存され、AP業務は独立したODPを使用し、SESSIONレベルのシステム変数
ob_route_policyをCOLUMN_STORE_ONLYに設定することで、カラムストアレプリカに対する弱い読み取り方式のクエリ分析にアクセスできます。これにより、元のTP業務に影響を与えません。一方、3+1ゾーンのようなデプロイメント形態は、行列混合に比べて、ストレージコストも節約できます。ODP V4.3.2以降のバージョンと併用する必要があります。詳細については、カラムストアレプリカを参照してください。V4.3.3ではこの機能を実験的機能として定義しており、今後のバージョンで正式な本番機能へと継続的に改善していく予定です。
マテリアライズドビューの強化
マテリアライズドビュー機能の強化
業務における手動リライトコストを削減するため、OceanBase V4.3.1からマテリアライズドビューのリライト機能がサポートされました。システム変数
QUERY_REWRITE_ENABLEDをTrueに設定した状態でマテリアライズドビューを作成する際にENABLE QUERY REWRITEを指定することで、自動リライト機能を使用できます。これにより、システムは元のテーブルに対するクエリをマテリアライズドビューに対するクエリにリライトできます。V4.3.1は、非集約マテリアライズドビューにおいてFROMが完全に一致しWHERE部分が部分的に一致する場合のリライトをサポートしていましたが、V4.3.3ではさらに、非集約マテリアライズドビューのFROM結合互換性、マテリアライズドビューに存在しないテーブルを含むクエリのリライトをサポートし、集約マテリアライズドビューのリライトおよび集約上巻き戻しのリライトもサポートしています。同時に、新バージョンでは増分更新とリアルタイムマテリアライズドビューがサポートするSQLタイプも拡張しました。先行バージョンでは既に、単一テーブル集計や複数テーブル結合シナリオでの増分更新とリアルタイムクエリをサポートしていましたが、V4.3.3では結合集計シナリオのサポートを追加しました。詳細については、マテリアライズドビュークエリのリライト（MySQLモード）およびマテリアライズドビュークエリのリライト（Oracleモード）を参照してください。
また、OceanBaseの以前のバージョンでは行ストア形式のマテリアライズドビューのみをサポートしていましたが、V4.3.3からはカラムストア形式のマテリアライズドビューのサポートも拡張されます。これにより、マテリアライズドビュー参照を含む一部の複雑な分析シナリオで、より優れたクエリパフォーマンスを得る機会が生まれます。詳細については、マテリアライズドビューの作成（MySQLモード）およびマテリアライズドビューの作成（Oracleモード）を参照してください。
データインポートとエクスポートの最適化
外部テーブルインポートのパフォーマンス最適化
V4.3.3では、ダイレクトロードにおける外部テーブルデータ読み取り段階の実行パフォーマンスを最適化し、前バージョンに比べて約15%向上しました。
INSERT OVERWRITE機能の強化
OceanBase V4.3.2からテーブルレベルの上書き機能（INSERT OVERWRITE）がサポートされ、テーブル内の古いデータをクリアし新しいデータを書き込むことを原子レベルで実現しました。これにより、データの定期的なリフレッシュ、データ変換、データクレンジング修正などのAP業務シナリオをサポートします。しかし、V4.3.2ではテーブル全体の置き換え書き込みのみをサポートしており、パーティションレベルでの置き換え書き込みや、特定の列のみを置き換えて書き込む機能は提供されていませんでした。V4.3.3ではこの機能を補完・強化し、INSERT OVERWRITEステートメントでターゲットテーブルをパーティションまたはサブパーティションとして指定することをサポートするとともに、ターゲットテーブルの一部の列情報を指定することも可能にしました。これにより、データの置き換え書き込み方法がより柔軟になり、より多くの業務シナリオに適用できるようになりました。
Load Data/外部テーブルで圧縮ファイルをサポート
Load Dataは一般的なデータインポート方法であり、通常のサーバー側インポート、ダイレクトロード、クライアント側インポートなどの使用シナリオが含まれ、既定の形式のテキストファイルをデータベースにインポートできます。しかし、以前のバージョンでは通常のテキストファイルのみをサポートしており、GZIP圧縮ファイルのような圧縮ファイルは事前に解凍してからインポートする必要があり、操作が複雑でした。新バージョンからは圧縮ファイルのインポートをサポートし、GZIP、DEFLATE、ZSTD形式の圧縮ファイルをロードしながら解凍し、同時に書き込むことが可能になりました。この基盤の上で、CSVファイルの外部テーブルも圧縮ファイルのサポートを拡張し、外部テーブルにアクセスすることで上記の圧縮形式のファイルデータを直接クエリできるようになりました。
データ型とストレージの最適化
ARRAYデータ型
ARRAYはAP業務でよく使われる複雑なデータ型であり、複数の同種の要素を格納できます。リレーショナルデータでは効果的に表現できない多値属性の管理やクエリに関わる場合、ARRAY型は適した選択肢です。OceanBase V4.3.3はMySQLモードでARRAY型をサポートし始め、テーブル作成時に特定の列を数値型または文字型の配列型として定義できるようにし、ネスト配列の定義も可能にしました。また、配列オブジェクトのクエリや書き込みに使用される式の構築、array_contains式とANY演算子を使用して配列に特定の要素が含まれているかどうかを判断することをサポートしています。同時に、+/-/=/!=などの演算子を使用した配列要素の計算や判断もサポートしています。
RoaringBitmapのパフォーマンス最適化
V4.3.2ではRoaringBitmapデータ型と関連する式をサポートし、ユーザープロファイル、パーソナライズドレコメンデーション、精密マーケティングなどの業務シナリオにおける多次元分析ニーズをサポートしましたが、一部のシナリオではパフォーマンスが優れていませんでした。新バージョンでは、RoaringBitmap型の計算におけるパフォーマンス問題を重点的に分析し、メモリの申請と式の実行ロジックを最適化し、不要なパフォーマンスオーバーヘッドを削減することで、cardinality、and/or/xor/andnotおよび集計シナリオにおける実行パフォーマンスを数倍向上させました。
リソース管理と分離
QUERYレベルのリソースグループ設定
OceanBaseは現在、DBMS_RESOURCE_MANAGERシステムパッケージを使用して、ユーザーレベル、バックグラウンドタスクレベル、カラムパラメータレベルのリソースグループを構成し、CPUとIOPSのリソース分離をサポートしています。V4.3.3では、QUERYレベルのリソースグループバインディング機能が新たに追加されました。SQLに
/*+ resource_group('group_name') */ヒントを指定することで、その文が対応するリソースグループのリソースを強制的に使用するようにできます。リソースグループが存在しない場合は、現在のデフォルトリソースグループが使用されます。リソースグループを切り替える際は、セッションの再接続が必要です。
V4.3.2
バージョン情報
- リリース日：2024年7月16日
- バージョン番号：V4.3.2 Beta
新機能・機能強化
データのインポートとエクスポートの最適化
増分ダイレクトロード機能の強化
V4.3.1から増分ダイレクトロードの実験的機能がサポートされましたが、
outrow lobデータのインポートをサポートしない、load_modeがinc_replace（つまりreplaceセマンティクス）の増分ダイレクトロードのみをサポートするなど、いくつかの制限がありました。V4.3.2では、outrow lobデータに対する増分ダイレクトロード機能が追加され、load_modeの値としてincがサポートされるようになりました。デフォルトではinsertセマンティクスですが、SQLでignoreキーワードを指定するとignoreセマンティクスとして動作します。これは正式な機能としてリリースされます。詳細な使用方法については、LOAD DATAステートメントを使用したデータのダイレクトロードおよびINSERT INTO SELECTステートメントを使用したデータのダイレクトロードを参照してください。フルダイレクトロードのパフォーマンス最適化
フルダイレクトロードのシナリオにおいて、新バージョンではデータロードプロセス中の列型変換操作の削減、統計情報収集操作のCPU占有率の低減、
INSERT INTO SELECTのSELECT側でのpk生成ロジックの除去、カラムストアでのsum skip indexのデフォルトでの無効化（ストレージ層でRange内の指定列データの事前集約SUM値に対応）、さらにマイクロブロック検証の無効化（構成パラメータmicro_block_merge_verify_levelを0に設定）により、ダイレクトロードのパフォーマンスが約20%向上しました。SELECT INTO OUTFILEによるパーティションエクスポートOceanBaseは現在、select into outfileを使用して複数のファイルをエクスポートすることをサポートしていますが、データをパーティションに分割した後、パーティションごとにエクスポートする機能はまだサポートされていません。新バージョンでは、パーティションごとのエクスポート機能が追加され、より明確なディレクトリ構造を得ることができます。この基盤の上で、ファイルディレクトリをパーティションを持つ外部テーブルとして構築し、パーティションパスのトリミングによって外部テーブルのクエリ効率を向上させることも可能です。
外部データソースの統合
外部テーブル機能の強化
OceanBaseデータベースは早期からCSV形式のファイル外部テーブルをサポートしてきましたが、AP業務の拡大に伴い、一部のデータレイクシナリオにおいて、Parquet形式の外部データソースを読み取るニーズも非常に一般的であることがわかりました。V4.3.2からParquetファイル外部テーブルがサポートされ、ユーザーは外部テーブルを通じてファイル内のデータをOceanBaseの内部テーブルにインポートすることができるほか、直接外部テーブルを使用してデータソース間の結合クエリ分析も行えます。同時に、外部テーブルがスキャンするファイルディレクトリの有効性を保証するため、新バージョンではファイルディレクトリの自動更新機能が追加されました。外部テーブル作成時に
AUTO_REFRESHオプションを使用してファイルリストの更新方式（手動、リアルタイム、周期的）を指定でき、DBMS_EXTERNAL_TABLE.REFRESH_ALL_TABLE（interval int）システムパッケージを使用して定期的な更新タスクを管理できます。詳細な使用方法については、外部テーブルの作成を参照してください。
パフォーマンス最適化
AP典型的シナリオのパフォーマンス最適化
V4.3.2では、データブロックのプリフェッチ、ベクトル化バッチ処理、Filterのプッシュダウン、比較計算、集計計算、DTL shuffle、単調性Filterなど、全方位の戦略的最適化が行われました。100Gデータ量仕様において、TPCH、TPCDS、ClickBenchなど、多様なAPシナリオのベンチマークテスト性能がV4.3.1と比較して約10%～15%向上しました。
データ型とストレージの最適化
RoaringBitmap
ビッグデータ時代の到来に伴い、企業におけるユーザーデータのマイニングと分析への需要は日々高まっています。RoaringBitmapは、その省スペース性や計算効率の高さから、ユーザープロファイリング、パーソナライズドレコメンデーション、精密マーケティングなどのビジネスシナリオで重要な役割を果たしています。OceanBase V4.3.2からMySQLモードでRoringBitmapデータ型がサポートされ、一連の符号なし整数の格納と操作により、大量データの集合計算や重複除去の性能が向上します。多次元分析ニーズに対応するため、このバージョンでは基数計算、集合演算、Bitmap判定、Bitmap構築、Bitmap出力、集計演算に使用される20種類以上の式をサポートしています。
データ操作の最適化
テーブルレベルの上書き
データウェアハウスにおいて、データの定期的なリフレッシュ、データ変換、データクレンジング修正を行うシナリオでは、データの上書きが一般的な要求です。OceanBase V4.3.2では、テーブルレベルの上書き機能（INSERT OVERWRITE）が新たに追加され、テーブル内の古いデータをクリアし、新しいデータを書き込むことを原子的に実現します。フルダイレクトロード機能を基盤として、INSERT OVERWRITEも高い実行性能を発揮します。V4.3.2はINSERT OVERWRITE tablename SELECT * FROM tablenameの構文をサポートしていますが、パーティションレベルでの上書きは現在サポートされていません。パーティションレベルの機能は、今後のバージョンで提供される予定です。
タスクスケジューリングと非同期実行
非同期タスクスケジューリング
OceanBaseは現在、
insert overwrite、insert select、create table as、load dataなど、多様なデータインポートコマンドをサポートしており、リアルタイムでのデータ取り込みを可能にしています。しかし、リアルタイムインポート方式では、インポート処理中は完了するまで待機する必要があり、セッションを中断することができません。このため、大規模なデータインポートのシナリオでは使い勝手が良くありません。新バージョンでは、DBMS_SCHEDULERに基づき非同期タスクスケジューリング機能を提供しており、ユーザーはsubmit job、show job status、cancel jobなどのコマンドを使用して、非同期インポートタスクの作成、ステータスの確認、タスクのキャンセルを実現できます。
V4.3.1
バージョン情報
- リリース日：2024年5月17日
- バージョン番号：V4.3.1 Beta
新機能・機能強化
マテリアライズドビューの強化
マテリアライズドビューの強化
OceanBase V4.3.0ではマテリアライズドビュー機能がサポートされ、ビューのクエリ結果を事前に計算・保存することで、リアルタイム計算を削減しクエリ性能を向上させ、複雑なクエリロジックを簡略化し、APシナリオの要件をサポートします。この基盤の上で、V4.3.1バージョンはリアルタイムマテリアライズドビュー機能を拡張サポートし、マテリアライズドビューとMLOGの二つのデータに基づくリアルタイム計算能力を提供し、リアルタイム性要求の高い分析業務に適用します。マテリアライズドビューの主キー制約が新たに追加され、ユーザーがマテリアライズドビューに主キーを指定できるようになり、これにより主キーに基づく単一行検索、範囲検索、または関連シナリオのパフォーマンスが最適化されます。同時に、内部結合シナリオにおけるマテリアライズドビューの増分更新能力も拡張サポートされ、一部シナリオのマテリアライズドビュー更新性能が向上しました。
また、V4.3.0バージョンでマテリアライズドビューを使用する場合、業務スクリプト内の元のテーブルへのアクセス計算を手動で対応するマテリアライズドビューへのクエリに置き換える必要があり、人為的なリライトコストが発生していました。新バージョンでは、一部シナリオでのマテリアライズドビューのリライト能力をサポートしており、システム変数
QUERY_REWRITE_ENABLEDをTrueに設定した状態で、マテリアライズドビュー作成時にENABLE QUERY REWRITEを指定することで、マテリアライズドビューの自動リライト能力を利用できます。これにより、システムは元のテーブルへのクエリをマテリアライズドビューへのクエリにリライトでき、業務改革量を削減できます。マテリアライズドビューの自動リライトの詳細については、マテリアライズドビュークエリのリライト（MySQLモード）およびマテリアライズドビュークエリのリライト（Oracleモード）を参照してください。
データインポートとエクスポートの最適化
増分ダイレクトロード（Experimental）
OceanBase V4.1.0からダイレクトロード機能がサポートされ、データロードの実行パスを簡略化し、SQL、トランザクション、MemTableなどのモジュールをスキップしてデータを直接SSTableに永続化することで、データインポート効率を大幅に向上させました。しかし、テーブルデータを複数回インポートするシナリオでは、毎回のインポートごとにテーブル内の既存データを書き直す必要があり、増分インポートの性能に影響を与えていました。V4.3.1は増分インポートシナリオを特定して最適化し、増分ダイレクトロードでは既存データを書き直す必要がなく、新規データのみを処理するため、複数回のインポートを初回インポートのように高性能に実行できます。
LOAD DATAおよびINSERT INTO SELECTステートメントで/*+ direct(need_sort, max_errors_allowed, load_mode)*/ヒントを使用して、増分ダイレクトロード機能の有無を指定できます。load_modeを指定しない場合、またはload_modeがfullの場合は、従来のフルダイレクトロード方式を使用します。load_modeをinc_replaceに指定すると、増分ダイレクトロード方式を使用します。この機能はV4.3.1では実験的機能として定義されており、今後のバージョンで機能を拡張し、本番利用可能な機能へと進化させていく予定です。増分ダイレクトロードの詳細については、ダイレクトロードの概要の増分ダイレクトロードセクションを参照してください。SELECT INTO OUTFILEの性能最適化
現在のselect into outfile機能は、データテーブルの並列読み取りをサポートしていますが、外部ファイルへの直列書き込みしかできず、データエクスポートの性能ボトルネックがありました。V4.3.1は並列エクスポート能力を追加し、select into outfileコマンドにsingle、max_file_sizeオプションを追加して、外部ファイルへのデータ書き込み方法を制御します。singleオプションは、データを単一ファイルまたは複数ファイルにエクスポートするかを制御します。並列度を1より大きく指定し、single = falseの場合、データを複数ファイルにエクスポートでき、並列読み取りと並列書き込みの効果を実現します。max_file_sizeオプションは、エクスポートファイルのサイズを制御します。
インデックスの強化
MySQLモードの全文インデックス（Experimental）
リレーショナルデータベースでは通常、インデックスを使用して厳密値に基づくクエリを高速化しますが、一般的なB-Treeインデックスは、大量のテキストデータを含むファジー検索が必要なシナリオには適用できません。その場合、全表スキャンによって各行データに対してファジー検索を行う必要があり、テキストが長くデータ量が多い場合、性能はしばしば要件を満たせません。また、近似一致や相関ソートなどの複雑なクエリシナリオも、SQLのリライトではサポートすることが困難です。
上記の問題を解決するため、OceanBaseはV4.3.1で全文インデックス機能をサポートしました。テキスト内容を事前処理してキーワードインデックスを構築することで、全文検索の効率を効果的に向上させます。この機能はV4.3.1では実験的機能として定義されており、今後のバージョンで機能を拡張し、本番利用可能な機能へと進化させていく予定です。今回のリリースでは以下の機能が含まれます：
MySQLモードで全文インデックス機能をサポートし、MySQLの基本構文と互換性があります。
- テーブル作成時にCHAR/VARCHAR/TEXT列に対して事前に全文インデックスを構築できます。
- パーティションテーブルに適用されます。
- プライマリテーブルに複数の全文インデックスを作成できます。
- SPACE（スペース）、NGRAM、BENG（基本英語）の3種類の組み込みトークナイザーをサポートします。
- 1つのmatch againstで複数列に対する全文検索をサポートします。
- NATURAL LANGUAGE MODEモードをサポートします。
パーティション管理
パーティション交換
時間の経過とともに、テーブルには大量の履歴データが蓄積される可能性があります。これらのデータは頻繁にアクセスする必要はない場合がありますが、コンプライアンスや履歴データ分析の要件を満たすために保持する必要があります。クエリ性能を向上させるため、業務では通常、アクティブデータと非アクティブデータを区別し、非アクティブデータをアーカイブする必要があります。SQLを使用してデータを新しいテーブルに移行することでこのシナリオの要件を解決できますが、データ量が多い場合、性能は通常優れていません。そのため、OceanBase V4.3.1バージョンではパーティション交換機能が新たに追加されました。データディクショナリ内のパーティションとテーブルの定義を変更するだけで、データの物理的コピーを行う必要がなく、AテーブルのデータをBテーブルの特定のパーティションにほぼ瞬時に移動でき、データ移行の性能を大幅に向上させます。今回のリリースでは以下の機能が含まれます：
- パーティションテーブルの1つのパーティションと通常テーブルとのデータ交換をサポートします。
- パーティションタイプがRange(Range Columns)のパーティションテーブルをサポートします。
- セカンダリパーティションタイプがRange(Range Columns)のセカンダリパーティションテーブルをサポートします。
- including indexes をサポートしており、パーティション交換時に対応するローカルインデックスも交換され、交換後も利用可能な状態が維持されます。
- without validationモードをサポートしており、ユーザーはデータがパーティションキーの範囲に合致することを保証する必要があります。
外部データソースの統合
外部テーブルのパーティション
OceanBase V4.2.0から外部テーブル機能がサポートされていますが、非パーティションテーブルに限定されています。ファイル数が多い場合でも、あるクエリでは理論上は一部のデータファイルのみをスキャンすれば済むシナリオで、非パーティションの外部テーブルでは全量のファイルをスキャンするしかなく、切り捨てができず、パフォーマンスが低下します。V4.3.1バージョンでは外部テーブルのパーティション機能が追加され、通常のテーブルのlistパーティションに似たパーティショニング方法をサポートし、自動/手動の2種類の構文を提供しています。自動でパーティションを作成するよう指定した場合、システムはパーティションキーの定義に従ってファイルをパーティションごとにグループ化します。手動でパーティションを作成するよう指定した場合、ユーザーは各パーティションに対応するデータファイルのサブパスを指定する必要があります。この場合、外部テーブルのクエリはパーティション条件に基づいてパーティションの切り捨てを実現でき、スキャンするファイル数を削減し、クエリのパフォーマンスを大幅に向上させることができます。
データ型とストレージの最適化
MySQLモードのJSON複数値インデックス（Experimental）
MySQL 8.0から複数値インデックス機能がサポートされ、JSONドキュメントやその他のコレクションデータ型に適用されます。これにより、ユーザーは配列やコレクションにインデックスを構築することで、要素の効率的な検索を実現できます。OceanBase V4.3.1はMySQLモードでJSON複数値インデックス機能と互換性があり、複数の要素を含むJSON配列フィールドに効率的なセカンダリインデックスを作成できるようにしました。これにより、複雑なJSONデータ構造に対するクエリ能力が強化され、データモデルの柔軟性とデータクエリの高性能を両立しています。この機能はV4.3.1では実験的な機能として定義されており、今後のバージョンで機能が拡張され、本番運用可能な機能へと進化していく予定です。今回のバージョンでは以下の機能が含まれます：
- 複数値インデックス、複合複数値インデックスの事前作成をサポートします。
- 一意および非一意の複数値インデックスをサポートします。
- 複数値インデックスを作成する際、JSON配列の要素タイプとしてINT、UINT、DOUBLE、FLOAT、CHARなどをサポートします。
- パーティションテーブルに適用されます。
- MEMBER_OF()、JSON_CONTAINS()、JSON_OVERLAPS() 関数での複数値インデックス検索をサポートします。
MySQL JSON Partial Update
一部のユーザーは業務データとしてJSONドキュメントを使用しています。ドキュメントを更新する際、現在は全量読み取った後に全量更新するしかなく、ドキュメントが大きい場合はパフォーマンスが期待に応えられません。V4.3.1バージョンではJSON Partial Update機能が新たにサポートされました。ユーザーが特定の式（json_set/json_replace/json_remove）を使用してJSONドキュメントの一部のフィールドを更新する際、変更する部分のみを更新できるため、全量上書き更新の必要がなく、更新パフォーマンスが向上します。この機能はlog_row_value_options構成パラメータを有効にする必要があります。
クエリ実行とリソース管理
SQL一時結果の圧縮
SQL実行で扱うデータ量が膨大な場合、メモリ不足が発生する可能性があります。その際、一部の演算子は一時的な中間結果をマテリアライズする必要があります。マテリアライズされるデータ量が過大でディスク容量が満杯になると、SQL実行が失敗します。V4.3.1ではSQL一時結果の圧縮機能が新たに追加され、テナントレベルの構成パラメータspill_compression_codecまたはSQLレベルのヒント（例：/*+opt_param('spill_compression_codec', 'lz4') */）を使用して、一時結果を圧縮するかどうかおよび圧縮アルゴリズムを指定できます。一時結果の圧縮を指定すると、一時的なディスク容量の使用量を効果的に削減し、より大規模な計算量を伴うクエリタスクをサポートできます。
V4.3.0 Beta
バージョン情報
- リリース日：2024年3月22日
- バージョン番号：V4.3.0 Beta
新機能
カラムストアエンジン
大規模データの複雑な分析や膨大なデータのアドホッククエリシナリオにおいて、カラムナストレージはAPデータベースの重要な機能の一つです。カラムナストレージは、行指向ストレージとは異なるデータファイルの編成方法であり、テーブル内のデータを列単位で物理的に配置します。データをカラムナストレージで格納すると、分析シナリオにおいてクエリ計算に使用される列データのみをスキャンでき、行全体のスキャンを回避して、I/Oやメモリなどのリソース使用量を削減し、計算速度を向上させます。また、列単位での格納は本質的にデータ圧縮に適しており、高い圧縮率を得やすく、ストレージ容量とネットワーク転送帯域幅を削減できます。
しかし、一般的なカラムストアエンジンの実装では、大量のランダム更新が発生しないことを前提としており、カラムナで整理されたデータが静的であることを保証しようとします。実際に大量のデータがランダムに更新される状況では、避けられないシステムパフォーマンスの問題が発生します。OceanBaseのLSM-Treeアーキテクチャは、ベースラインデータと増分データを別々に処理できるため、このようなシナリオの問題を解決するのに適しています。そのため、V4.3.0バージョンでは、現在のアーキテクチャを基盤としてカラムストアエンジンのサポートを拡張し、一つのコード、一つのアーキテクチャ、一つのOBServer上で、カラムナストレージと行指向ストレージのデータ格納を統合し、TPおよびAPクエリのパフォーマンスを兼ね備えました。
AP業務の移行を容易にし、既存顧客が新バージョンをスムーズに利用できるようにするため、カラムストアエンジンを中心に、オプティマイザーから実行エンジン、DDLからトランザクション処理まで、多くのモジュールで適応と最適化が行われました。これには、カラムナストレージに基づく新しいコストモデルとベクトル化エンジン、クエリプッシュダウン機能の拡張と強化、Skip Index、新しいカラムナエンコーディングアルゴリズム、適応型Compactionなどが含まれます。
業務面では、ユーザーは負荷タイプに応じて、テーブルを行指向テーブル、カラムナテーブル、または行列冗長テーブルに柔軟に設定できます。カラムストアエンジンの詳細については、カラムナストレージを参照してください。
新しいベクトル化エンジン
OceanBaseは初期バージョンで、Uniformデータ記述方式に基づくベクトル化エンジンを実装し、非ベクトル化エンジンに比べて性能が大幅に向上しました。しかし、深層APシナリオでは、まだいくつかの性能上の課題がありました。V4.3.0バージョンでは、ベクトル化エンジン2.0バージョンを実装し、Columnデータ形式記述に変更することで、ObDatumのメンテナンスに伴うメモリ使用量、シリアライゼーション、読み書きアクセスのオーバーヘッドを回避しました。データ形式記述に基づく再構築により、新バージョンでは、HashJoin、AGGR、HashGroupBy、Exchange(DTL Shuffle)など10項目以上の演算子、関係演算、論理演算、算術演算など20項目以上のMySQL式など、一連の一般的な演算子と式が再実装されました。今後のV4.3.xバージョンでも、新しいベクトル化エンジンに基づき、他の演算子と式の実装を継続的に補完・改善し、APシナリオでより優れた性能を実現していきます。
マテリアライズドビュー
V4.3.0バージョンでは、マテリアライズドビュー(Materialized View)機能が新たに追加されました。マテリアライズドビューはAP業務を支える重要な機能であり、ビューのクエリ結果を事前に計算・保存することで、リアルタイム計算を削減してクエリ性能を向上させ、複雑なクエリロジックを簡略化します。これは、高速なレポート生成やデータ分析シナリオで広く利用されています。
マテリアライズドビューは、クエリ性能を最適化するためにクエリ結果セットを保存する必要があり、マテリアライズドビューとベーステーブルの間にはデータ依存関係が存在します。ベーステーブルのデータに変更があるたびに、マテリアライズドビュー内のデータも同期を保つために対応する更新を行う必要があるため、新バージョンではマテリアライズドビューのリフレッシュメカニズムも導入されました。これには、フルリフレッシュと増分リフレッシュの2種類の戦略が含まれます。フルリフレッシュは比較的直接的な方法で、リフレッシュ操作を実行するたびに、システムはマテリアライズドビューに対応するクエリステートメントを再実行し、既存のビュー結果データを完全に計算して上書きします。この方法は、データ量が比較的小さいシナリオに適しています。対照的に、増分リフレッシュは、前回のリフレッシュ以降に変更された部分のみを処理します。正確な増分リフレッシュを実現するために、OceanBaseはOracle MLOG(Materialized View Log)に類似したマテリアライズドビューのログ機能を実装し、ログを通じてベーステーブルの増分更新データを詳細に追跡・記録することで、マテリアライズドビューが迅速な増分リフレッシュを行えるようにしています。増分リフレッシュ方式は、特にデータ量が膨大で変更頻度が高い業務シナリオに適しています。マテリアライズドビューの詳細については、マテリアライズドビュー(MySQLモード)およびマテリアライズドビュー(Oracleモード)を参照してください。