Dynamo db はじめの一歩
- 2. はじめに DynamoDBの検証に伴い、ドキュメントを読み込んだので、知見を共有。 DynamoDBを使用する際に、 地雷を踏まない（であろう）アーキテクチャ設計が行えるようになることを目 的とする。
- 3. (; ?`д??)
- 7. コンテンツ ● DynamoDBとは ● 重要な用语 ● 仕组み ● 課金体系 ● メリット ● デメリット ● 事故らないためのアーキテクチャ設計
- 8. DynamoDBとは ● AWS上で利用可能なフルマネージドなNoSQLデータベースサービス ● スキーマレス ● ３つの施設間でデータが同期的にレプリケート ● SSDに保存 ● データの操作はHTTP(S)リクエストで行う
- 9. 重要な用语
- 14. 仕组み
- 17. 仕组み PKとは??? プライマリキーのこと。 以下のどちらかで作成可能 ?HASH ?HASH + Sort Key なので、RDBMSで云うところの複合PKは、２個までしか選べない 3個以上選びたい場合は、ロジックでキーを作ってカバー！！
- 18. 課金体系 無料利用枠を超えると課金が発生する 無料利用枠 ● ２億リクエスト／月 ※25の読込書込キャパシティユニットで超えない程度 ● 25GBのデータストレージ（データ + インデックス分） ● DynamoDBストリームからの250万件読込み／月
- 19. 課金体系 無料利用枠を超えると課金が発生する 無料利用枠 ● ２億リクエスト／月 ※25の読込書込キャパシティユニットで超えない程度 ● 25GBのデータストレージ（データ + インデックス分） ● DynamoDBストリームからの250万件読込み／月 何言ってるのか判りづらいけど、 ストレージ以外は毎月無料枠があるよ！ ってことです。
- 20. 課金体系 無料利用枠を超えると課金が発生する 無料利用枠 ● ２億リクエスト／月 ※25の読込書込キャパシティーユニットで超えない程度 ● 25GBのデータストレージ（データ + インデックス分） ● DynamoDBストリームからの250万件読込み／月
- 24. 課金体系 ● 読込みキャパシティーユニット(RCU) １つのキャパシティーユニットで、1秒間に最大4KBを 「１回の整合性のある強力な読込み」 or 「２回の結果的に整合性のある読込み」 を行える。
- 25. 課金体系 意味???判るよね？
- 26. 課金体系 データ量で表すとこや！
- 27. 課金体系 ● １キャパシティーユニットで1KBを読み込む 強力な～ ???1消費するので１秒間で１回読める 結果的に～???1消費するので１秒間で２回読める（スループット２倍） ● １キャパシティーユニットで4KBを読み込む 強力な～ ???1消費するので１秒間で１回読める 結果的に～???1消費するので１秒間で２回読める（スループット２倍） ● １キャパシティーユニットで5KB読み込む 強力な～ ???2消費するので２秒間で１回読める 結果的に～???2消費するけど１秒間で１回読める（スループット２倍だから）
- 29. 課金体系 こうなる
- 30. 課金体系 ● １キャパシティーユニットで1KBを読み込む 強力な～ ???1消費するので１秒間で１回読める 結果的に～???1消費するので１秒間で２回読める（スループット２倍） ● １キャパシティーユニットで4KBを読み込む 強力な～ ???1消費するので１秒間で１回読める 結果的に～???1消費するので１秒間で２回読める（スループット２倍） ● ２キャパシティーユニットで5KB読み込む 強力な～ ???2消費するので１秒間で１回読める 結果的に～???2消費するけど１秒間で２回読める（スループット２倍だから）
- 31. 課金体系 以下の計算式で考えてあげればOK（先にこっち出せとか言わないで???） ● 強力な～ ???（キャパシティユニットの値）×４KB／秒 ● 結果的に～???（キャパシティユニットの値 × 2）×４KB／秒
- 33. 課金体系 ● １キャパシティーユニットで1KBを書き込む???１消費（１秒でイケる） ● １キャパシティーユニットで1.1KBを書き込む???２消費（２秒かかる） ● ２キャパシティーユニットで1.1碍叠読み込む???２消费（１秒でイケる）
- 35. 課金体系 無料利用枠 ● ２億リクエスト／月 ※25の読込書込キャパシティーユニットで超えない程度 ● 25GBのデータストレージ（データ + インデックス分） ● DynamoDBストリームからの250万件読込み／月 有料枠 ● 25GB以上のデータストレージに、0.285USD/GBを毎月払う
- 36. メリット ● どんなにデータを保存しても、パフォーマンスは安定している ※使い方を誤らなければ ● DSLに則ってJSONを書けばいいだけなので、専門スキルは不要 ● 书込み元が多いほど、威力を発挥する
- 41. 利用シーン ● ログの集約 特にコンテナ化されているもの、マイクロサービス化したシステム群 ● IoT周り デバイスから直、フォグサーバ経由 ● 膨大な履歴データの保持 何かのタイミングでスリムアップはした方が良いと思う
- 42. おしまい