DynamoDB
キャパシティーユニット
クエリ時の式(Expression)
projection-expression
取得する項目の式。SQLでいう SELECT の最初のリスト
AS みたいなやつもある。Dynamoの予約語とのコンフリクト回避などにも有効。
filter-expression
条件式。SQLでいう WHERE 句
data-expression
こんなものはない
query-expression
こんなものはない
TTL
使える。削除のタイムスタンプを設定できる。
トランザクション
手続きをすれば使える。
プロビジョンド
分単位のIOでこの分だけは確保しておきたいってやつの設定。高そう。
BatchGetItem API
まとめてデータ取得
BatchWriteItem API
まとめてデータ書き込み
アトミックカウンター
他の書き込み要求を妨げない無条件のインクリメント処理。
UpdateItem の振る舞いの一つ。
ローカルセカンダリインデックス
テーブル作成時に指定することができる、パーティション単位の追加インデックス。
テーブル単位に5個まで設定できる。
パーティションを跨って機能しない。
後から追加することはできない。
グローバルせカンダリインデックス
こちらもテーブル単位の追加インデックスだが、パーティションを跨って機能できるし後から追加できる。
テーブル単位に5個まで設定できる。
実態としてはパーティションキー・ソートキーの追加セットという感じ。
ただ、メインのパーティション・ソートキーと異なり、その値が必須になるわけではない。RDBMSの追加複合インデックスと捉えるのがいいかもしれない。
便利だが、クエリで消費するキャパシティーユニットが書き込み・読み込み分共に増加する。
オブジェクト永続性モデル
エンティティクラスのインスタンスとDynamoDBのレコードを一致させるアイデア。公式のSDKでもサポートされている。
バージョン番号によるオプティミスティックロックを使うことで、複雑な更新への不整合に強くなる。
オプティミスティックロック = 楽観的ロック
具体的には、クライアント側のバージョン番号と DynamoDB 上のバージョン番号が一致している場合に限り Update を進めることができるようになる。
スロットルエラーに対する安価な対処
エラー時の再試行 + 指数バックオフを使う
RCU/WCUを向上させなくても、再試行である程度の信頼性が担保できる
DynamoDBストリームの種類
StreamViewType
KEYS_ONLY
変更されたアイテムのキー属性だけ
NEW_IMAGE
変更されたアイテム全体
OLD_IMAGE
変更される前のアイテム全体
NEW_AND_OLD_IMAGE
上の両方
DynamoDBストリーム + Kinesis
DynamoDB Streams Kinesis Adapter を使う
クエリに対して効いたインデックスをレスポンスとして返す
DynamoDBのテーブル設定
ReturnConsumedCapacity パラメータに INDEXES を追加する
セカンダリインデックスの情報も帰ってくる
TOTAL にするとキャパシティーの消費数だけを返す
INDEXES でもこれは返ってくる
スキャン
クエリと違ってインデックスを使わないやつ
「フィルタ式」で返す項目のコントロールができる
「並列スキャン」を使うことで努力的にパフォーマンスを向上できる
早くなるけどRCUの消費も早くなるのだろう