この記事のポイント
- 従来型のデータベースについて問題点を述べているYo
- 分散SQLとNewSQLについて説明しているYo
- OceanBaseとSeekDBについて説明しているYo
はじめに
この記事ではこれまでの登壇内容を振り返る内容となっています。
具体的には2026年7月16日開催、「その深夜のデータベースメンテナンス、本当に必要ですか？」というイベントの登壇資料を振り返ります。振り返る資料は以下のとおりです。
話した内容の目次
主にOceanBaseの第一印象を中心に良いところ悪いところをズバリお伝えしました。
また、SeekDBについても触れ、各DBの位置づけをお伝えしました。
従来型のデータベースが抱える問題点
まずは導入として従来のデータベースが抱える問題点について説明しました。
筆者が実感として持っている問題点としては以下のとおりです。
- トランザクション(OLTP)とアナリティクス(OLAP)が別のDBになりがち
- NoSQL vs RDBの対立構造、うまくハマる方法を探しがち
- スケールアウト（横方向の拡張）の限界と高コスト
- 深夜のメンテナンスウィンドウの必要性（無停止運用の困難さ）
トランザクション(OLTP)とアナリティクス(OLAP)が別のDBになりがち
まずはアプリケーションが利用しているDBと分析で利用しているDBが異なるという問題です。
あえて異なるように設計している場合は問題ないですが、ニアリアルタイムの分析においては致命的なところです。また、DB毎に運用組織が異なるという組織単位での分断もあります。
アプリケーションDBを管理しているのはデータベース管理者である一方で分析DBを管理しているのは分析部署のデータエンジニアその他というケースもあります。
NoSQL vs RDBの対立構造、うまくハマる方法を探しがち
2つ目にアプリケーションの設計に都合によってデータ構造を変えることがあるという話です。
RDBを使うケースにおいてはデータモデルがベースにありますが、NoSQLの場合はAPI都合となるケースがあります。そして、この２つのDBをうまく組み合わせたアーキテクチャは実際に存在するものです。
どちらが良いかは言えませんが、異なるDBを持つということを考えると運用コストや可用性をより一層気にする必要が出てきます。
スケールアウト（横方向の拡張）の限界と高コスト
3つ目にスケールアウトの限界です。
多くの場合においてはマルチAZによる冗長化をしたまま水平スケールをしていると思います。水平スケールは技術的にはほぼ際限なく可能なものですが、実際の運用となるとコストを意識しないといけません。実際はスケールできる最大数を決めていることも少なくはありません。
深夜のメンテナンスウィンドウの必要性（無停止運用の困難さ）
最後にメンテナンスウィンドウです。
ミドルウェアのアップデートやスキーマの更新などDBでは停止を伴う作業を行う必要があります。多くの場合においてはそれは営業時間外の深夜帯に行われるでしょう。可能であれば、無停止で問題なくやりたいと思うはずです。
分散DBとNewSQL
これまでの話をまとめると無停止で運用ができてかつ大きくスケールできるDBが必要です。そこで分散DBの登場です。
分散DBというのはつまり、複数のDBを1つのDBとして見せるDBのことです。そして、この分散DBを実現するものとしてNewSQLがあります。NewSQLについてはここでは割愛
コンセンサスアルゴリズムの話
分散DBというのはデータを複数のDBに分割します。
しかし、分割して保有するということはすなわち全体として整合性を保つ必要があります。ここで登場するのがコンセンサスアルゴリズムです。
コンセンサスアルゴリズムとは
コンセンサスアルゴリズムは多数決によって正しいデータを確定するための合意を得るアルゴリズムのことです。何のことかよくわからない部分が多いので具体例を見ていきましょう。
まずは更新要求と提案です。
更新要求と提案ではクライアントからの提案をもとにLeaderを決めて、更新の提案を作成します。提案が作成できたら合意と決定を行います。
複数のNodeで多数決を行い、一番多かった返信を採用します。そしてデータを確定します。
コンセンサスアルゴリズムのポイントとしてはNode同士で通信するというところです。
過半数が合意したものを正しいものとして扱い、一部のNodeが故障してもサービスが継続できるという特徴があります。
代表的なコンセンサスアルゴリズムとしてはPaxosやRaftがあり、OceanBaseはPaxosを複数使ったMulti-Paxosを採用しています。
OceanBaseを理解する4つの視点
では、OceanBaseとはいったい何者なんでしょうか。OceanBaseを理解するために今回は4つの視点で説明します。
- 一般的なRDBMSと何が違うのか
- 分散データベース特有の難しさ
- OceanBaseが向いているケースと向いていないケース
- OceanBaseの技術をAI検索に展開したSeekDB
一般的なRDBMSと何が違うのか
一般的なDBとどのように違うのか簡単に説明すると以下の2点が主に異なるところです。
- 1台を強くするのではなく、クラスタ全体で動かす
- データを複数のOBServerに分割して配置し、クラスタ全体で処理する
一般的なRDBではプライマリーとレプリカで2つのサーバーを持ちます。一方でOceanBaseの場合はOB Proxyを起点に複数のOB Serverをつなげ、クラスタ全体で動かします。
OB Proxyの役割
OB Proxyというのは複数のDBを束ねる司令塔のようなものです。このプロキシが動いていることによってアプリケーションは複数に分割されたDBを意識する必要がありません。リクエストに応じてDBの処理をルーティングしています。
無停止更新
リクエストに応じてDBの処理をルーティングしていることに関連して、OceanBaseは無停止更新ができます。クラスタを稼働したままリソースが追加できるということです。
分散データベース特有の難しさ
ここまでの流れを聞くと良いことづくめに聞こえるかもしれませんが、分散DBであるがゆえの課題もあります。
それはコンセンサスアルゴリズムの特徴にもあったNode同士が通信することにあります。基本的にデータを更新しても問題ないかの決定をとるために合意形成アルゴリズムを実行する必要があります。
合意形成コストが多ければ多いほど、Node間の通信は増えるため、Node数は増やせば良いというものではありません。
また、分散トランザクションを動かすという観点においてはNode数は少ないほうが良いです。
理由としてはデータがどこに保存されているかパーティションでどのように区切られているかがあります。複数のパーティション間にデータが点在する場合はNode間の通信は増えます。分散トランザクションのコストは考慮しないといけないということです。
OceanBaseが向いているケース
- 停止時間を短くしたい基幹システム
- 大量の同時更新を扱うサービス
- RPOとRTOに厳しい要件があるシステム
- データ量やアクセス量の継続的な増加が見込まれるシステム
- SQLやトランザクションを維持したまま水平拡張したいシステム
大規模トラフィックだけでなく、停止できないことや将来的に拡張することに価値のあるシステムが候補となり得ます。とても厳しいトランザクションと可用性を要求される決済システムには向いているでしょう。
OceanBaseが合わないかもしれないケース
- 小規模で単一Nodeでも十分なシステム
- 高可用性や水平拡張を必要としないシステム
- マネージドサービスを利用しても、分散トランザクションや性能設計を扱う知識は必要（後述）
- Node間通信が多くなるデータモデル
- 特定のDB製品固有機能や完全な互換性に強く依存するシステム
- コストよりも構成の単純さを優先したいシステム
すぐれたDBではありますが、要件によってはOceanBaseがオーバースペックになることもあります。
分散トランザクションや性能設計を扱う知識は必要
どんなにマネージドサービスを活用しても運用がなくなることはありません。何かしらの形で運用をすることになります。
では、深夜のデータベースメンテナンスが必要になるのかというところですが、結論から言うとほぼYesだと思います。
「運用はなくなる」のではなく、「運用の中身が変わる」ということにはなるんですが、データ設計を深夜にやるかどうかを聞かれたら、おそらくNoと答えるのではないかなと思います。
OceanBaseの技術をAI検索に展開したSeekDB
OceanBaseの特徴がわかったところで小さくアプリケーションを作りたい場合はどうすれば良いでしょうか。OceanBaseはその特徴ゆえに小さく始めることが苦手のようにも見えます。昨今においてはAIアプリケーションをサクッと作るためにDBを使うことも少なくはありません。
そこでRAG、エージェント検索を小さく構築できるSeekDBについて説明します。
SeekDBとは
OceanBaseは大規模な分散SQLデータベースである一方でSeekDBはAIアプリケーションで必要になる検索やデータ管理をより小さく始めやすい形で提供するDBです。
OceanBaseとSeekDBは単純な上位版と下位版ではありません。OceanBaseは分散・高可用な業務データベースを中心とし、SeekDBはAIアプリケーションや検索用途から使い始めやすいデータベースです。
なぜ、SeekDBにRDBの機能が必要なのか
ここでひとつSeekDBの特徴にあったRAGについて補足です。RAGではベクトルの近さだけを検索すれば良い思われがちですが、そうとは限りません。ユーザーの権限や文書の種類、更新日時など、構造化された条件と組み合わせて検索する必要があります。
例えば、「この質問に近い文書」だけでなく、「このユーザーが閲覧可能」「過去30日以内に更新された文書」といった条件も同時に満たす必要があります。
そのため、ベクトル検索だけでなく、SQLによる条件検索を1つのデータベースで扱えることに意味があります。RAGでは「似ている文書を探す」だけではなく、「業務上取得してよい文書だけを返す」ことが重要です。
条件付きのベクトル検索を実現できて初めて、業務アプリケーションへの採用を現実的に検討できるようになります。このようなベクトル検索とSQLを組み合わせた検索を、1つのデータベースで実現できることがSeekDBの大きな特徴です。
OceanBaseの始め方（個人的なオススメ）
OceanBaseとSeekDBの話は以上です。ここからはオススメの始め方についてお伝えします。
まずは公式のGet startedをやってみることをオススメします。
インスタンスの種類には3つ、始めるならトランザクションインスタンスがおすすめです。
- トランザクションインスタンス
- アナリティクスインスタンス
- キーバリューインスタンス
SeekDBの始め方（個人的なオススメ）としてはpyseekdbをuv環境にインストールして実行するのがオススメです。GitHub Codespacesでも試せます。リンク
Skillsやベクターサーチの例もあります。
まとめ
以上、OceanBaseとSeekDBのリアルでした。今回の検証を通して競合の他の分散SQLについても深く学ぶことができました。結構可能性があるDBという印象を持ちましたのでもっと深く触ってみたいと思いました。
また、OceanBaseを他の文脈で触ってみてどういう風に役立つのかという点についても検証してきたいと思いました。具体的にはAI駆動開発やPlatform Engineering、オブザーバビリティといった領域でOceanBaseがどういった価値を示せるのかが気になっていますので試してみたいと思います。今回は以上です。