DynamoDB
installやupdateが不要
メンテナンス不要
DBの容量の設定も不要
暗号化、バックアップの設定も不要
苦手なこと
データの集計
合計値や平均値を算出する機能はない
やるなら、自前で実装したりする必要がある
どれぐらいできるものなのか #??
複雑な検索
キーを指定することに依る検索しかできない
したい場合は、Amazon Elasticsearch Serviceと組み合わせたりする
始め方
参考
入門
>#WIP
設計方針
具体的
使用事例
zozotown
どのような規模でも信頼性が高いパフォーマンスを維持できる
同時接続数が増加しても容易に対応できる
そのためAWS Lambdaなんかと相性が良い
マルチリージョン
マルチマスター
レイテンシーを 10ms未満に維持
組み込みのセキュリティ
バックアップと復元
インメモリキャッシュ
データの格納と取得に特化
期限切れになった項目を自動的にテーブルから削除することもできる
parimary keyの選択
partition key
普通のRDBと同じノリ
パーティションキーは
= の検索しかできないどういうルールで付けるの #??
自動で連番にならないということは何かしらの規則が必要なのだろうけど
あるあるpartition keyはどんなの #??
test-0000 とか？sort key
ソートキーによって、sortや範囲検索ができる
データ追加する時に適当に付けて良いの #??
2#a#employee-0004 みたいにして、 (階数)#(フロア名)#(社員 ID) というformatを表したりするマジ？？
RDB脳には考えられないな
文字列と区切り文字で何かを表現するのか
でも、他の人にとってはわかりにくいし、変更も容易じゃなくない #??
そこは妥協するのか？
用語
項目
RDBでの、record
属性
RDBでの、column
インデックス
レプリカ
割とテクニックが要りそう
非正規化する
ユースケース駆動という感じ
このtableはどのparameterで検索され、どのparameterを返すことを想定しているのか、などを考慮する
でも、それってアプリケーションの仕様変更されたら辛くならない #??
valueにjsonが入ることもある
同じ名前が、おなじ項目として存在することもあるのね
ユースケース駆動だからか
名前が変更になったときは、両方とも変更する必要がありそうだが、どうするのか #??
DynamoDB Streamsという機能を使う
ユースケースによってはJSONは辞めたほうが良いこともあるということか？
むずかしー
partition keyで区切って、Many to Manyを表現する
グローバルセカンダリインデックス(GSI)を使ったりもする
優れた設計のアプリケーションで必要なテーブルは1つのみ
必要な情報はなるべく1度のqueryで検索するのが理想
検索
query
主キーで検索する
パーティションキーとソートキーの複合主キー
parittion keyなら
= だし、sort keyなら範囲絞り込みなどができるRDBのqueryと同じノリ
scan
クエリと違い、すべての項目と属性を読み込む
queryよりも検索の自由度が高い
queryより圧倒的に遅い
key関係なく全ての項目をscanするからか
そのため、基本的にscanのは使用は避けるべき
キーを指定せずにフィルターのみを使用するのが異なる点 #??
これ、異なる意味あるのか？
よくわからん
KVSの一般的な話だと思うが、良い属性の付け方がいまいちわからない
適当につけると、こんなふうにデータに依って異なる属性が付けられるがこれは良いのか #??
どうやってデータ追加する年 #??
大きいデータの扱い
1つの項目の最大サイズは400KB
1回のqueryで取得できる項目のサイズは1MB以内
データ容量分の料金がかかるので、不要になったデータは消していきたい
Time To Liveを使うと有効期限を指定できる
過ぎたら勝手に消してくれる
どういう単位でtableを分けるのか？
rdbみたいに小さく分けるわけではないと思ってるけど、そうなのか？
ユースケース
Serverlessをやるときによく使われる
AWS Lambdaと併用される
ミリ秒単位のアクセスレイテンシーが求められる
データの拡張性が求められる
関連投稿
マガジンの人気ランキング