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

想定する読者

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

はじめに

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

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

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

1:1の設計パターン

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

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

User Table

UserId (PK)	MailAddress	JoinDate
栗花落	tsuyuri@onigari.com	2020/1/20
煉獄	rengoku@onigari.com	2018/4/10

User Email GSI

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

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

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

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

• パーティションキーとソートキーでデータアクセス
• Query を用いてデータアクセス
• 野球チームのメンバー管理システムで、１ユーザーが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 を使用してアクセス
• 従業員管理システムで、１ユーザーが複数の部署に属し、１部署には複数のユーザーが属しているケースを例とします

Department Table

DepartmentId(PK)	CreatedAt
department-1	2020/01/20
department-2	2020/01/20

Staff Table

StaffId(PK)	CreatedAt
staff-1	2020/01/20
staff-2	2020/01/20

Staff Department Table

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

Department Staff GSI

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

まとめ

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

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

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

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

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