はじめに

あなたのプロジェクトにAmazon DynamoDBがマッチしているかのチェックポイントを作ってみました。
ある程度は経験に基づいていますが、ポイント自体は完全に独断と偏見なので、温かい目で見てもらえればと思います。
合計ポイントがプラスなら、プロジェクトにDynamoDBを活用してみてください。
面白そうだからチャレンジしちゃえ、という気持ちを推奨しつつも、マジレスをしていければと思います。（あくまで過去の自分に向けた備忘録が目的です）

それでは、チェックをどうぞ。

チェックポイント

  • DynamoDBやNoSQLにエンジニアが興味がある
    • +100
    • 興味と学習意欲はエンジニアの魂です。
  • データベース運用を行いたくない
    • +100
    • アップデート不要で、オンデマンドスケール可能。
    • ただし急なスパイク対応の場合はオンデマンドでも落ちる罠
    • 大規模プロジェクトならメトリクス監視はどっちみち必須。
  • 一覧系のアプリで、多様な検索条件で多くのレコードをヒットさせたい
    • -1000
    • 例えば、年収、住所、年齢など、複数の条件で過去や現在の大量の住居などの購買情報を臨機応変に検索するシステムには明確に不向きです。
    • つまり「複数の検索条件で大規模なレコードをマッチングするシステム」は構造的に不向き。
      • 数百万レコードから複数条件でクエリする場合、RDBならWHERE句で一発ですが、DynamoDBではテーブル設計から考慮する必要があります。
  • データ量がTB〜PBスケールになる
    • +100
    • ストレージの分散が容易で、大規模データ向けなので大きなメリット
  • 数万単位のユーザーが存在して、頻繁なアップデートを行う
    • +100
    • クエリがシンプルかつ高速なので、多くのレコードが存在するDBに対しては向いています。ただし、クエリーがシンプルが故にできることや柔軟性も明確に少ない。
  • ユーザーIDなど明確なPKによる高速アクセスがメイン（柔軟な検索は不要）
    • +100
    • 固定された検索パターンにはレスポンスの早さもあいまって、非常に強い。
  • リレーションを貼りたい
    • -100
    • テーブル間のリレーションは基本的に貼れません。工夫すれば可能ですが、言ってしまえばRDBでは不要な労力との見方もできる。
  • 曖昧検索が必要
    • -100
    • DynamoDBやフロントで工夫すれば可能ですが、OpenSearchなどを組み合わせる必要があり、向いているとはいえない
  • データベースの自動スケーリングを求める
    • +50
    • スケーリングは楽。RDBの書き込みはスケールアウトしづらい（基本はほぼできないものが多い）のでここは大きな強みです。
  • バックエンドデータベースの構造がシンプルで頻繁に変わる（POCやIoT用途など）
    • +50
    • テーブル構造の定義が不要かつ、変更、追加が容易です。簡単に始められます。
  • 爆速のレイテンシーを求める
    • +50
    • 構造が単純なため、DynamoDBは1桁msで高速に返却されます。
  • テーブルスキーマや型定義を慎重に管理したい
    • -50
    • 厳密な型定義は基本的にできません。これは柔軟さの裏返しでもあるので一長一短です。
  • DynamoDB経験者がプロジェクトに少ない
    • -50
    • RDBと考え方が全く異なるため、学習コストが高く、それを考慮したフォロー体制がないと崩壊リスクがあります。
      • そこまで理解して調整できるPMは希少とも言えます。
  • キャッシュDBとして使いたい
    • +20
    • 単純な用途には非常に強いです。
  • データ削除時などのイベントを活用したい
    • +10
    • TTL機能でイベントトリガーが容易に行えて、他のLambdaなどのサービス発火連携が容易です。
  • 基本的にはサーバーレスアーキテクチャを活用予定
    • +10
    • 自動デプロイなどとの相性が良好です。
      • RDBはテーブル定義・マイグレーションなどがやや手間です。
  • RDBの経験者がプロジェクトに多い
    • – 20
    • 慣れたものを使うのも十分メリットがあります。
  • 将来的にデータ分析も行いたい
    • – 20
    • 普通のプロジェクトで使われるケースとは少し異なるような柔軟なクエリはできず、BIツール連携もできなかったり手間がかかるケースが多いです。
    • エクスポートで対応は可能ですが、その手間をなくしたいならRDBの方が良いです。

番外編

  • DynamoDBとOpenSearchを組み合わせれば大体解決するのでは？
    • これももちろん一概には言えず良い面悪い面があります。
      • 良い面
        • 検索が柔軟
        • 曖昧検索が可能
        • RDBより柔軟なクエリが可能
      • 悪い面
        • OpenSearch自体の運用（インスタンス管理やアップデート）が必要
        • 結局運用コストが上がり、「それなら最初からRDBで良いのでは」となる場合も多い
        • キャッシュ問題が発生し、運用工数が増えるケースが考えられる（古いレコードが残ってる、OpenSearchへの反映待ち etc…）
        • OpenSearchのクエリ構造・パフォーマンスチューニングの学習コストが上がる

おわりに

いかがでしたでしょうか。
ざっとですが、DynamoDBがあなたのプロジェクトに向いているかどうかの判断材料になれば幸いです。

「頑張ればDynamoDB or RDBでもできるのでは」と思う部分もあったかもですが、
やはり知らなくても「自然にできる」方が楽なので、学習コストも重視してポイントをつけています。

あまり真に受ける人はいないと思いますが、あくまで参考程度にご覧ください。
ポイントがマイナスでも「とにかくやってみたい！」という精神は尊いと思います。

少しネガティブな要素も挙げましたが、DynamoDB自体は非常に良いサービスです。
向き不向きはどんなものにもありますが、NoSQLの異なる構造の面白さも含め、ぜひ一度触ってみてください。
ただし、不向きなプロダクトに全面採用すると痛い目を見る可能性もあるので、
その場合はBIや分析用など、部分的な採用から始めるのが良いでしょう。

良いDBライフを！