180 Views
July 17, 26
スライド概要
2026年7月16日開催、「その深夜のデータベースメンテナンス、本当に必要ですか?」というイベントの登壇資料です。
https://oceanbase.connpass.com/event/398914/
Cloud Developer,404ニキ,Microsoft MVP,LINE API Expert,PagerDuty Ambassador,Google Cloud PTE/Tech Influencer,AWS Community Builder, #AIDD #AI駆動開発 #dotnetlab 投稿は個人の見解, #AzPoC
実際に触って分かったOceanBaseとSeekDBのリアル その深夜のデータベースメンテナンス、本当に必要ですか? Is that midnight database maintenance really necessary? 30min 1
自己紹介 山田顕人(Kento.Yamada) @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事:DevSecOps、クラウドインテグレーション コミュニティ運営:.NETラボ、AI運用、AI駆動開発 受賞歴(10個、継続中の称号を掲載) ● 初代PagerDutyアンバサダー DevSecOpsの領域で開発と運用とデータ分析を担当 2
今日話すこと 前半 ● OceanBaseの印象 ● 従来型のデータベースが抱える問題点(手短に) ● 分散DBとNewSQL(手短に) 後半 ● OceanBaseの話題 ● SeekDBの話題 ● OceanBaseとSeekDBの関係性 3
欠点が見つからない 第一印象 OceanBase 4
従来型のデータベースが抱える問題点(手短に) ● トランザクション(OLTP)とアナリティクス(OLAP)が別のDBになりがち ● NoSQL vs RDBの対立構造、うまくハマる方法を探しがち ● スケールアウト(横方向の拡張)の限界と高コスト ● 深夜のメンテナンスウィンドウの必要性(無停止運用の困難さ) 5
OLTPとOLAPが別のDBになりがち OLTP DB OLAP DB ミラーリング トランザクションDBと分析DBで分けるアーキテクチャ 例:アプリケーションではOLTP、分析アプリケーションにおいてはOLAP ※NoSQLとPrestoで分析はよくあるパターン、そして運用組織の分断 👉 CDC(Change Data Capture)の同期遅延、データ損失の危険 6
RDB vs NoSQLの対立構造、うまくハマる方法を探しがち Application RDB NoSQL Application NoSQL RDB ● アプリケーションがアクセスするのはRDBが先かNoSQLが先か ● API都合 or データモデル都合 7
スケールアウト(横方向の拡張)の限界と高コスト DB Application スケールできる最大数を決め ている場合は これ以上スケールできない! DB DB ● DBの配置は多くの場合においてマルチAZ配置で冗長化 ● 水平スケールする = 同じ構成でDBが増えてコスト増 8
深夜のメンテナンスウィンドウの必要性 (無停止運用の困難さ) DB Application DBサービスあるいは特定の リージョンやAZにあるDBを 止めることがある。 DB ● 停止切替の作業が必要、大抵の場合は営業時間外で対応 9
分散DBとNewSQL(手短に) NodeA DB Application NodeB NodeC DB DB DB 実際には3つのDBで構成 ● 分散DB:複数のDBを1つに見せること ● NewSQL:SQLとACIDを維持したまま、NoSQLのようなスケーラビリティを実現 10
分散したら困ることないですか? コンセンサスアルゴリズムの話 NodeA NodeB NodeC DB DB DB 残高 100万円 残高 95万円 残高 80万円 送金中に障害発生、どのデータを正しいと判断すればよい? ここで「コンセンサスアルゴリズム」が登場します。 11
コンセンサスアルゴリズムの仕組み(イメージ) ① 更新要求 ② 提案 クライアントから 90万円への更新要求 あるNode(Leader)が残高更新の 提案を各Nodeに送信 Leader DB クライアント NodeA NodeB 90万円に更新する提案 NodeC DB DB DB 100万円 95万円 80万円 NodeB NodeC DB DB 95万円 80万円 12
コンセンサスアルゴリズムの仕組み(イメージ) ③ 合意 ④ 決定 多数のNodeが「OK」と返信 この例では過半数の2/3 Leader 多数の合意が得られたので、 更新が確定し、全Nodeに反映 Leader DB DB 残高確定、90万円 NodeCがNG NodeA NodeB DB DB NodeC DB 100万円 95万円 80万円 NodeA NodeB DB DB NodeC DB 90万円 90万円 90万円 13
コンセンサスアルゴリズムのポイント Leader Point: Node同士で通信、アルゴリズムのキモ DB 代表的なコンセンサスアルゴリズム NodeA NodeB NodeC DB DB DB ● Paxos ● Raft (OceanBaseはMulti-Paxosを採用) 90万円 90万円 90万円 ● 過半数が合意したもの = 正しいもの ● 一部のNodeが故障していてもサービスが継続できる ● Leaderが切り替わっても、OBProxyが適切なOBServerへルーティングする 14
OceanBaseを理解する4つの視点 ● 一般的なRDBMSと何が違うのか ● 分散データベース特有の難しさ ● OceanBaseが向いているケースと向いていないケース ● OceanBaseの技術をAI検索に展開したSeekDB 順番に見ていこう! 15
OceanBaseは何が違うのか OceanBase 一般的なRDBMS OBProxy Application RDB Primary RDB Replica OB Server OB Server OB Server Zone A Zone B Zone C ● 1台を強くするのではなく、クラスタ全体で動かす ● データを複数のOBServerに分割して配置し、クラスタ全体で処理する 16
補足:OceanBase Bacchus ストレージ分離型アーキテクチャ 引用:OceanBase Bacchus: a High-Performance and Scalable Cloud-Native Shared Storage Architecture for Multi-Cloud https://arxiv.org/abs/2602.23571 17
分散をアプリケーションに意識させない Point Tenant データが分割されていても アプリケーションからは1つに見える。 Table A Table B Table C DB OBProxyの役割 SQLを受け取って対象データを持つ適切な OBServer(DB)へルーティング (ここが通信レイテンシ削減のキモ) アプリケーションは 分散していることを意識しない。 18
オンラインスケーリングの仕組み 変更前 NodeA NodeB NodeC DB DB DB クラスタを稼働させ たままリソース追加 Node Dを追加 NodeA NodeB DB DB NodeC NodeD DB DB サービス停止せずにデータを再配置 19
分散DBであるがゆえの課題 Application Application 合意形成コストが発生! NodeA NodeA NodeB NodeC DB DB DB DB 高速・単純 合意(コンセンサス)をとる ● Node間通信が増える ● 分散トランザクションでは複数Nodeの調整が必要になる ● Node数を増やせば必ず速くなるわけではない 20
分散トランザクションのコスト 同一パーティション内 注文 在庫 データが同じNodeに存在 通信が少ない。 DB 複数パーティション間 データが異なるNodeに存在 注文 在庫 Nodeをまたぐ DB DB ネットワーク通信と トランザクション調整が必要 21
OceanBaseが向いているケース ● 停止時間を短くしたい基幹システム ● 大量の同時更新を扱うサービス ● RPOとRTOに厳しい要件があるシステム ● データ量やアクセス量の継続的な増加が見込まれるシステム ● SQLやトランザクションを維持したまま水平拡張したいシステム 大規模トラフィックだけでなく、停止できないことや 将来的な拡張性に価値があるシステムが候補となり得る。 例:とても厳しいトランザクションと可用性を要求される決済システム 22
OceanBaseが合わないかもしれないケース ● 小規模で単一Nodeでも十分なシステム ● 高可用性や水平拡張を必要としないシステム ● マネージドサービスを利用しても、分散トランザクションや性能設計を扱う知 識は必要(後述) ● Node間通信が多くなるデータモデル ● 特定のDB製品固有機能や完全な互換性に強く依存するシステム ● コストよりも構成の単純さを優先したいシステム まとめ:要件によってはOceanBaseがオーバースペックになることもある 23
By the way:ここまで話したけど 深夜メンテナンスは本当に不要になるんですか? 今まで OceanBase Cloudを利用 ● DB追加 ● データ設計 ● パッチ適用 ● SQL ● バックアップ ● 性能 ● 障害対応 ● コスト 「運用はなくなる」のではなく、「運用の中身が変わる」 24
OceanBase Cloudで運用はどう変わる? OceanBase Cloud 利用者/開発者 クラスタ構築 データモデル設計 Node追加・削除 SQLチューニング バージョンアップ インデックス設計 バックアップ パーティション設計 障害復旧 RPO/RTOの設計 基盤監視 アプリケーションの設計 インフラ運用は大幅に減るが、データベース設計は依然として重要 25
では、AIアプリケーションから小さく始めたい場合はどうでしょうか SeekDBはOceanBaseの技術をAIアプリ向けに届ける入口 大規模な業務システム AIアプリケーション 分散 高可用・水平スケール RAG エージェント・検索 OceanBase Database SeekDB 26
SeekDB、なぜRAGにRDBの機能が必要なのか RAGで扱うデータ ● 本文 「この質問に近い文書」 かつ 「このユーザーが閲覧可能」 かつ 「過去30日以内」 ● ベクトル ● 文書ID ● ユーザーID クエリ ● 公開範囲 ● 更新日時 ベクトル検索とSQLを1つのデータベースで ● カテゴリ 扱えることに意味がある! 27
OceanBaseとSeekDBのつながり ● OceanBase ○ 大規模・分散・高可用な業務DB ● SeekDB ○ AIアプリ・RAG・検索から始めやすいDB 共通する考え方 ● SQLで扱える ● トランザクションを扱える ● 構造化データを扱える SQLが扱えるため検索条件に対応したRAGアプリケーションを構築できる。 それがSeekDB!そして、大規模ならそこでOceanBaseという使い方 28
まとめ OceanBase SQLとACIDを維持したまま、分散・高可用・水平拡張を実現 ただし 分散DB特有の通信コストと運用設計は必要(OceanBase Cloudであっても) SeekDB AI検索やRAGから小さく始められる選択肢 29
OceanBaseの始め方(個人的なオススメ) ● Get started with a transactional instance|OceanBase Cloud | docs|Distributed Database ○ https://en.oceanbase.com/docs/common-oceanbase-cloud-10000000001945363 インスタンスの種類には3つ、始めるならトランザクションインスタンスがおすすめ ● トランザクションインスタンス ● アナリティクスインスタンス ● キーバリューインスタンス 30
SeekDBの始め方(個人的なオススメ) ● SeekDB ○ https://github.com/oceanbase/seekdb ● pyseekdb ○ https://github.com/oceanbase/pyseekdb ● skills ○ https://docs.seekdb.ai/seekdb/agent-skills ● Hybrid Search ○ https://docs.seekdb.ai/seekdb/experince-hybrid-search-with-sdk ● Vector Search ○ https://docs.seekdb.ai/seekdb/experience-vector-search-with-sdk pyseekdbをuv環境にインストールして実行するのがオススメです。Skillsもある。 GitHub Codespacesでも試せます。 31
おわり 32
Appendix ● System architecture ○ https://en.oceanbase.com/docs/common-oceanbase-cloud-100000000028490 06 ● System management ○ https://en.oceanbase.com/docs/common-oceanbase-cloud-100000000028490 11 ● OceanBase Deployer Docs - Install and Deploy Tool Documentation - OceanBase Docs ○ https://en.oceanbase.com/docs/obd-en ● Experience hybrid search with SQL | seekdb ○ https://docs.seekdb.ai/seekdb/experience-client-server-mode-seekdb-with-S QL 33