SAA学習-データベース-DynamoDBおよびNoSQLの概要
今回のテーマ：DynamoDBおよびNoSQLの概要
主要サービスの公式資料
DynamoDB：
AWS Black Belt Online Seminar：
概要
完全マネージド型のNoSQLデータベースで特徴は以下の項目があります。
- ハイスケーラブルで無制限に性能拡張が可能
- 負荷が高くなっても応答速度が低下しない低レイテンシー
- 高可用性(SPOFなしでデータは3か所のAZに保存)
- CloudWatchで運用
- プロビジョンスループットテーブルごとにRead/Writeに必要なキャパシティを割り当て
例) Read：100、Write：1000 - ストレージの容量制限がなくデータ容量の増加に応じたディスクやノードの増設は不要
DynamoDBが出来ること
キーバリューでデータを操作することが主要な役割
出来ること
- キーに対するバリューのCRUD操作
- 簡単なクエリオーダー
- 数万人以上が同時アクセス処理が必要になるアプリケーションのデータ処理
出来ないこと/向いていないこと
- JOIN/TRANSACTION/COMMIT/ROLLBACKは不可
- 詳細なクエリデータやオーダー
- 大量のデータ読み書き時のコスト増
DynamoDBの整合性モデル動作
結果整合性モデルで一部処理に強い整合性モデルを利用します。
Write
- 少なくとも2つのAZでの書き込み完了が取れた状態で完了
Read
デフォルト：結果整合性モデル
最新の書き込み結果が即時読み取り処理で反映されない可能性がありオプション：強い整合性モデル
GetItem/Query/Scanでは強い整合性のあるオプション指定が可能
パーティショニング
分散型のNoSQLの特徴で、大量データを高速処理するための機能となります。
パーティショニングの概要図は以下となります。
ユースケース
ビックデータ処理向けか大量データ処理が必要なアプリケーション向けに利用します。
また、大量に発生するWEB行動データやログ管理などに利用します。
ビックデータ
- 大量のデータを収集・蓄積・分析するためのデータベースとして利用
- Hadoopと連携しビックデータ処理が可能
アプリケーション
- 大規模サービスのデータ高速処理が必要なアプリケーション向けに利用
- 多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理に利用
ユーザー行動データ管理
- ユーザー情報やゲーム、広告などユーザー行動データ向けDB
- ユーザーIDごとに複数の行動履歴管理
バックエンドデータ処理
適用判断
トランザクションで発生しうるデータベース処理をチェックし検証します。
判断しうる項目例としては以下のようになります。
テーブル設計
DynamoDBはテーブル利用が開始され以下のように設計していきます。
1.テーブル
DynamoDBのテーブルはデータのコレクションとなります。
他のDBと同様にテーブル単位でデータを保存します。
2.項目(アイテム)
各テーブルの中に項目を作成しデータ保持します。
項目間で一意に識別可能な属性をグループとします。
名前やIDなどの属性を付与する場合は、Personalという項目を作成が必要です。
3.属性
各項目は1つ以上の属性で構成されます。
属性はそれ以上分割する必要のない最小のデータ単位となります。
概略図としては以下のようになります。
※属性はVALUE型やJSON型など不揃いでもDynamoDBならば問題ありません。
インデックス
DynamoDBは暗黙的にに設定するキーと明示的なキーがインデックスとして利用できます。
暗黙的なキー
データを一意に特定するために暗黙的なキー(ハッシュキーやレンジキー)として宣言し、
検索に利用するインデックスで、1テーブルに1つ宣言します。
宣言時に使用されるハッシュキーとレンジキーについては以下のようになります。
ハッシュキー
- KVSにおけるキーに相当するデータを一意に特性するためのIDなどを示します
- テーブル作成時に1つの属性を選びハッシュキーとして宣言します
- ハッシュ関数によってパーティションを決定するためハッシュキーと呼ばれます
- ハッシュキーは単独で重複不可となります
レンジキー
- ハッシュキーにレンジを加えたものでレンジキーまたは複合キーと呼ばれます
- テーブル作成時に2つの属性を選び1つをハッシュキーとし、もう一つをレンジキーで宣言します
- 2つの値の組み合わせによって1つの項目を特定します
- 複合キーは単独であれば重複が可能となります
ハッシュキー/レンジキー・複合キーとテーブルなどの相関概略図は以下のようになります。
明示的なキー
ハッシュキーやレンジキーだけでは検索条件を満たせない場合、LSIとGSIを利用します。
LSIとGSIに対は以下のようになります。
なお、スループットやストレージ容量を追加で必要とするため、多様はするべきではありません。
ローカル・セカンダリ・インデックス(LSI)
プライマリーキータイプがハッシュやレンジキーの場合、追加で別のレンジキーを作成するイメージとなります
1テーブルに5つの作成が可能でテーブル作成時に作成します。
用途について以下のようになります。
- レンジキー以外で絞りこみ検索を行うインデックスで、複合キーテーブルに設定可能
- 複合キーによって整理されている項目に対し、別の規則でインデックス検索を可能
グローバル・セカンダリ・インデックス(GSI)
追加で別のハッシュキーを設定することが可能で、全データに対しグローバルに付与されます。
1テーブルに5つの作成が可能でテーブル作成時に作成します。
用途について以下のようになります。
- ハッシュキーの属性の代わりに代用
- ハッシュキーテーブルおよび複合キーテーブルどちらにも設定可能
- ハッシュキーを跨いで自由に検索可能
テーブル操作
テーブル操作を行う代表的なコマンドは以下となります。
| コマンド | 概要 |
|---|---|
| GetItem | ハッシュキーを条件に一定の項目を取得 |
| PutItem | 1件のアイテムを書き込む |
| Update | 1件のアイテムを更新 |
| Delete | 1件のアイテムを削除 |
| Query | ハッシュキーとレンジキーにマッチする項目を取得(最大1MB) |
| Scan | テーブル全件検索する(最大1MB) |
| BatchGetitem | 複数のプライマリーキーに対しマッチする項目を取得 |
DynamoDB Streams
DynamoDBテーブルに保存された項目の追加・変更・削除が発生時に履歴をキャプチャする機能となります。 利用できる機能概要は以下となります。
データの保存
- 過去24時間以内のデータ更新履歴を保存し、24時間を経過すると消去
- データ容量はマネージド型で自動的に管理
データ保存の順番
- 操作が実施された順番に応じてデータをシリアライズ
- 特定のハッシュキーに基づいた変更は正しい順番で保存
- ハッシュキーが異なる場合、受信した順番が前後する可能性があり
DynamoDB Streamsのユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用可能です。
事例としてアプリケーションのプッシュ通知などがイメージとなります。
概略は以下の2つとなります。
データ更新をトリガーとしたアプリケーション
データ更新に応じた通知処理などのアプリケーション処理実行など
実装する方法や用途の概略図は以下となります。
DynamoDB Accelerator(DAX)
DAXはDynamoDBにインメモリキャッシュ型の機能を付与します。
概略図としては以下のようになります。
特徴は以下のようなものがあります。
- インメモリキャッシュとして1桁台のミリ秒単位からマイクロミリ秒単位まで結果整合性のある読込ワークロードの応答時間短縮(トレーディングシステムなど)
- マルチAZDAXクラスターは1秒間に数百万件のリクエスト処理が可能
- DAXはDynamoDBを使用するAPIと互換性を持つマネージド型サービスのため、メンテナンスなどの運用や導入が容易に可能
- スループットの強化やキャパシティユニットを必要以上にプロビジョンしないように設計・実装することで運用コストの節約が可能
グローバルテーブル
リージョン間で同期されるマルチリマスターテーブルを作成可能となります。
概要としては以下のようなものがあります。
- DynamoDBの性能のまま世界中で複数のリージョンにエンドポイントを持つことが可能
- 読み書きのキャパシティに加えクロスリージョンレプリケーションのデータ転送料金が課金
- オプションで実施で強い整合性は不可
オンデマンドバックアップ
パフォーマンスに影響なく数百TBのバックアップが実行可能です。
概要としては以下のようなものがあります。
- 任意のタイミングで利用可能な長期間データ保存用バックアップ
- データパイプラインという別サービス利用が必要だった
Read/Writeキャパシティオンデマンド
キャパシティ設定不要でリクエストに応じた課金設定により実装が可能となります。
概要としては以下のようなものがあります。
- トラフィック量の予測が困難な場合、リクエストの実績数に応じた課金が可能
- オンデマンドでRead/Write処理に自動スケーリングを実施
- プロビジョンドキャパシティ設定への変更は無制限
- オンデマンドへの変更は1日1回まで可能
今回のテーマは以上です。
補足：
既存のRDB中心の設計から、
DynamoDB/Lambdaなどの組み合わせで、
サーバレスでサービスが実装できないか初期段階で、
検討も一考の余地があるかと思います。
それに伴いコスト低減が実現することも視野入れつつ代用不可ならば、
RDSを活用する考え方を考慮してもよいかもしれません。
