Zenn
🤔

(todoアプリ)DynamoDBのテーブル設計考えよう

2023/06/15に公開
AWS
DynamoDB
DB
tech

はじめに


DynamoDBのテーブル設計をちゃんとしてみた。

大前提

  • RDBの常識はDynamoDBの非常識

命名規約

全般

  • 『全部小文字、なるべく短く』で統一する。
    　DynamoDBは大文字/小文字を区別するみたいだが、DBによってはしないものなどがあるため小文字で統一を図る。コーディングミスも防ぐことができる。

DynamoDB の命名規則は次のとおりです。
すべての名前は UTF-8 を使用してエンコードする必要があり、大文字と小文字が区別されます。
テーブル名とインデックス名の長さは 3～255 文字で、次の文字のみを含めることができます。
a-z
A-Z
0-9
_ (下線)
- (ダッシュ)
.（ドット）

  • 予約語を使わない。属性名として使用しないこと。大文字と小文字が区別されない！！
    　DynamoDB の予約語
    ※特に、DynamoDB では、# (ハッシュ) および : (コロン) に特別な意味があるので使わない。

キー設計

  • キー種別
  • パーティションキー（必須）
    • データをどのパーティションに配置するかを決定するキー。
    • 形式＝「ハッシュ型(HASH)」
    • 使用可能な検索＝「完全一致」のみ
  • ソートキー（任意）
    • パーティションキーが同一の複数データについて、ソートや範囲検索を行うためのキー
    • 形式＝「レンジ型(RANGE)」
    • 使用可能な検索＝「完全一致」「前方一致」「範囲検索」
  • プライマリキー
    • 「パーティションキー」 or 「パーティションキーとソートキーのセット」
    • テーブル内でユニーク必須。
  • 使う側（アプリやブラウザ）が、どんなキーを指定して検索（クエリ）をするのか？要件によってよく考える。ToDoアプリの機能を例に考えるとこんな感じ
    • パーティションキー＝ユーザーID
    • ソートキー＝タスクID
      といったところかな。
    • 日時でソート、絞り込みたい場合
      　各タスクの登録、閲覧、更新、削除では必要ない。タスク一覧の閲覧、全文検索で必要かもしれない。その場合は、更新日時や、期限日時といった属性をセカンダリインデックスとすればよい。また、全文検索用に最初から「タイトル」、「内容」といったキー値を連結したキーを登録しておくと良いと思う。
機能 検索に使用するキー
ユーザーのタスク一覧を閲覧 ユーザーID
ユーザーのタスクを登録 ユーザーID、タスクID
ユーザーのタスクを閲覧 ユーザーID、タスクID
ユーザーのタスクを更新 ユーザーID、タスクID
ユーザーのタスクを削除 ユーザーID、タスクID
ユーザーのタスク一覧を全文検索 ユーザーID、検索ワード(タイトル+内容連結文字列)

その他

データ型記述子

低レベルの DynamoDB API プロトコルは、各属性を解釈する方法を DynamoDB に伝えるトークンとして、データ型記述子を使用するんだって。

  • DynamoDB データ型記述子の一覧↓
    S — 文字列
    N — 数値
    B — バイナリ
    BOOL — ブール
    NULL — Null
    M — マップ
    L — リスト
    SS — 文字列セット
    NS — 数値セット
    BS — バイナリセット

参考

Discussion