DynamoDB
https://gyazo.com/ea3df894d85f438e30809fa60112527c
ポイント
要はDynamoDBは連想配列の形でデータを持ってるから、キーは一意にしなきゃいけないし、検索するにしてもキーでしか検索できないに決まってるよ
SQLのWhere句に入れられるようなものは、基本的にはパーティションキー（ハッシュキー）とソートキー（レンジキー）だけ。
テーブル自体のパーティションキー（プライマリキー）には重複が許されていない
GSIのパーティションキーでは重複が許されているので、これを利用して検索を行う
用語
パーティションキー(ハッシュキー)
DynamoDBは複数のパーティションに分散して保存される
パーティションキーをもとにどのパーティションに保存されるか決定される
各パーティションへのアクセスがなるべく均一になるようパーティションキーを設計すると良い。
ソートキー(レンジキー)
パーティション内でソートキーを元に並べ変えられて物理的に近くに配置される
プライマリキー
データを一意に識別する(主キー)
パーティションキーだけかパーティションキーとソートキーの複合キー
グローバルセカンダリインデックス
全てのパーティションのデータにまたがって検索できる
パーティションキーとソートキーが異なる
パーティションキーだけを指定して作成もできる
hiroki.icon要は検索用のキーを加えて拵えることができるってことだね
ローカルセカンダリインデックス
パーテションキーは同じだがソートキーが異なる
/icons/point.iconテーブル作成時にしか作成できない
PutItem
プライマリキーを指定して単一のデータを書き込む
GetItem
プライマリキーを指定して単一のデータを取り出す
Query
パーティションキーを指定して複数のデータを取り出す。
ソートキーを指定して取り出すデータの範囲をフィルタ
GSIのパーティションキーを指定することで複数対象への検索を行える
UpdateItem
プライマリキーを指定して単一のデータを更新する
Scan
全件検索
全件からフィルターするので重い
一度に1mbまでしか取得できない→続けて後続リクエストを送ることで全体を取得する
DynamoDB Accelerator(DAX)
インメモリキャッシュで高速化する
コンピューティングをスケールして高速化するわけではない
TTL
「この属性の日時（UNIX時間）を過ぎたら削除してね機能
期限切れになる時間をunixtimestampで保存しておくとその時間以降に項目を削除してくれる
例えば項目をputした2時間後のtimestampを登録することで2時間後に自動削除する
データ取得パターン
GetItemでの主キー一件検索
Queryでの複数アイテム検索
Query＝GSIの使用
必ずkeyを指定しないといけないのでGSIを設定しても純粋に最新100件みたいなのは難しそう
GSIに日付（パーティションキー）とunixtimeスタンプ（ソートキー）を指定することで可能ではある
Scanでの全件検索
できないこと
ソートキーのみの範囲指定検索
必ずパーティションキーは指定しなければいけない
→グローバルセカンダリインデックスで日付とtimestampを指定して擬似的に日付範囲で検索とかはできそう
パーティションキー(インデックスキー)に対して行える条件比較は限られている
eqはできるけど、in/containsとかはできない
複数のアイテムを一気に削除することはできない
既存のテーブル名の変更ができない
Dynamoは集計に弱い
グローバルセカンダリインデックスの設定とかソートキーなどで多少効率的にできるけど、大きくリードキャパシティを消費してしまう可能性が高い
フルスキャンならなおさら
スキーマの変更
ユースケース
ユーザのロケーション情報などの定期格納
ロケーションベースのリアルタイム処理
最新のデータを取得したい
→タイムスタンプ的なソートキーを設定しておかないといけない
code:dynamo
//起動
docker run -d -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -inMemory -sharedDb
-sharedDb オプション
単一のDBファイルを使うようにする
S: 文字列
N: 数値
L: リスト
参照