SQL から NoSQL へ : Amazon DynamoDB でのデータモデリング

本記事は 2025/07/03に投稿された SQL to NoSQL: Modeling data in Amazon DynamoDB を翻訳した記事です。
翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。

この投稿では、既存のデータベース構造とアクセスパターンを分析したパート1の内容を基に、効果的な Amazon DynamoDB データモデルの設計に焦点を当てます。DynamoDB は、アプリケーションの特定の要件と使用パターンに合わせた異なるデータモデリングアプローチを提供しています。

適切に設計されたデータモデルは、DynamoDB における最適なパフォーマンスとコスト効率をサポートします。ソーシャルメディアプラットフォームの例を通じて、異なるモデリングアプローチがアプリケーションのパフォーマンスと運用コストの両方にどのような影響を与えるかを示しています。

この投稿では、エンティティの特定、テーブル設計の決定、リレーションシップのモデリングアプローチなど、DynamoDB のデータモデルを設計するための戦略について説明します。特定のシナリオを使用してさまざまなモデリング手法を比較し、ユースケースに応じた適切な判断を行えるようにします。

エンティティの特定

DynamoDB のアイテム、属性、および対応するデータ型を定義します。これらは一般的に既存のデータベーススキーマと一致しているはずですが、DynamoDB のモデリングパターンに合わせて調整してください。現在のスキーマ構造を正確に反映させるのではなく、アプリケーションのアクセスパターンに合わせて最適化することに重点を置いてください。以下の点を考慮してください：

• コアエンティティ – アプリケーションがデータにアクセスし管理する方法に基づいて、主要なビジネスエンティティをリストアップします。例えば、ソーシャルメディアアプリケーションの場合、投稿、ユーザー、コメントなど、アプリケーションが頻繁に操作する中心的なデータ要素を表すエンティティが含まれます。
• サポートエンティティ – アプリケーションの機能をサポートするために必要な追加エンティティを特定します：
  • メトリクスやカウントを追跡するためのエンティティ
  • アプリケーションの状態を管理するためのエンティティ
  • 特定のアクセス要件をサポートするためのエンティティ
• 属性 – 各エンティティについて、既存のテーブル構造ではなく、アプリケーションのニーズに基づいて必要な属性をリストアップします。アプリケーションにおける属性の特性、データ型、使用方法を理解することで、DynamoDB での表現方法を計画するのに役立ちます。例えば、日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック番号のいずれかにマッピングする必要があります。

テーブル設計の決定

DynamoDB のアイテムを特定した後、シングルテーブル設計とマルチテーブル設計のどちらを使用するかを評価しました。多くのアプリケーションでは、実装が簡単なマルチテーブル設計から始めることをお勧めします。しかし、私たちのソーシャルメディアアプリケーションでは、要件分析に基づいてマイクロサービスごとにシングルテーブル設計を選択しました：

• アプリケーションの特性 – データの関連性が非常に高く、関連アイテムを一緒に取得する必要が頻繁にあります。例えば、投稿を表示する際には、同じ操作で関連するコメントとユーザー詳細を取得する必要があります。アプリケーションは主にトランザクションデータを扱い、監査、履歴、分析データの量は多くありません。これらの特性は、自然とシングルテーブルアプローチと適合しています。
• パフォーマンスとコストの分析 – シングルテーブル設計では、すべてのデータが 1 つのテーブルに格納されるため、関連アイテムを含む複雑なクエリに対して一貫したパフォーマンスを提供します。キャパシティ管理については、自動スケーリングと簡素化された運用により、ほとんどのワークロードで推奨されるオンデマンドモードで開始しました。使用パターンを分析し、予測可能なワークロードを確立した後、コスト最適化のためにプロビジョンドモードを評価しました。シングルテーブル設計における関連データアクセスの統合されたキャパシティプランニングと効率的な RCU/WCU の割り当ては、プロビジョンドモードのメリットを最大限に活用するのに役立ちました。ストレージの観点からは、データの特性上、テーブル分割することに対して正当化するような顕著な非効率性はありませんでした。
• 運用上のメリット – サービスごとに単一のテーブルを管理することで、監視、キャパシティプランニング、データモデルの発展が簡素化され、運用上の作業負荷が削減されました。

テーブル設計の選択による影響は、アクセスパターンとデータ特性によって異なります。ユースケースにおけるパフォーマンスとコストへの影響を正確に評価するため、両方のアプローチを代表的な処理量でテストすることをお勧めします。詳細については、Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計をご参照ください。

パーティションキーとソートキーの定義

SQL クエリ分析から得られた知見を使用して、データの主要なアクセスパターンを特定します。これにより、DynamoDB テーブルの適切なパーティションキーを決定するのに役立ちます。SQL クエリの ORDER BY 句と TOP 句から得られた情報を使用して、複数レベルでのソートが必要な場合には対応する複合ソートキーの使用をするなど、ソートキーの選択を行います。

