業務データ、リアルタイム分析、AIワークロード——これまでバラバラだったものをひとつのデータベースに。OceanBase AI Database 詳細はこちら ->
業務データ、リアルタイム分析、AIワークロード——これまでバラバラだったものをひとつのデータベースに。OceanBase AI Database 詳細はこちら -> ->
OceanBase
OceanBaseとデータベースに関する技術トレンド、プロダクト解説、ユーザー事例をお届けし、より深い理解と活用を支援します。
著者の記事一覧
OceanBaseのベクトル検索を支える技術：高速化とコスト削減
ベクトル検索を本番環境で使うには、検索速度に加え、データが増えたときの拡張性や運用コストも考える必要があります。数百万件では快適に動いていたシステムでも、数億件になると、応答の遅延やメモリ不足への対応が課題になります。 OceanBaseは、日々の業務を支えるトランザクション処理と、意味や類似度に基づくベクトル検索を一つのデータベースで扱えます。データを複数のサーバーに分散する仕組みと、独自開発のベクトル検索ライブラリ「VSAG」を組み合わせ、データの増加に対応しながら、検索性能とコストの両立を図ります。 その基盤となるのは、業務処理や分析処理の性能を測るTPCベンチマークで世界記録を達成した...
OceanBaseのハイブリッド検索：ベクトル検索・全文検索・フィルタリングを1つのSQLで
AIアプリケーションの検索基盤では、ベクトルデータベース、リレーショナルデータベース、検索エンジンを組み合わせる構成がよく使われます。PoCの段階では合理的に見えるこの構成も、本番運用に入ると、データ同期の遅延、検索処理の複雑化、運用負荷の増大といった課題が顕在化します。 OceanBaseは、V4.4.1からハイブリッド検索をサポートしています。V4.6.0では、SQLから直接利用できるHYBRID_SEARCHインターフェースを追加しました。ベクトル検索、全文検索、スカラー値によるフィルタリングを1つのSQLに集約し、複数のシステムに分散していた検索処理をデータベース内で実行できます。 本...
［イベント情報］db tech showcase 2026 Tokyo セッション登壇のご案内
『db tech showcase 2026 Tokyo』OceanBase セッション登壇 & ブース出展決定！ OceanBase Japan（以下「OceanBase」）は、2026年11月5日(木)～6日(金)の2日間にわたり開催される、国内最大級のデータベースカンファレンス「db tech showcase 2026 Tokyo」に協賛し、2つのスペシャルセッションに登壇いたします。 本カンファレンスは、DBエンジニア、データサイエンティスト、ITリーダーが一堂に会する国内最大級の技術イベントです。AI時代のデータ基盤のあり方や、脱シャーディング・クラウド時代のDB選定など、現場の最...
分散データベース運用でOceanBaseが複雑さを抑えられる理由
1. データベースのインスタンスが増えると、運用はどう変わるのか 事業が成長し、マイクロサービスの導入が進むと、注文、ユーザー、在庫、レポートなどのサービスごとに、独立したデータベースが必要になることがあります。開発、テスト、ステージング、本番の各環境に加え、顧客やチャネルごとにデータを分離する必要も出てきます。その結果、わずか1〜2年で、インスタンス数が十数個から100を超える規模に増えることもあります。これらを個別に管理していると、監視、変更作業、原因調査、復旧にかかる負担も増していきます。 アラートが増え、重要な問題を見つけにくくなる。100個のインスタンスで監視システム、アラートルール...
垂直スケールでも瞬断は避けられるのか？
これまでの記事では、OceanBaseが、ネイティブ分散アーキテクチャによってアプリケーションをシャーディングから解放する仕組みや、テナントのリソース構成を変更することでトラフィックの変動に秒単位で追従する仕組みを紹介してきました。 テナント（独立したリソース割り当てを持つDBインスタンスに相当）のリソース構成を変更する場合、既存の物理マシン上でCPUやメモリなどの割り当てを再配分するだけで済むため、ハードウェアの変更は不要です。業務時間中でも実行でき、アプリケーションからは完全に透過的で、サービス停止も発生しません。 ただし、この方法にも限界があります。単一マシンで利用できる物理リソースには...
稼働するだけでは不十分：OceanBaseが保証するデータ整合性
はじめに：サービスは稼働中。しかし、そのデータは本当に正しいのか？ 2021年、Meta社は数十万台のマシンを対象に18ヶ月間にわたり実施した監視調査をまとめた研究論文「Silent Data Corruptions at Scale」を発表し、サイレントエラーを引き起こすCPUが数百個も検出されたことを明らかにしました。結論として、サイレントデータ破損（Silent Data Corruption: SDC）は、特定のハードウェアにおける偶発的な故障ではなく、「世代を超えたシステム的な課題（systemic problem）」であると明確に指摘されています。同年、Google社も論文を発表し...
OceanBaseのアービトレーションサービスとは？ 2F1A構成で実現するRPO=0の高可用性
分散データベースで高可用性を設計する際、2ノードのプライマリ・スタンバイのような偶数レプリカ構成には根本的な弱点があります。ノード障害やネットワーク分断が起きると過半数を確保できず、安全に新しいリーダーを選べなくなるためです。 この問題への一般的な対策は、3つ目の参加者を加えて投票総数を奇数にすることです。そうすれば、スプリットブレインを防ぎながら合意形成を進めやすくなります。 ただし、この3つ目の参加者が必ずしも完全なデータレプリカである必要はありません。必要なのは、投票に参加し、障害時にクラスタの合意形成を支えることです。OceanBase 4.xでは、この役割を「アービトレーションサービ...
分散データベースからOceanBase AIデータベースへ――OceanBaseの技術進化を読み解く
OceanBaseは、分散データベースから出発し、いまではAI時代に対応する新たな製品群へと進化しつつあります。本記事では、その技術的な歩みをたどります。 OceanBaseの製品進化 OceanBaseは2010年に分散データベースの開発を開始しました。当初はNoSQLデータベースとして位置付けられていましたが、その後は本格的なリレーショナルデータベースへと進化し、MySQLおよびOracleとの互換性も継続的に強化してきました。3.x以降は、トランザクション処理（TP）と分析処理（AP）が混在するワークロードへの対応も強化してきました。実際の基幹業務システムでは、TPとAPを厳密に切り分け...
OceanBase AIが実現するRAGパイプラインの全体像
前回の記事「AI時代のデータベースはどう進化するのか。ベクトル検索だけでは足りない」では、アーキテクチャと価値の観点から、OceanBase AI がマルチモデル統合アプローチを採用する理由を解説しました。1 つのデータベースで業務データ、ベクトル、全文検索、AI 呼び出しを扱い、SQL によってデータからインテリジェンスまでの流れをつなぐ、という考え方です。 本記事では、このコンセプトを実際の技術フローとして実現する方法を掘り下げます。RAG（Retrieval-Augmented Generation）やハイブリッド検索の導入を検討している開発チームが直面する具体的な課題は、以下のような点...
OceanBaseのAI Function入門。SQLでここまでできる
OceanBaseには、`AI_COMPLETE`、`AI_EMBED`、`AI_RERANK`、`AI_PROMPT`、`AI_SPLIT_DOCUMENT` という5つのSQL組み込み関数があります。これらを使うと、テキストのチャンキング、ベクトル化、検索結果の再ランキング、テキスト生成といった処理をデータベースの中で扱えます。ベクトル検索やハイブリッド検索と同じエンジン上で動くので、RAGの一連の流れをSQLでそのままつなげて書けます。 OceanBaseでは、LLMの機能をデータベース関数として利用できます。使い方は`UPPER()`や`SUM()`に近く、モデルのエンドポイントを登録...
LangChainからCursorまで、AI開発のデータ基盤をOceanBaseに集約する
AIアプリ開発でデータ層が分散しやすくなる理由 RAGやAIエージェントを組み込んだアプリケーションを作ると、使うツールは自然と増えていきます。LangChainやLlamaIndexで処理フローを組み立て、OpenAIやローカルモデルで推論を行い、Difyのようなワークフロープラットフォームで業務ロジックをつなぎ、Cursor、Cline、Claude CodeなどのIDEで実装を進める。最近のAI開発では、こうした構成は珍しくありません。 一方で、ツールが増えるほどデータ層は複雑になりがちです。業務データはRDB、ベクトル検索は専用Vector DB、キーワード検索は検索エンジン、エージェ...