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

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

想定する読者

  • 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と異なるのは、事前にデータへのアクセス設計が必要となる点です。

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