Web アプリ開発のための Amazon DynamoDB 設計を考える

DB 設計についてお話しする前に、アプリの内容をご紹介します。

アーキテクチャは図のようになっています。

AWS Amplify によりサーバーレス構成でウェブアプリを構築しています。

URL にアクセスするとログイン画面が表示されます。このログイン機能は Amazon Cognito の JavaScript ライブリを使用しています。

新たな設問・回答文の登録や登録データ一覧の取得などの操作は、Amazon API Gateway と AWS Lambda、DynamoDB で行います。アプリケーションからの API を API Gateway で受け、Lambda で処理、必要な情報を DynamoDB に保存するという流れです。

Amazon DynamoDB はマネージドサービス型の NoSQL データベースです。データを探索するために必要なプライマリキーは「パーティションキー (PK)」または「パーティションキーとソートキー (SK) の組み合わせ」です。PK, SK について知りたい方はこちら をご覧ください。

公式ガイド では NoSQL 設計の重要概念として次の 2 点が挙げられています。

1. アプリケーションのユースケースを理解してからスキーマの設計を開始する。
2. DynamoDB ではできるだけ少ないテーブルを維持する。

開発前は「DynamoDB は NoSQL でスキーマレスだから事前設計は不要でしょ」と思っていたのですが、重要概念 1 にある通り、ユースケースを洗い出してからスキーマ設計をする必要があります。重要概念 2 に基づき、今回使用したテーブルは 1 つです。

まずはユースケースの洗い出しです。「ユースケースって具体的に何を考えればいいの？」と思いましたが、

1. アプリの操作手順を具体的に想像する。
2. それぞれの操作段階で「DB からどのようなデータを得たいのか」を考える。
3. 「得たいデータを取得するための条件として指定するデータは何か」を考える。

という流れで、洗い出しを行いました。

今回想定したユースケースは以下の 7 個です。1〜2 は設問画面、3〜7 は回答画面で実装しています。

想定したユースケース

次にスキーマ設計です。今回はセカンダリインデックス等は使わないため、オリジナルテーブルの PK と SK について考えます。

試行錯誤の結果、PK, SK は以下の 3 種類になりました。1 と 2 の下段はデータの例です。

ユーザー ID は、ログイン後に Cognito から返ってくる ID トークンの sub という項目を利用しています。ID トークンや sub についてはこちら をご覧ください。

<PK, SK>

この設計にあたり工夫した点を 3 つ紹介します。

No.1, 2 のデータ例では、{設問ID}, {回答ID} がタイムスタンプになっており、それぞれが登録された日時を示しています。このようにした理由として以下の 2 点が挙げられます。

• タイムスタンプはミリ秒単位で取得する。同一ユーザーがミリ秒単位の同じタイミングで複数の登録をすることはないを判断した。
• タイムスタンプを SK に設定することで、設問や回答文の登録日時でソートできる (DynamoDB では、同一 PK 内の順序は SK で決まっている。)

DB から取得したタイムスタンプをアプリの登録日時表示に合う形に整形する処理はアプリケーション側で実装しています。

No.3 の SK は “default” という固定文字です。このアイテム (行) はデフォルト回答文の ID を保持しています。

デフォルト回答文情報の他の持ち方として、No.2 の「その他の属性」に「デフォルト回答文か否か」という属性を追加し、「デフォルト回答文なら true。そうでない場合は false」とする方法もあります。

しかし、ユースケース 7「指定した設問のデフォルト回答文を取得」の際に、「デフォルト回答文か否か」の属性で「多くの false の中から 0 または 1 つの true を探す」というフィルター処理が必要となり、クエリ効率が良くないです。そのため、デフォルト回答文の情報は 1 つのアイテムに設定しました。

DynamoDB の設計で戸惑ったのは、「3 つ以上の条件を指定するクエリはどのように行うのか」ということでした。

今回は 2 つのデータを組み合わせた新たなデータを作ることで、3 条件以上のクエリを実装しました。

3 条件以上のクエリを行うユースケースとそのクエリ対象のアイテムを以下に示します。

<3 条件以上のユースケース>

<クエリ対象のアイテム>

クエリ対象のアイテムの PK (user#{ユーザーID}_theme#{設問ID}) は、ユーザー ID と設問 ID の 2 つのデータの組み合わせになっています。クエリでは、PK でユーザー ID と設問 ID、SK で回答 ID による絞り込みが行われるため、3 条件を指定するクエリができます。

データの組み合わせ方について、以下のように PK をユーザー ID、SK を設問 ID と回答 ID とする方法も考えられます。しかし、この設計では、ユースケース 1「設問画面読み込み時に、ユーザーが登録した全ての『企業名・プロジェクト名・設問文・設問ID・登録日時』を取得」で PK に user#{ユーザーID} を指定してクエリをする際、theme#{設問ID}_comp#{回答ID} 等の不要なデータも含まれてしまいます。各ユースケースにおいて、クエリ結果に「期待するデータが不足なく含まれる」ことはもちろんですが、「期待するデータ以外のものはできる限り含まない」という点も考慮し、上記の組み合わせを採用しました。

<PK をユーザーID、SK を設問ID と回答ID とした場合>

本記事では、エントリーシート管理ウェブアプリとその DynamoDB 設計についてご紹介しました。

DynamoDB を使う場合は、効率の良いクエリができるよう、ユースケースに基づいてパーティションキーとソートキーを慎重に設計する必要があります。NoSQL はスキーマレスですが、だからと言って事前設計不要というわけではないという点が大きな学びでした。

この記事が「DynamoDB で DB 設計をしてみよう！」と思っていただくきっかけになれば幸いです。