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