この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS re:Invent 2019 DAT403-R - [REPEAT] Amazon DynamoDB deep dive: Advanced design patternsのセッションレポートです。DynamoDBのインデックスの説明から始めて、実アプリケーションのアクセスパターンに応じたテーブルの設計方法について解説しています。
セッション情報
登壇者
Rick Houlihan
概要
This technical session is for advanced users of Amazon DynamoDB. The patterns and data models discussed in this presentation summarize a collection of implementations and best practices used by large customers—including Amazon retail businesses—to deliver highly scalable solutions for a wide variety of business problems. We delve into strategies for global secondary index sharding and index overloading, scalable graph processing with materialized queries, relational modeling with composite keys, executing transactional workflows on DynamoDB, and more.
動画
スライド
レポート
アジェンダ
- データ処理の小史（なぜNoSQLなのか？）
- DynamoDBの概要
- NoSQLのデータモデリング（正規化と非正規化）
- NoSQLに共通するデザインパターン（複合キー、階層データ、リレーショナルデータ）
- 実際のアプリケーションのモデリング
なぜNoSQLなのか？
DynamoDB
テーブルの構造
- Itemに対してAttributesが存在する
- Partition keyが必須
- Sort keyは任意でクエリ機能を提供する
Secondary indexes
- 従来のDBのようなアクセスをする際に利用する
- Sort key以外のアクセスパターンを提供する
- 複合ソートキーや複合インデックスを利用できる
- Keyは内部的にHashに変換されている
- 書き込み時にSecondry Indexを作成しておくことで検索できる
- 実際のアクセスパターン
SQLとNoSQLのデザインパターン
- SQLは正規化する
- NoSQLは非正規化する
アドホックなSQL
- SQLの場合は結合条件によって処理時間が延びる
NoSQLの場合は結合済みのモデルにする
- 処理時間は一定になる
NoSQLに共通するデザインパターン
ドキュメントと列指向
- ドキュメントデータにおけるインデックスと複合インデックス
- NoSQLにおける効率の良いインデクシング
クエリフィルタと複合キーによるアプローチ
- クエリフィルタのアプローチ
- 複合キーによるアプローチ
実アプリケーションのモデリング
複雑なリレーションをモデリングする
- スキーマ
- テーブルとアクセスパターン
- インデックスのスキーマ
- 最終的な結果
アクセスパターンに対する対処
- データ構造を変更することで書き込み時のWCUを95%削減できる
その他
- NoSQL Workbench for DynamoDBもあるよ
結論
- NoSQLはリレーションがないことを意味しない
- ERDは未だに重要
- RDBMSはNoSQLによって不要になっていない
- NoSQLはスケールが必要なOLTPかDSSに使用する
- RDBSMはOLAPに使用する
感想
DynamoDBのインデックスの説明から始めて、実アプリケーションのアクセスパターンに応じたテーブルの設計方法について説明してくる有用なセッションだったと思います。DynamoDBのモデリングについて悩んでいる方はぜひスライドを参照することをおすすめします。
16
