モバイルアプリ向けDynamoDB設計ハンズオンをやってみた

概要

モバイルアプリ向け DynamoDB 設計ハンズオンをやってみました。
このハンズオンでは、モバイルアプリ向けの DynamoDB の設計方針を学ぶことができます。
せっかくなので、学んだことをアウトプットします。

以下公式説明です。

このラボでは、DynamoDB により提供するモバイルアプリケーションを構築しながら、Amazon DynamoDB での高度なデータモデリングパターンを学びます。DynamoDB を使用する場合、データをモデリングする前にデータへのアクセス方法 (アクセスパターン) を検討することが重要になります。ここではそういったパターンを学ぶために、ソーシャルネットワークを内臓したサンプルのモバイルアプリケーション用に、データモデルを構築していきます。DynamoDB で素早く一貫性のあるパフォーマンスを実現するための、データモデルの設計法を習得できます。

データモデリングについて

DynamoDB などの NoSQLDB は RDB 等と異なり、速度とスケールの為に設計されています。
そのため、以下の点に注意してモデリングする必要があります。

1. アクセスパターンを検討する

   • まず、DynamoDBをどのような使い方をするのかを検討する。(どういうアプリなのか、どういうリクエストが多いのか等)
     • とっかかりとしては、まずエンティティを抽出し、多重度をつける。
     • 次に、アクセスパターンを検討する。エンティティがどういったデータにどういう操作を行うかを検討する。
       • SNSを例に挙げると、ユーザが他のユーザのプロフィールを参照する等。

2. DynamoDB へのリクエスト数を最適化する

   • 1で検討したアクセスパターンごとにリクエスト数を最小限に抑えるようにテーブルを設計する。
   • 理想は各アクセスパターンに必要なリクエストを1つのみにすること。
   • 最適化を行う為に、DynamoDBのコアコンセプトを理解する。
     • プライマリキー
     • セカンダリインデックス
     • DynamoDB トランザクション

3. リレーショナルモデルの考え方をしない

   • DynamoDB にリレーショナルモデルの考え方を持ち込むと DynamoDB の利点がほとんど失われる。一般的なアンチパターンは以下である。
     1. 正規化： DynamoDB はテーブルが多くなるにつれて速度が遅くなるため、正規化を行わないほうが良い。
     2. テーブルごとに 1 つのデータ型にまとめる： DynamoDB テーブルには単一のテーブルに様々なタイプのデータが含まれる。
     3. セカンダリインデックスを大量に作る：属性の柔軟性を使用してテーブル内の複数のデータ型にかけて単一のセカンダリインデックスを再利用する。

プライマリキーの設計

• プライマリキーは各エンティティを明確に識別できる必要がある。そのため,個々のアイテムのコアアクションを実行できること確認する。
• プライマリキーはプレフィックスを使用することにより、コンフリクトを防ぐことができる。
  • 同一のテーブルに顧客と従業員がある場合、以下のようにプレフィックスをつけ、エンティティを区別することにより、IDの衝突がなくなる。
    • 顧客：CUSTOMER#<CUSTOMERID>
    • 従業員：EMPLOYEE#<EMPLOYEEID>
• 多対多のマッピングが存在する場合、2つのクエリパターンが必要となる。この場合、パーティションキーとソートキーという二つの値を使う複合プライマリキーを使用する。
  • SNSを例に挙げると、フォロー、フォロワーを管理しているエンティティは、フォローしているユーザを取得するアクセスパターンとフォローされているユーザを取得するアクセスパターンが存在する。

インデックスの置きかえ

置換インデックスは一般的なセカンダリインデックスのデザインパターンである。置換インデックスを使用して、テーブルのプライマリキーの逆であるセカンダリインデックスを作成する。

置換インデックスは 2 つのシナリオで役に立つ。

• 多対多関係の「反対側」をクエリする場合。
• それ自体が一対多関係の対象であるエンティティの多対一関係をクエリする場合

非正規化

DynamoDB ではデータを非正規化することがよくある。非正規化は、結合を回避し、クエリのパフォーマンスを向上させるのに役立つ。非正規化を行うには、クエリ中に両方のアイテムをフェッチしないようにするために、アイテムの属性をそのアイテムを参照する別のアイテムにコピーする。

ただ、非正規化によってデータを持ちすぎるとデータモデルが複雑になる場合があるので注意が必要。

まとめ

それぞれについてより詳しく知りたい場合には実際にハンズオンを行ってみてください。
手を動かしながら理解することができます。

また、以下にベストプラクティスが載っています。一度参照されると設計がより楽になると思います。