データベースの技術選定を突き詰める ～複数事例から考える最適なデータベースの選び方～ 株式会社スリーシェイク 中楯 直希 

\du 2 株式会社スリーシェイク Sreake事業部 Alias - nnaka2992 - nkDATE 業務内容 - DBRE兼SRE見習い - 自称データ雑用係 興味あること - DBをKubernetesにのせること - SREっぽいこと - データベース関連ならなんでも Google Cloud Partner Top Engineer 2025 Data Managementになりました 中楯 直希 @nnaka2992 

はじめに: 目的 3 サービスのメインのデータベースがあるときに パーパスビルドでデータベースを採用すべきか？ メインのデータベースにまとめるべきか？ 事例ベースで紹介します 

はじめに: 注意点 4 ● 非公開事例を含むため内容をぼかしたり、詳細を改変 しているものがあります ● 紹介する事例はRDBを利用したものが中心となってい ます 

アジェンダ 5 ● Oracle DatabaseとRedisを組み合わせた超低レイテンシ ● PostgreSQLとBigQueryを組み合わせたアクセス数集計 ● PostgreSQLとpg_bigmを利用した全文検索 ● まとめ 

Oracle DatabaseとRedisを組み合わせた超低レイテンシ 6 ● オンラインゲームに利用するレイテンシが重要なランキング 機能 ● ホスティング環境はオンプレミス ● レイテンシに加えリアルタイム性も重要 Clients Server Oracle DB 

Oracle DatabaseとRedisを組み合わせた超低レイテンシ 7 ● ポイント ○ オンプレミスのためスケールアウトは難しい => Oracle DBを強化することは不可 ○ ユーザーの注目を集めるためのサービスなためリアルタイム性は必須 => バッチ処理に逃げることは不可 ○ レイテンシも1桁ms未満に抑える必要がある => 高速に更新し、高速に提供する必要がある ○ 組織でRedisの利用実績があった => Redisを採用するハードルが無い 

Oracle DatabaseとRedisを組み合わせた超低レイテンシ 8 ● 最終的なアーキテクチャ ○ ランキングデータはRedisに保存・アクセスする ○ ランキング対象のイベントデータはOracle Databaseに永続化 Clients Server Oracle DB Redis その他のデータアクセス ランキング対象データの永続化 ランキングデータの集計と取得 

PostgreSQLとBigQueryを組み合わせたアクセス数集計 9 ● PostgreSQLをバックエンドにしたSaaSのページごとアクセ ス数の集計 ● Cloud Run x Google Cloud for PostgreSQLを利用 ● コストは小さく・構成はシンプルにしたい Cloud SQL Cloud Run (Frontend) Cloud Run (Backend) BigQuery Google Anaytics 4 Clients 

PostgreSQLとBigQueryを組み合わせたアクセス数集計 10 ● ポイント ○ アクセス数のリアルタイム性は必須ではない(1時間ごとの更新で十分) => バッチ集計を採用可能 ○ コストと構成をシンプルに保つ観点からあたらしいコンポーネントを構成 に追加することは現実的ではない => メッセージキューを採用したり新しいDBの採用は不可 ○ GA4のデータがBigQueryにシンクされている => 都合のイイデータが集計を得意とするDBにある 

Oracle DatabaseとRedisを組み合わせた超低レイテンシ 11 ● 最終的なアーキテクチャ ○ GA4のデータをBigQueryで集計 ○ Cloud StorageからPostgreSQLにデータをアップロード Cloud SQL Cloud Run (Frontend) Cloud Run (Backend) BigQuery Google Anaytics 4 Clients Cloud Storage アクセスデータをコピー アクセスデータにアクセス Workflows 

PostgreSQLとpg_bigmを利用した全文検索 12 ● PostgreSQLをバックエンドにしたSaaSの文書検索機能の パフォーマンス改善 ● Cloud Run x Google Cloud for PostgreSQLを利用 ● もともと文書検索機能があり検索速度が課題 Cloud SQL Cloud Run (Frontend) Cloud Run (Backend) Clients 

PostgreSQLとpg_bigmを利用した全文検索 13 ● ポイント ○ 文書はPostgreSQLに保存されている => 二重管理は避けたい ○ 文書検索機能はもともとある => 小さくはないコードベースが存在する ○ 検索方法は完全一致検索のみ => 高度な検索機能は不要 ○ 組織に検索用途のDBへのナレッジが無い => 運用コストを考えると採用に消極的 

PostgreSQLとpg_bigmを利用した全文検索 14 ● 最終的なアーキテクチャ ○ 新規のコンポーネントは追加しない ○ PostgreSQLでpg_bigmを利用し、完全一致検索用インデックスを作成 する Cloud SQL Cloud Run (Frontend) Cloud Run (Backend) Clients 

まとめ 15 ● ソリューションありきではない選定が重要 ● 組織のケイパビリティによってベストは常に変わる ● 要件に応じてデータベースを選定することが大事 ○ 必須じゃない要件を削ることで新しいベストな選択肢ができることも