DynamoDBで、RDBMSのリレーション設計に対応!GSIで効率良いクエリー設計を解説します😎

DynamoDBで、RDBMSのリレーション設計に対応!GSIで効率良いクエリー設計を解説します😎

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

想定する読者

  • DynamoDB をはじめて設計するヒト
  • DynamoDB の設計経験がすでにあるヒト

はじめに

DynamoDB でデータアクセス設計を行う際、RDBMS でいうところのデータのリレーションはどのように表現するのか?

というのが気になるところだと思います。

RDBMS でいうところの「1 : N」「1 : N」「N : M」の設計などを紹介&解説します。

1:1の設計パターン

特定のキー情報でデータを取得するパターンです。

  • KVS のようなデータアクセス
  • GetItem, BatchGetItem でパーティションキーでデータアクセス
  • GSI でパーティションキーをスイッチして属性情報に対するキーアクセスを実現

User Table

UserId (PK)MailAddressJoinDate
栗花落tsuyuri@onigari.com2020/1/20
煉獄rengoku@onigari.com2018/4/10

User Email GSI

User テーブルの Email をパーティションキーにしたGSIを作成します。

MailAddress (PK)UserIdJoinDate
tsuyuri@onigari.com栗花落2020/01/20
rengoku@onigari.com煉獄2018/04/10

1:N/親子関係の設計パターン

1つのデータに複数のデータが属しているパターンです。

  • パーティションキーとソートキーでデータアクセス
  • Query を用いてデータアクセス
  • 野球チームのメンバー管理システムで、1ユーザーがN個の野球チームに属するケースを例にします

User Join Team Table

UserId(PK)Team(SK)JoinDate
宇髄読売ジャイアンツ2019/10/20
宇髄中日ドラゴンズ2019/11/20
時透ソフトバンクホークス2020/02/10

宇髄さんは読売ジャイアンツと中日ドラゴンズに属することができました。もちろん、GSI でパーティションキーを Teamにすれば、読売ジャイアンツに属している人は誰か?を検索することが可能です。

N:Mの設計パターン

多:多のリレーションのパターンです。

  • GSI を使用してパーティションキーとソートキーをスイッチ
  • Query API を使用してアクセス
  • 従業員管理システムで、1ユーザーが複数の部署に属し、1部署には複数のユーザーが属しているケースを例とします

Department Table

DepartmentId(PK)CreatedAt
department-12020/01/20
department-22020/01/20

Staff Table

StaffId(PK)CreatedAt
staff-12020/01/20
staff-22020/01/20

Staff Department Table

StaffId(PK)DepartmentId(SK)
staff-1department-1
staff-1department-2
staff-2department-1

Department Staff GSI

DepartmentId(SK)StaffId(SK)
department-1staff-1
department-2staff-1
department-1staff-2

まとめ

テーブル数は可能な限り少ないことが望ましいので、GSI を駆使して要件を達成するようにしましょう。

わたしたちはお客様へのヒアリング結果に基づき、現在のアプリケーション要件で使用しなくても、将来を見通して GSI を作成しておくケースが多いです。(特にフェーズごとで開発内容が指定されているようなケースでは先々必要になる要件がなんとなく推測つきます)

DynamoDB が RDBMS と異なるのは、事前にデータへのアクセス設計が必要となる点です。

しっかりビジネス要件をヒアリングした上で、どのようなアクセスがされるかを想定し設計しましょう。

サーバーレス開発については、お気軽にお問い合わせください。