OceanBaseは、分散データベースから出発し、いまではAI時代に対応する新たな製品群へと進化しつつあります。本記事では、その技術的な歩みをたどります。
OceanBaseの製品進化
OceanBaseは2010年に分散データベースの開発を開始しました。当初はNoSQLデータベースとして位置付けられていましたが、その後は本格的なリレーショナルデータベースへと進化し、MySQLおよびOracleとの互換性も継続的に強化してきました。3.x以降は、トランザクション処理（TP）と分析処理（AP）が混在するワークロードへの対応も強化してきました。実際の基幹業務システムでは、TPとAPを厳密に切り分けられるとは限りません。
この方向性をさらに推し進めるかたちで、OceanBaseは分散アーキテクチャを土台としつつ、単体構成での性能向上にも注力してきました。分散アーキテクチャを基盤に単体性能も磨き込み、分散型と集中型の技術を単一のコードベースに統合しました。これにより、単体構成で高い性能を実現すると同時に、分散構成まで一貫した利用・運用環境を提供しています。
今回の大きな転換点は、OceanBaseの統合アーキテクチャを基盤として、OceanBase AI Lakebase（以下、Lakebase）という新たな製品群が登場したことです。
Lakebaseの中核となるのは、ストレージおよびコンピュートエンジンです。OceanBaseはこのエンジンを中心に、データ開発とガバナンスのための OceanBase DataStudio、データ開発・分析をAIエージェントとして支援する OceanBase DataPilot、AIエージェントのメモリ管理を担う PowerMem、企業向け文書ナレッジベースの PowerRAG などを整備しています。これらは、いずれもOceanBase AI Lakebaseを中核とする製品群です。
なぜOceanBase AI Lakebaseが必要なのか
では、なぜいまLakebaseが必要になるのでしょうか。既存の考え方と比べて、何が新しいのでしょうか。
従来、データベースの進化は性能やコストを主な競争軸としてきました。一方でAI時代は、その価値を見直すきっかけになっています。ストレージとコンピュートの基盤として、アプリケーションと業務の実課題をどのように解決するかが、いま改めて問われています。
発想自体はシンプルです。AIの進化により、これまで扱いにくかった非構造化データを、体系的に処理・管理し、その内容を理解したうえで活用できるようになりました。機械学習の発展とともに、その兆しはすでに見え始めていましたが、大規模言語モデルと生成AIの急速な普及により、今ではあらゆる企業にとって身近な実務課題になっています。
多くの企業は以前から非構造化データを管理してきました。従来はコンテンツ管理システムを構築してデータを保存するものの、保存後は使われなくなり、ごく一部が時折参照されるだけでした。データ資産という観点から見ると、十分に価値化されていないケースが少なくありません。AIによって、これまでコストとして扱われてきたデータを資産として価値化する必要があります。
企業が保有するデータの80～90%は、容量ベースで見れば非構造化データだとされています。これらを、より適切に活用できるデータ資産へ変えていくには、何が必要なのでしょうか。
OceanBaseの答えは明快です。構造化データの時代に「レイクハウス（Lakehouse）」アーキテクチャが必要だったのと同様に、非構造化データやマルチモーダルデータの管理にも、新しいアーキテクチャである OceanBase AI Lakebase が必要です。OceanBase AI Lakebaseは、構造化データと非構造化データを統合的に管理することを目指しています。
このアーキテクチャはオンプレミスへの導入にも、クラウドサービスとしての提供にも対応します。Lakebaseエンジンは、下位のストレージ層から利用者向けの開発環境まで、複数のレイヤーで構成されています。
- 最下層（ストレージ層）： オブジェクトストレージをはじめとするオープンなストレージアーキテクチャに、構造化・半構造化・非構造化データを格納します。
- 統合データ管理層： データベース技術でインデックスを構築し、構造化テーブル、半構造化データ、そしてマルチモーダルテーブルを統合します。
- コンピュート層： OceanBaseのSQLエンジンを拡張したもので、マルチモーダルデータの管理・計算・処理を担うとともに、SparkやRayなどのオープンなコンピュートエンジンとも連携します。
利用者は主にSQLを使い、Pythonも組み合わせながらデータ開発を完結できます。
さらに、OceanBase内外や異なるデータベースに分散したデータを横断的に活用できるようにするため、エンジンには大幅な拡張を加えています。内部のメタデータをデータレイク上のオープンなコンピュートエンジンからシームレスに利用できるようにするとともに、エンジン内部からもデータレイク上のさまざまなオープン形式のストレージへアクセスできるようにしています。
OceanBase Lakebase統合エンジン
Lakebaseの中核には、長年にわたって磨き上げてきたOceanBaseエンジンがあります。これをLakebase向けに再設計・拡張したもので、最大の変更点はストレージアーキテクチャです。データレイク上のデータと連携するため、オブジェクトストレージをすべてのデータの最終的な保存先および永続ストレージとし、ログサービスによってトランザクションの耐久性を確保します。その上で分散システムとしての特性を維持し、ストレージとコンピュートを分離することで、それぞれを独立して柔軟にスケールさせ、さまざまなデータ形式を格納できるようにしています。
ストレージとコンピュートの分離
まず基盤となるのが、ストレージとコンピュートの分離です。OceanBase 4.4で取り組みを始めたこのアーキテクチャは、現在、Lakebaseとの連携を可能にする構成へと進化しています。
従来のデータベースのように、ストレージ側で複数のレプリカを保持する必要はありません。システム全体ではオブジェクトストレージを中心にデータを一元的に保持し、必要なときに取得できるストレージリソースとして利用します。従来から培ってきた高可用性の仕組みも引き継ぎ、RTOの短縮も図っています。
ストレージとコンピュートを分離すると、AI時代のデータに適した運用を容易に実現できます。たとえば、大量のチャット履歴は、従来の会計システムに保存されるデータほど高い価値密度を持つとは限りません。このため、データのアクセス頻度に応じた自動的な階層化が重要になります。OceanBaseはポリシー制御によってデータを3つの状態に分けます。
- COLD： キャッシュに置かず、常にオブジェクトストレージに保持します。
- HOT： ローカルサービスに保持します。
- AUTO： アクセス状況に応じて、システムが自動的にキャッシュへの配置と追い出しを制御します。
ベクトルデータやチャット履歴のようなテキストデータも、この仕組みを基盤として管理できます。
ハイブリッド検索
もう一つの中核機能は、ハイブリッド検索です。AIエージェントの登場により、データベースには高い検索能力が求められるようになりました。従来は、こうした機能を必ずしもデータベース自体に持たせる必要はありませんでしたが、新しいアプリケーションでは、ベクトル、テキスト、スカラーといった異なるデータを組み合わせて、効率的に検索できることが求められます。
OceanBaseはこの分野の機能を継続的に強化しています。データ型としては密ベクトルと疎ベクトルをサポートし、インデックスについては、インメモリ型のベクトルインデックスに加え、ディスクベースでコスト効率に優れたベクトルインデックスも独自に開発しています。クエリ処理では、複数の検索経路を組み合わせながら、ベクトル検索とテキスト検索を並行して実行し、効率よくフィルタリングします。ベクトル検索は計算負荷が高いため、クエリの最適化では、検索範囲を必要なデータにできるだけ絞り込むことが重要になります。OceanBaseは早い段階から高性能なベクトル検索を提供しており、ベクトル検索に特化した一部のオープンソースエンジンと比べても、多くの指標で優れた性能を示しています。
シンプルな技術スタック
これらの基盤機能を踏まえ、従来のエンジンと比べたLakebaseエンジンの進化を見ていきます。一般に、オープンソース技術を組み合わせてデータプラットフォームを自前で構築する場合、構造化データを管理するだけでも、多数の複雑なエンジンを組み合わせる必要があります。
従来の技術スタックは、一般に3つの層に分かれます：
- オフライン処理層： Hadoopなどのビッグデータ技術を用いたT+1の処理
- リアルタイム処理層： Flinkを代表とするストリーム処理技術
- データサービス・分析層： BIや業務アプリケーションに直接データを提供
この構成では、データレイク上のデータを各エンジンへ取り込まなければなりません。たとえば、初期にはClickHouseをリアルタイム分析に導入しても、単一テーブルのクエリしか扱えず複数テーブルの結合が難しい場合、別のデータベースを追加する必要があります。そのデータベースがポイントルックアップに適さなければ、HBaseのようなNoSQLシステムも必要になります。AI時代にはベクトルデータが加わるためベクトルデータベースが必要になり、メモリの保存やテキスト検索にはElasticsearchなども加わります。新しい要件が出るたびに個別のエンジンを継ぎ足していくと、技術スタックは次第に複雑になり、運用・保守の負担も増していきます。
そこで重要になるのが、OceanBaseエンジンを中核として、より少ないコンポーネントで構造化データ、非構造化データ、マルチモーダルデータを加工・処理できる、よりシンプルなアーキテクチャを実現することです。リアルタイムのデータ処理パイプラインでは、増分更新型のリアルタイム・マテリアライズドビューが中核技術になります。増分マテリアライズドビューを利用すれば、データベース外部のエンジンを導入しなくても、複雑な加工や前処理の大部分を効率よく実行できます。
このアーキテクチャでは、不要な全量再計算や外部システムとの重複処理を避けられます。管理者は「何を作るか」を宣言するだけでよく、「どのように処理するか」はエンジンに委ねられます。増分処理によって階層的なデータ変換を実現する考え方であり、複雑な外部処理パイプラインの運用に伴う課題を減らします。
マルチモーダルテーブル
次に、重要な製品技術である マルチモーダルテーブル を説明します。
マルチモーダルテーブルは、従来のリレーショナルテーブルを拡張したものです。OceanBaseのエンジニアが顧客とマルチモーダルデータの管理・ガバナンス要件について議論する中で、多くの企業がテキスト、画像、音声、カメラ映像などを解析・理解し、構造化データまたは半構造化データへ変換して管理・活用したいと考えていることが分かりました。そこから、これらの情報を一つのテーブルに対応付けて管理できないかという発想が生まれました。
OceanBaseのマルチモーダルテーブルには、主に次の機能があります：
- ハイブリッド検索： マルチモーダルデータに対する効率的な検索機能。
- 半構造化データの照会： JSONなどの半構造化データを効率よく検索・照会する機能。
- 刷新されたLOB設計： 大規模オブジェクト（LOB）の実装を再設計し、数十GBの動画を1列に保存しても読み書きコストが余分に大きく増えない構成を実現。
具体的には、小さいLOBは実際のLOB値を表の行（インライン）に格納する INROW方式、大きいLOBは表にロケータのみを保持し実データを表の行の外（アウトオブライン）に格納する OUTROW方式 を採用します。オブジェクトとメタデータの対応関係はデータベースが一元管理するため、利用者が自ら管理する必要はありません。
データベースのフォーク（Fork Database）
さらに重要な機能として、データベースのデータを低コストでフォーク（Fork Database）できるようにしています。OceanBaseのストレージアーキテクチャとマルチモーダルテーブルを基盤に、テーブルの論理的な複製をミリ秒単位で作成できます。新しいテーブルを作成する際に実データを丸ごとコピーすることはありませんが、新しいテーブルに対しては完全に独立したテーブルと同様に、すべての作成・参照・更新・削除操作を実行できます。
この機能はAIエージェントの評価で特に重要です。従来のアプリケーションテストでは、テスト環境と本番環境を分離するのが一般的でした。しかしAIエージェントの時代には、評価をオフラインデータで行うべきか、本番に近いオンラインデータで行うべきかという課題が生じます。実務上は、本番に近いオンラインデータのスナップショットを用いて、AIエージェントを評価する方法が有効です。そのため、評価用データサンドボックスを低コストで構築し、短時間で破棄できるほど、フォーク操作が軽量であることが求められます。
AIエージェントのためのデータ基盤
企業内部のオンライン業務で使われるAIエージェントには、新しいアーキテクチャが必要です。Lakebaseを基盤に考えると、AIエージェントは完全なコンテキストを保存できなければなりません。これは比較的理解しやすい要件です。同時に、AIエージェントの実行中に生成される複雑で大容量のデータを保存する必要があります。AIエージェントが継続的に改善していくためにも、こうしたデータを効率よく管理しなければなりません。
これらのデータは、前述のLOBなどの仕組みで扱います。実行中に生成されるデータを、リアルタイムかつオンラインで分析できるかが重要です。たとえば、リスクをリアルタイムで検知・遮断し、リアルタイム分析を行いながら、低コストで保存してオンライン分析まで一体化する必要があります。マルチモーダルテーブルを利用すれば、データレイク上のテーブルデータには、オフライン処理エンジンとニアリアルタイム分析エンジンの双方からシームレスにアクセスできます。そのためには、データ転送に関する課題を解決することが鍵となります。
ここで、AIエージェントの実行時状態と業務データを分離する場合についても考える必要があります。たとえば、EC事業者向けのAIエージェントや、利用者の健康データを扱うAIアプリケーションでは、業務データとAIエージェントの実行時データを連携させなければなりません。OceanBaseの全体構想は、AIエージェントの業務データと実行時データを統合的に管理・連携することを目指しています。これは、今後のAIエージェントにおけるアーキテクチャとデータ編成の進化の方向性でもあります。
さらに、構造化データと非構造化データが混在する場合、それぞれのデータを、AIエージェントが業務上の意味を理解し、適切に検索・分析・活用できる Agent-Ready な状態に整備する必要があります。
マルチモーダルデータの加工パイプライン
ここまで説明したのは、Lakebaseをオンラインのユースケースに適用する部分です。オフラインのユースケースでは、マルチモーダルデータの加工が中心になります。構造化データを階層的に加工するのと同じように、マルチモーダルデータについても、加工の全工程を階層的に進める必要があります。
全体の流れは次のとおりです：
- データ取り込み： ファイルまたはファイルサーバーを起点とし、大規模オブジェクトまたはファイルディレクトリとしてデータをデータセット単位で管理し、Lakebaseエンジンへ取り込みます。
- 初期加工： 専用の マルチモーダルデータ処理エンジン を利用し、大規模モデルと小規模モデルの能力を組み合わせて画像や文書から情報を抽出します。
- ベクトル化・活用： Embeddingなどのベクトル化を実行し、以降の加工や検索に利用できる形にします。最終的には Data API などを通じて加工済みデータを直接照会できるようにします。
これらの技術を大規模モデルまたは小規模モデルの学習に適用する場合、マルチモーダルテーブルを中心に加工フローを構築できます。一つのマルチモーダルテーブル内で、加工前の元サンプルをLOB列に格納します。加工・クレンジングの工程では、CPUやGPUを用いた処理基盤でデータから継続的に特徴量を抽出し、マルチモーダルテーブルにさまざまな型の派生列を追加します。その後、クレンジング、加工、アノテーション（人手によるアノテーションと自動アノテーション）を実施します。
アノテーションが完了したら、マルチモーダルテーブル全体をForkし、Fork時点の状態をデータスナップショットとして確定します。続いてバージョン管理を行い、そのデータを学習クラスタへ渡して学習を実行します。すべてのマルチモーダルデータをバージョン単位で追跡できるため、モデルV1とモデルV2の性能が向上または低下した理由を分析する際、どのデータが変わったのかを正確にたどることができます。
OceanBase DataStudio
最後に、Lakebaseエンジンの上位に、プラットフォーム製品である OceanBase DataStudio を構築しています。
データ開発者にとっては、イメージしやすい製品でしょう。マルチモーダルデータを対象に、データ統合から始め、ツールを使ったデータ加工、マルチモーダルデータのデータリネージ追跡・管理、高品質なデータセットを構築した後の社内展開・共有・利用までをカバーします。データ資産管理、データ品質管理、加工プロセスの運用・保守も含まれます。
DataStudioのアーキテクチャは、構造化データと非構造化データの両方を扱います。マルチモーダルテーブルにより、利用者は構造化データと非構造化データのために別々の知識体系を学ぶ必要がありません。従来、構造化データの管理・開発を担っていたデータ開発者も、必要な知識領域を少し広げるだけで、企業向けに高品質なデータセットを効率よく構築できる、より高度な役割を担えるようになります。
また、プラットフォームは一連のデータエージェント機能を提供します。開発者は、社内の開発プロセスに最も適したスキルやツールを直接呼び出せます。社内データ資産の選定やETL開発も従来より容易になり、特定の開発言語への依存も低減します。これは重要な変化です。企業がデータに業務上の意味づけを整備すれば、自然言語でデータに問い合わせる形で、加工済みデータから直接アプリケーションを生成し、データの価値をさらに引き出すこともできます。
長年OceanBaseを見てきた人にとって、これは大きな変化に映るかもしれません。しかし過去10年以上の歩みを振り返れば、自然な進化でもあります。OceanBaseは一貫して企業の実課題を起点に、段階的に発展してきました。分散データベースからOceanBase AI Lakebaseへと変わったのは、扱えるデータの種類と支えられる業務シナリオです。一方で、「一つの統合エンジンで、企業にコストパフォーマンスの高いデータ基盤を提供する」という本質は変わっていません。