エンティティ関係のモデリング

DynamoDB の柔軟なスキーマは、従来のリレーショナルデータベースとは異なるアプローチを可能にしますが、DynamoDB におけるデータモデリングの戦略とその最適な戦略の評価方法について、いくつか検討する価値があります。

単一アイテム

DynamoDB の単一アイテムアプローチは、エンティティと関連データが 1 つのアイテム (最大 400 KB) に収まる場合に効率的です。このモデルでは、関連するデータをすべてまとめて保存することで、高速な読み取りが可能になります。ただし、このアプローチは書き込み操作に影響を与えます。変更を加えるたびにアイテム全体を更新する必要があり、書き込みコスト (WCU) が増加します。書き込みの頻度が高くなるほどコストが上がり、データの整合性を維持する複雑さも増します。このアプローチは、親データと子データが同時にアクセスされることが多く、読み取りコスト (RCU) の削減メリットが書き込みコストの増加を上回るような、読み取り量の多いアプリケーションに特に適しています。子データの読み取りと書き込みの比率を評価し、メリットがデメリットを上回ることを確認することが重要です。

単一アイテム内の子アイテムコレクションのフィルタリングは、フィルター式またはクライアントサイドのフィルタリングでのみ可能です。ただし、DynamoDB はフィルターを適用する前にアイテム全体を読み取るため、RCU の消費量は減りません。

これらのトレードオフを理解し、アクセスパターンを慎重に評価することで、高速な読み取りと、書き込みコストの増加やフィルタリングの複雑さのバランスを取りながら、このデータモデリングパターンがユースケースに適しているかどうかを判断できます。

垂直パーティショニング

DynamoDB の垂直パーティショニングは、特定の属性に対する絞り込みクエリに有用です。このパターンでは、同じパーティションキーと異なるソートキーを持つ隣接するアイテムに関連データを保存します。

主なメリットには以下のようなものがあります:

• クエリの柔軟性 – 子アイテムを単独で、または親アイテムと一緒に効率的に取得できます
• 書き込みのきめ細かい制御 – 親アイテムを書き換えることなく、個々の子アイテムを更新できます

ただし、このアプローチでは、エンティティ間のフィルタリングがより複雑になります。親と子の属性の両方でフィルタリングを行うには、一部の親の属性を非正規化して子アイテムにする必要があります。親の属性が頻繁に変更される場合、書き込みコストを増加させる可能性があります。例えば、アクティブユーザーのすべての動画投稿を検索したい場合を考えてみましょう。これには 2 種類のフィルタリングが必要です。1つはアクティブユーザー（親エンティティ）の検索で、もう1つはユーザーの投稿のうち動画であるもの（子エンティティ）の検索です。1 つの解決策は、ユーザーのステータスを各投稿レコードに直接追加して非正規化することです。これによりクエリは簡単になりますが、欠点もあります。ユーザーのステータスが変更されるたびに、そのユーザーのすべての投稿でステータスを更新する必要があります。これにより書き込み操作が増加し、結果として運用コストが上がります。このようなクエリの簡素化と書き込み効率のトレードオフは、DynamoDB の設計パターンでよく考慮される点です。

重要なのは、アクセスパターンを慎重に分析し、クエリの柔軟性、書き込み管理、エンティティ間のデータ非正規化のコストのバランスを取ることです。

ユーザーが複数の投稿を作成できるソーシャルメディアプラットフォームを想像してみてください。次の図は、ユーザーと投稿の関係を示しています。このシナリオでは、アクセスパターン、使用統計、アイテムサイズを慎重に分析することで、DynamoDB の最適なデータモデリングアプローチを決定する方法を探ります。この包括的な評価により、特にソーシャルメディアアプリケーションのニーズに合わせた、パフォーマンス、コスト効率、スケーラビリティのバランスを取る戦略を選択する際の指針になります。

アイテムサイズに関する注意事項

DynamoDB のデータモデルを設計する際は、アイテムのサイズを見積もってください。DynamoDB では 1 アイテムあたり 400 KB の制限があるため、データの平均サイズと最大サイズの両方を把握しておくと便利です。

ソーシャルメディアアプリケーションのユーザーと投稿モデルについて、以下の点を考えてみましょう：

• ユーザーのプロファイルデータの平均サイズを見積もります
• ユーザーあたりの投稿の平均数と、その一般的なサイズを計算します

これらの見積もりは、意思決定の指針となります。RCU と WCU はアイテムサイズに比例するため、最適なデータモデリング戦略を設計するには、平均アイテムサイズを評価することが重要です。

アクセスパターン

