DynamoDB開発者ガイド要約
DynamoDB開発者ガイド要約
参考資料
Amazon DynamoDB 開発者ガイド API バージョン 2012-08-10
DynamoDBとは
AWSのプロダクトの一つ。
DynamoDBなのでデータベースである。
リレーショナルデータベースではなくNoSQLである。
NoSQLとは
NoSQLは Not only SQL の略と解釈されるのが一般的である。
NoSQLはRDBではないため共通する特徴として非構造のデータを扱うことができるというものがある。
NoSQLには大きく下記の四つに分類されることが多い。
- キーバリューデータストア
- 列ファミリーデータストア
- 文書データストア
- グラフデータストア
DynamoDBはこれらのうちのキーバリューデータストアに分類される
キーバリューデータストアとは
この構造の原型がAmazonのDynamoであると言われている。
高い可用性とスケーラビリティが特徴である。
主キーに対してBLOBの値を持つのみという極めてシンプルな構造を持っている。
複雑なクエリを発行することはできない。
DynamoDBのしくみ
テーブル
各データはテーブルに保存される。
項目(Items)
項目(item)はRDBに置ける行(record)に相当する。
項目はプライマリキーによって一意に識別可能であることが前提となる。
テーブルごとの項目数の制限はない。
属性(Attributes)
属性はRDBにおける列に相当する。
属性にはそれ以上分割できない単位のデータを格納する。
属性を入れ子にすることもできる。 最大32階層までの入れ子属性をサポートしている。
属性のうち一つ必ずプライマリキーとなる要素が含まれている必要がある。
非構造
テーブルの項目はスキーマレスであることが許容されている。
プライマリキー以外の属性やデータ型を定義する必要がない。
テーブル内の各項目がそれぞれバラバラな属性や構造を持っていても良い。
プライマリキー
前述のようにテーブルにはそれぞれ一つ以上のプライマリキーが定められていなければならない。
プライマリキー属性の値はスカラー値（文字列・数値・バイナリのいずれか）である必要がある。
プライマリキーは二種類のものがある。
パーティションキー
シンプルなプライマリキー。 DynamoDBの内部でパーティションキーの値をハッシュ関数にかけその出力に基づいて項目が保存される物理ストレージのアドレスが決まる。 ハッシュ属性とも呼ばれる。
パーティションキーの値にアクセスすることで物理ストレージの目的の項目のアドレスに直接アクセスすることができる。
プライマリキーがパーティションキーのみである場合はキーの値が項目間で一意である必要がある。
パーティションキーとソートキーの複合
複合プライマリキーと呼ばれる。
第一のプライマリキーはパーティションキーであり第二のプライマリキーがソートキーとなる。
複合プライマリキーの場合は複数の項目のパーティションキーに同じ値を用いることもできる。 ただしソートキーは異なる値である必要がある。 ソートキーは範囲属性とも呼ばれる。
同じパーティションキー値を持つ項目は物理ストレージの同じ領域にソートキーの値によって分類されて物理的に近い場所に格納される。
複合プライマリキーのメリット
データのクエリを実行する際の柔軟性を高める。
パーティションキーとソートキーの組み合わせでクエリの範囲を調整することができるためである。
セカンダリインデックス
DynamoDBではプライマリキー属性に対してインデックスを作成している。 基本的にはプライマリキーを指定することでデータへのアクセスを迅速に行うことができる。
プライマリキー以外の属性を指定した場合でも効率的なデータへのアクセスを実現したい場合はセカンダリインデックスを使用することができる。
テーブルにグローバルセカンダリインデックスを作成することでテーブルから直接データを読み込むのとほぼ同様の方法でインデックスからデータを読み取ることができる。
読み込み/書き込みキャパシティモード
テーブルでの読み込みと書き込みについてキャパシティモードが2つ設けられている。
キャパシティモードは１秒あたりにどれだけのリクエストを許容するかの指標である。
- オンデマンド
- プロビジョンド
プロビジョンドはデフォルトであり無料枠である。
オンデマンドモード
オンデマンドモードではリクエスト数に制限がない柔軟なオプションである。
リクエスト数に応じて支払い料金が発生する。
リクエスト数が事前に予測できない場合は有効なオプションと言える。
プロビジョニングモード
１秒あたりの読み込みと書き込みの回数を指定する必要がある。
Auto Scaling が有効である場合トラフィックに応じてテーブルのプロビジョンドキャパシティーを自動的に調整することができる。
リクエスト数が予測可能である場合はプロビジョニングモードが有効である。
読み込みキャパシティーユニット/書き込みキャパシティーユニット
プロビジョニングモードのテーブルでは読み込みキャパシティユニットと書き込みキャパシティーユニットの二つの基準に基づいてスループットを調整することができる。
読み込みキャパシティーユニット
読み込みキャパシティユニット一つにつき最大サイズ4KBの項目について１秒あたり1回の強力な整合性のある読み込み、あるいは1秒あたり2回の結果整合 のある読み込みを行うことができる。
必要な読み込みキャパシティユニットの数は項目のサイズと読み込みの種類によって変動する。
例として項目サイズが8KBの場合は4KBの場合に比べて倍の数の読み込みキャパシティユニットが必要になる。 このように項目のサイズが大きければ大きいほど必要な読み込みキャパシティユニットの数は増える。
書き込みキャパシティーユニット
一つの書き込みキャパシティユニットはサイズが1KBまでの項目について1秒あたり1回の書き込みを行うことができる。
1KBを超えて書き込みを行う場合、項目のサイズに比例して追加のキャパシティユニットが必要になる。
また、トランザクション書き込みリクエストの場合は通常のリクエストの倍のキャパシティユニットが必要になる。
ProvisionedThroughputExceededException
意図せず大量のキャパシティーユニットが消費されるのを防ぐためにスロットリングも動作するようになっている。
スロットリングはテーブルがサポートできるよりも高いレートで読み込みや書き込みが試みられた場合に発生する。
スロットリングが発動するとリクエストはHTTP Bad Request となり ProvisionedThroughputExceededException が返る。
AWS SDKにはスロットリングされたリクエストを再試行するためのサポートもある。
CloudWatchではスロットリングされた書き込み/読み込みリクエストをモニタリングすることができる。
スループットについて検討する際に考慮すべきこと
項目のサイズ
項目のサイズが十分に小さければリクエストが大量に発生しない限り消費ユニットを少なく収めることができる。
項目のサイズは予測できる範囲に収められるように設計すべきで、かつできる限り小さなものになるように努力すべきである。
リクエストのレート
リクエスト数についても可能な限り見積もりがなされるべきである。
ただし、項目のサイズを小さく保つことができればこの見積もりも難しいものではなくなるはずである。
Auto Scaling
DynamoDB Auto Scaling ではテーブルのスループットキャパシティが自動的に管理される。キャパシティユニットの上限と下限が自動で定義される。
トラフィックが増加した場合、リクエストのスロットリングが発生しないためにキャパシティの増加を行う。
また、意図的にスループットを低下させるような処置も行う。
