はじめに
本記事はDynamoDBでリレーションの実装について、各方法の概要とユースケースについて簡単にまとめたものです。カタカナ英語が多くて目がチカチカしますが、是非お付き合いください。
方法１: 子エンティティ in Attribute
親エンティティのattributeに子エンティティを配列またはハッシュの形式で格納します(↑赤枠)。「1つのフィールドには1つの値しか含まれない」という第一正規系の原則にあえて違反しています。
この方法は、子エンティティの特定の要素に対するアクセスパターンが必要無い場合に適しています。図の例で言えば、都道府県が東京都の住所のみを取り出すといったことは出来ません。
また、注意点としてアイテムのサイズ制限である400KBを超えないようにしなければなりません。ユーザーの購入履歴など無限に増える可能性があるものには、この方法は使わない方が良さそうです。
方法２: PK=親エンティティ / SK=子エンティティ
PKに親エンティティ、SKに子エンティティを設定します。各アイテムには親エンティティと子エンティティ両方の情報を持たせます(↑赤枠)。
この方法は、親エンティティの情報が不変である場合に適しています。というのも、この方法では親エンティティの情報が各アイテムに重複することになるため、後からの修正が難しくなるからです。あるいは、親エンティティの変更頻度が少なく、紐づいている子エンティティの情報が(手作業で修正できる程度には)少ないものであれば良いかもしれません。
方法３: PK=親エンティティ / SK=親&子エンティティ
PKに親エンティティ、SKに親と子エンティティとをそれぞれ設定します。２の方法と違い、親子の情報は別々のアイテムに格納しています(↑黄枠&緑枠)。ちなみに、同じPKの値を共有するグループ(↑赤枠)をアイテムコレクションと言います。
この方法は柔軟なアクセスパターンが必要な場合に適しています。PKとSKの条件の組み合わせ次第で以下４つのアクセスパターンに対応出来ます。
- 親のみ
- 親 + 全部の子
- 全部の子
- 特定の子
AWS公式でも紹介されており、最もスタンダードな手段と言えるかもしれません。
方法４: Secondary Index
方法３と同じことをSecondary Indexを使って実装します。子エンティティはベーステーブル上に通常のアイテムとして格納し(↑黄枠)、親エンティティと子エンティティのそれぞれにGSIを追加します。GSIテーブルは方法３と同じ形式になっています。(↑緑枠)
この方法は、Primary keyが他の用途で使えない場合に使用します。
参考