Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データベースの技術選定を突き詰める ~複数事例から考える最適なデータベースの選び方~

データベースの技術選定を突き詰める ~複数事例から考える最適なデータベースの選び方~

2025年5月14日に開催された【技術選定を突き詰める】Online Conferenc​​e 2025の公募LT登壇資料です。
https://findy.connpass.com/event/349580/

サービスのメインのデータベースがあるときに、パーパスビルドでデータベースを採用すべきか? メインのデータベースにまとめるべきか? という疑問に対して事例ベースで最適なデータベースの選び方を紹介します。

Avatar for nnaka2992

nnaka2992

May 13, 2025
Tweet

More Decks by nnaka2992

Other Decks in Programming

Transcript

  1. \du 2 株式会社スリーシェイク Sreake事業部 Alias - nnaka2992 - nkDATE 業務内容

    - DBRE兼SRE見習い - 自称データ雑用係 興味あること - DBをKubernetesにのせること - SREっぽいこと - データベース関連ならなんでも Google Cloud Partner Top Engineer 2025 Data Managementになりました 中楯 直希 @nnaka2992
  2. Oracle DatabaseとRedisを組み合わせた超低レイテンシ 7 • ポイント ◦ オンプレミスのためスケールアウトは難しい => Oracle DBを強化することは不可

    ◦ ユーザーの注目を集めるためのサービスなためリアルタイム性は必須 => バッチ処理に逃げることは不可 ◦ レイテンシも1桁ms未満に抑える必要がある => 高速に更新し、高速に提供する必要がある ◦ 組織でRedisの利用実績があった => Redisを採用するハードルが無い
  3. 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
  4. PostgreSQLとBigQueryを組み合わせたアクセス数集計 10 • ポイント ◦ アクセス数のリアルタイム性は必須ではない(1時間ごとの更新で十分) => バッチ集計を採用可能 ◦ コストと構成をシンプルに保つ観点からあたらしいコンポーネントを構成

    に追加することは現実的ではない => メッセージキューを採用したり新しいDBの採用は不可 ◦ GA4のデータがBigQueryにシンクされている => 都合のイイデータが集計を得意とするDBにある
  5. 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
  6. PostgreSQLとpg_bigmを利用した全文検索 12 • PostgreSQLをバックエンドにしたSaaSの文書検索機能の パフォーマンス改善 • Cloud Run x Google

    Cloud for PostgreSQLを利用 • もともと文書検索機能があり検索速度が課題 Cloud SQL Cloud Run (Frontend) Cloud Run (Backend) Clients
  7. PostgreSQLとpg_bigmを利用した全文検索 13 • ポイント ◦ 文書はPostgreSQLに保存されている => 二重管理は避けたい ◦ 文書検索機能はもともとある

    => 小さくはないコードベースが存在する ◦ 検索方法は完全一致検索のみ => 高度な検索機能は不要 ◦ 組織に検索用途のDBへのナレッジが無い => 運用コストを考えると採用に消極的