DynamoDB
はじめの一歩
sh-ogawa
はじめに
DynamoDBの検証に伴い、ドキュメントを読み込んだので、知見を共有。
DynamoDBを使用する際に、
地雷を踏まない(であろう)アーキテクチャ設計が行えるようになることを目
的とする。
(; ・`д・´)
検証しただけで運用はしてないので、
ハードルは少し下げさせていただく!!
質問は都度していただいてOKです
答えられるかは判らないけど
コンテンツ
● DynamoDBとは
● 重要な用語
● 仕組み
● 課金体系
● メリット
● デメリット
● 事故らないためのアーキテクチャ設計
DynamoDBとは
● AWS上で利用可能なフルマネージドなNoSQLデータベースサービス
● スキーマレス
● 3つの施設間でデータが同期的にレプリケート
● SSDに保存
● データの操作はHTTP(S)リクエストで行う
重要な用語
重要な用語
キャパシティーユニット
重要な用語
これだけ覚えれば大丈夫
重要な用語
● キャパシティーユニット(CU)
1秒間に消費できるリソースを定義する単位。
読込みと書込みのそれぞれに設定する。
重要な用語
● キャパシティーユニット(CU)
1秒間に消費できるリソースを定義する単位。
読込みと書込みのそれぞれに設定する。
「例えば、読込みキャパシティーユニットに「10」を設定した場合、
1秒間に利用できる読込みリソースは「10」である」と云える(超重要)
※消費リソースの算出方法は後ほど・・・
仕組み
仕組み
保存するストレージは
物理的に分かれている
仕組み
どのストレージに書か
れるかは、PKの値で
決まる
仕組み
PKとは・・・
プライマリキーのこと。
以下のどちらかで作成可能
・HASH
・HASH + Sort Key
なので、RDBMSで云うところの複合PKは、2個までしか選べない
3個以上選びたい場合は、ロジックでキーを作ってカバー!!
課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● 2億リクエスト/月
※25の読込書込キャパシティユニットで超えない程度
● 25GBのデータストレージ(データ + インデックス分)
● DynamoDBストリームからの250万件読込み/月
課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● 2億リクエスト/月
※25の読込書込キャパシティユニットで超えない程度
● 25GBのデータストレージ(データ + インデックス分)
● DynamoDBストリームからの250万件読込み/月
何言ってるのか判りづらいけど、
ストレージ以外は毎月無料枠があるよ!
ってことです。
課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● 2億リクエスト/月
※25の読込書込キャパシティーユニットで超えない程度
● 25GBのデータストレージ(データ + インデックス分)
● DynamoDBストリームからの250万件読込み/月
課金体系
25の読込書込キャパシティーユニットで超えない程度
課金体系
(; ・`д・´)意味不明!!
課金体系
キャパシティーユニットの消費量について教えます
課金体系
● 読込みキャパシティーユニット(RCU)
1つのキャパシティーユニットで、1秒間に最大4KBを
「1回の整合性のある強力な読込み」
or
「2回の結果的に整合性のある読込み」
を行える。
課金体系
意味・・・判るよね?
課金体系
データ量で表すとこや!
課金体系
● 1キャパシティーユニットで1KBを読み込む
強力な~ ・・・1消費するので1秒間で1回読める
結果的に~・・・1消費するので1秒間で2回読める(スループット2倍)
● 1キャパシティーユニットで4KBを読み込む
強力な~ ・・・1消費するので1秒間で1回読める
結果的に~・・・1消費するので1秒間で2回読める(スループット2倍)
● 1キャパシティーユニットで5KB読み込む
強力な~ ・・・2消費するので2秒間で1回読める
結果的に~・・・2消費するけど1秒間で1回読める(スループット2倍だから)
課金体系
なので、
1秒間で読み込めるようにするには
キャパシティーユニットを増やす
課金体系
こうなる
課金体系
● 1キャパシティーユニットで1KBを読み込む
強力な~ ・・・1消費するので1秒間で1回読める
結果的に~・・・1消費するので1秒間で2回読める(スループット2倍)
● 1キャパシティーユニットで4KBを読み込む
強力な~ ・・・1消費するので1秒間で1回読める
結果的に~・・・1消費するので1秒間で2回読める(スループット2倍)
● 2キャパシティーユニットで5KB読み込む
強力な~ ・・・2消費するので1秒間で1回読める
結果的に~・・・2消費するけど1秒間で2回読める(スループット2倍だから)
課金体系
以下の計算式で考えてあげればOK(先にこっち出せとか言わないで・・・)
● 強力な~ ・・・(キャパシティユニットの値)×4KB/秒
● 結果的に~・・・(キャパシティユニットの値 × 2)×4KB/秒
課金体系
● 書込みキャパシティーユニット(WCU)
1つのキャパシティーユニットで、1秒間に最大1KBを書込める。
課金体系
● 1キャパシティーユニットで1KBを書き込む・・・1消費(1秒でイケる)
● 1キャパシティーユニットで1.1KBを書き込む・・・2消費(2秒かかる)
● 2キャパシティーユニットで1.1KB読み込む・・・2消費(1秒でイケる)
課金体系
こっちは1KB未満の端数切り上げ
という簡単な理屈ですね
課金体系
無料利用枠
● 2億リクエスト/月
※25の読込書込キャパシティーユニットで超えない程度
● 25GBのデータストレージ(データ + インデックス分)
● DynamoDBストリームからの250万件読込み/月
有料枠
● 25GB以上のデータストレージに、0.285USD/GBを毎月払う
メリット
● どんなにデータを保存しても、パフォーマンスは安定している
※使い方を誤らなければ
● DSLに則ってJSONを書けばいいだけなので、専門スキルは不要
● 書込み元が多いほど、威力を発揮する
デメリット
● パフォーマンスを出させる場合、基本的に札束で殴るスタイル
(と言っても、そこまで高額なわけではない。
保存しているデータ量だけ注意してあげる)
● NoSQLなので、トランザクションの概念はない
(RDB使ってても、
厳密なトランザクション管理をしないといけない場面はほとんどない)
事故らないためのアーキテクチャ設計
可能な限り
横に並べて殴る
(特に書込み)
事故らないためのアーキテクチャ設計
これだけ
事故らないためのアーキテクチャ設計
外部ライブラリ使ってデータを登録する場合は、
そのライブラリがちゃんとマルチスレッドか、
子プロセスを立ち上げてデータ登録をしていることを確認
しておく。
利用シーン
● ログの集約
特にコンテナ化されているもの、マイクロサービス化したシステム群
● IoT周り
デバイスから直、フォグサーバ経由
● 膨大な履歴データの保持
何かのタイミングでスリムアップはした方が良いと思う
おしまい

Dynamo db はじめの一歩