AWS DynamoDB: シングルテーブル設計 vs マルチテーブル設計

はじめに

サーバーレス大好きなエンジニアです！
AWS SUMMIT 2024で学んだことを共有します。
みなさんも以下のようなことを思ったことがあるのではないでしょうか？

DynamoDBはSingle Table Designでなければいけないのか

今回はその歴史やMulti Table Designとの違いについて深掘りしていきたいと思います。

DynamoDBとは？

DynamoDBは、Amazon Web Services（AWS）が提供するフルマネージド型のNoSQLデータベースサービスです。高いスケーラビリティとパフォーマンスを誇り、特に大規模なアプリケーションやリアルタイムデータ処理に適しています。
以下のような特徴があります。

• フルマネージドサービス
• 高スケーラビリティ
• 高パフォーマンス
• マルチリージョン対応
• 柔軟なデータモデル

Single Table Designでなければいけないのか

結論から言います。

必ずしも1つのテーブルにまとめる必要がありません。

• ケースに応じて有効なパターンとそうではないパターンがある
• テーブルを分割した方がメリットがある場合は積極的にテーブル分割をするべき

なぜSingle Table Designが推奨されてきたのかを解説します。

Single Table Design

長所

• 非正規化によりトランザクションを使わなくとも一貫性が保ちやすい
• 1つのテーブルから複数のビューを作成できる

短所

• データ冗長性が高くなる可能性がある
• クエリの複雑さが高くなる可能性がある

Multi Table Design

長所

• データの正規化が可能
• クエリが単純化される可能性

短所

• テーブル間のデータ取得について設計が複雑になる
• データ整合性を維持する必要がある

一長一短があるので、どちらが優れているというわけではありません。

なぜSingle Table Designが推奨されていたのか

当初は制約や機能が不足していたためです。

1アプリ1テーブル

「1アプリ1テーブル」と推奨されていましたが、ここで言う「1アプリ」はマイクロサービスのことを指しており、多くの機能を一つのテーブルにまとめることを推奨していたわけではありません。

トランザクションの有無

現在はトランザクションの一貫性を保つ処理が可能です。以前は、複数のテーブルを更新する際に制限があり、更新が困難でしたが、現在は制限が緩和され、大量のデータを更新できるようになりました。

On-demand modeがない時期のCapacity管理

小さいテーブルが複数あると、それぞれのテーブルにキャパシティを設定する必要があり、料金が増えることにつながっていました。大きなテーブルを作成することで、無駄なキャパシティが発生せず効率的でした。

Table数に上限があった。

テーブル数の引き上げに限界がありましたが、2022年に1アカウントあたりの上限が引き上げられ、多くの場面でこの問題が解決されました。

メトリクスを過剰に増やさないため

テーブル単位でメトリクスが生成され、それらの監視が大変でした。

開発者マニュアル

初期段階でシングルテーブルとマルチテーブルの2つのパターンを並行して設計検討することが紹介されています。つまり、まずシングルテーブルで検討し、うまくいかなかった場合にマルチテーブルに切り替えるという従来の考え方から変わりつつあります。
要件やデータのパターンが変われば、テーブル設計を再検討しても構いません。

現時点で推奨されている構成とは？

Single Tableが適している場面

• 複数のテーブルにまたがってデータを取得するオペレーションがある場合
  • getItemを大量に行う必要があるが、1つのテーブルであれば1回のQueryで済む
• CloudWatchで監視する際にテーブル数が多すぎる場合、メトリクスの肥大化を防ぐため
• バックアップの効率化が見込める場合

Multi Tableが適している場面

• テーブルレベルでIAMを明確に分けたい場合
• ユーザープロフィールや履歴データ(例:操作履歴)など、増加特性が大きく違うもの
  • ユーザープロフィールは増加することが少ないが、履歴データは膨大になりやすい
• 月単位でテーブルを削除する必要がある場合、オペレーションコストが減少する
• テーブル単位の操作が必要な場合は、Multi Tableが推奨されます。

結局どちらが良いのか

• SingleとMultiのどちらが正解ということはありません。それぞれのワークロードに適したものを選択する方が良いです。
• 重要なのは、Single → Multi, Multi → Singleのどちらのパターンが適しているかを見極め、必要に応じて変更することです。

どのようにテーブルの分割・統合するか

• DynamoDB Strems
• Export to S3

まとめ

• DynamoDB = Single Tableに縛られず、SingleとMultiを使い分ける
• それぞれのメリットとデメリットを理解する
• 判断に迷ったらモデリングして、良い点と悪い点を整理する
• 現状のモデリングで問題があれば、新しいモデリングにどのように移行するか考えておく

参考