インスタンスについて
VPCではなくS3のようにグローバルセグメント？(この言い回しが正しいか謎(^_^;))に配置される。
プライマリキーについて
RDBと同様、データを一意に特定できるプライマリキーの設定が必要。プライマリキー以外の項目はスキーマレスで自由に登録できる。
プライマリキーはパーテーションキー、またはパーテーションキー + ソートキーで構成される。
パーテーションキー + ソートキーの組み合わせはRDBでいうところの複合プライマリキーのようなもの。併せた値がテーブル上でユニークになる。
各フィールド
400KBまで。
セカンダリインデックス
通常はプライマリキーまたはパーテーションキーを指定してフェッチを行うが各フィールドにセカンダリインデックスを設定することで条件に応じたデータを取得することができる。
グローバルセカンダリインデックス
パーテションキーを無視してテーブル内を横断的に検索するインデックス。
例えばuserテーブルのTELや郵便番号のデータフィールドに設定する。
1テーブル当たり、最大で５つまで。
ローカルセカンダリインデックス
パーテーションキーに追加してデータを検索するインデックス。
多分、ソートキーの代わりにデータを検索するキー。
例えばchatMessageテーブルの投稿者データフィールドとか。かな。
1テーブル当たり、最大で５つまで。
結果整合性
DynamoDBはCassandraのような分散モデルDBで、CAP理論でいうところのConsistency(一貫性)を担保していない。
つまり書きこんだばかりのデータの参照は各問い合わせノード次第で結果が違ってくる。
デフォルトでは結果整合の遅延を許可するといった問い合わせだが、必ず各ノード最新のデータを返却するといった強力な整合性のある読み込みで問い合わせることもできる。
もちろん強力な整合性のある読み込みは時間がかかる場合もあるし、時には問い合わせが失敗する場合もある。
アトミックカウンタ
RDBでいうところのシーケンスは採番用テーブルを用意する。
パーテーションキーをtableNameとして各テーブルのcurrentを記録しておく。
seq = seq + 1
とし、DynamoDBは更新処理で結果データを返すことが出来るので、重複しないシーケンスとして利用できる。
尚、RDB同様、複数の並列更新があっても、更新時のデータはロックを取って直列で行っている模様。なので、上記のクエリではロストアップデートは行われない。