アプリケーションのアクセスパターンを理解することは、効率的な DynamoDB モデルを設計する上で重要です。以下の点を考えてみてください：

• 投稿に適用されたフィルターに基づいてユーザーを取得する必要がありますか？
• 一部のクエリでユーザープロファイルデータと投稿の両方を同時にフィルタリングする必要がありますか？
• ユーザーの最新 N 件の投稿への迅速なアクセスが必要ですか？
• コメントの多い N 件の投稿を取得する必要がありますか？

これらのアクセス要件は、最適なパフォーマンスを実現するためのパーティションキー、ソートキー、およびセカンダリインデックスに関する決定に影響を与えます。フィルター条件は、単一アイテムアプローチの実現可能性を判断する際にも役立ちます。例えば、投稿フィルターに基づいてユーザーを特定する必要がある場合、単一アイテムアプローチは効率的ではない可能性があり、別のデータモデリングアプローチを検討する必要があるかもしれません。

使用状況メトリクス

データの読み取りと書き込みのパターンを分析して、最適な戦略を決定します。読み取りと書き込みの比率を理解するために、以下の点を考えてみてください：

• 投稿とユーザープロファイルデータが一緒に参照される頻度はどのくらいですか？
• 投稿の更新頻度は、ユーザープロファイルの変更頻度と比較してどれくらいですか？
• ユーザープロファイルと投稿において、最も頻繁に変更される属性は何ですか？
• 投稿カウンター（いいねやシェアなど）の読み取り頻度はどのくらいですか？
• 投稿カウンターの更新頻度は、投稿コンテンツの更新頻度と比較してどうですか？

データモデリング戦略の選択

アイテムサイズ、アクセスパターン、使用状況のメトリクスに関する情報を収集したので、次のセクションでは、これらのデータポイントを使用して、DynamoDB のソーシャルメディアアプリケーションに最適なデータモデリング戦略を評価し、選択する方法を説明します。

シナリオ1 ：1 対 N の関係

次の表は、ユーザー情報 (各 20 KB) と投稿コンテンツ (各 5 KB) の 1:N の関係を、単一のアイテムとして保存した場合と垂直パーティションした場合を比較したものです。

* 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。

シナリオ2 ：1 対 1 の関係

次の表は、1 つのアイテムとして保存された投稿 (各 4 KB) と投稿カウンター (0.5 KB) の 1:1 の関係を、垂直パーティションと比較したものです。

* 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。

この分析では、DynamoDB における 1:N の関係 (ユーザーと投稿) と 1:1 の関係 (投稿とカウンター) の両方について、単一アイテムと垂直バーティションを比較しています。1:N のシナリオでは、垂直パーティションは API コール数が増加しますが、RCU/WCU のコストを大幅に削減します (読み取りの場合は 21,500 RCU から 9,000 RCU へ、書き込みの場合は 1,700 WCU から 200 WCU へ)。同様に、1:1 の関係では、垂直パーティションにより API コール数は 2 倍になりますが、特に頻繁な更新において大幅な WCU の削減 (6,000 WCU から 1,000 WCU へ) を実現します。ただし、これらの結果は、ここで議論されたユースケース特有のものであることを理解することが重要です。ここで収集したデータを異なるシナリオに適用する前に、慎重な検討することをお勧めします。

結果

評価した特定のユースケースについて、以下のことが判明しました。

• 1:1 の関係 (投稿と投稿カウンター):
  • 単一アイテム設計では、読み取りの API コールと RCU が少なくなりましたが、更新時の WCU 消費が増加しました
  • 垂直パーティション設計では、より多くの API コールが必要でしたが、特に頻繁な更新において WCU の使用がより効率的でした
• 1:N の関係 (ユーザーと投稿):
  • 単一アイテム設計では、API コールは少なくなりましたが、アイテムサイズが大きくなることで RCU の消費量が大幅に増加し、更新時の WCU コストも大幅に増加しました
  • 垂直パーティション設計では、API コールの数は 2 倍になりましたが、RCU と WCU 両方の消費量を大幅に削減でき、スケールした際の費用対効果が高まることがわかりました。

まとめ

重要なポイントは、具体的な結果だけでなく、これらの結論に至るまでの分析プロセスにあります。どのようなユースケースでも、パフォーマンスのニーズとコストに関する考慮事項のバランスを取った最適なデータモデル戦略を定義するには、同様の綿密な分析と思考プロセスが不可欠です。更新頻度、読み取りパターン、データスケーリング要件、エンティティ間の関係の特性など、さまざまな要因を慎重に評価する必要があります。パート 3では、アプリケーションのデータアクセスレイヤーをこれらのデータモデルで効果的に動作するように適応させ、DynamoDB の機能を活用できるようにする方法を探ります。

著者について