20分で分かるDynamoDB/DynamoDB in 20 minutes

https://jawsug-nagoya.doorkeeper.jp/events/81320
2018-10-17（水） JAWS-UG名古屋 AWS勉強会 データベース祭りでの発表です。
re:Invent 2018 発表で古くなった部分（限定的なトランザクション対応やキャパシティプランニングが不要なモードなど）はありますが、全体的には参考になるかと思います。

Transcript

1. 20分で知るDynamoDB JAWS-UG名古屋 TATSUNO Yasuhiro 2018年10月17日 AWS勉強会 データベースまつり
2. 自己紹介 ▪ TATSUNO Yasuhiro ▪ ユーザー系SIer→来栖川電算 – サーバーレスアプリのプロダクトマネージャ – AWSさん、お世話になっております ▪ JAWS-UG名古屋 – 去年LT、今年8月から運営メンバー ▪ 好きなAWS：Lambda、CloudFront
3. AWS DynamoDBとは ▪ 分散 NoSQL データベース ▪ フルマネージド ▪ サービスイン – 2012年1月18日 北米 – 2012年3月1日 東京
4. NoSQL データベース としてのDynamoDB
5. 様々なDB技術の中で DynamoDB の位置付け RDB KVS ドキュメントDB グラフDB 列指向DB 特徴 長い歴史で技術 が成熟、ノウハ ウも蓄積。 標準化されたク エリ言語SQL キーと値を保存。 構造が単純なの で取得も更新も 高速にしやすい JSONやXMLなど 複雑な構造の データをそのまま 扱える ノードとエッジを 持つグラフをその まま扱える ・CPU/メモリの特 性を考慮したデー タ構造 ・高圧縮、高速 AWS RDS DynamoDB ElasticCache DynamoDB Elasticsearch Service Neptune Redshift 代表的な OSS NoSQL ≒ RDB以外のDB技術の総称 RDB
6. DynamoDBはいつ使うべき？ オリジナル： https://read.acloud.guru/why-amazon-dynamodb-isnt-for-everyone- and-how-to-decide-when-it-s-for-you-aefc52ea9476 小さいPJ/個人PJ 他のDBのキャッシュ などに使いたい マジです 大きなデータや Blobを保存する 詳しく サーバーレス アプリに使う はい KeyでValueを 引くだけで十分 いいえ 経験あり い い え は い はい はい いいえ はい いいえ いいえ 未 経 験 何するか 自覚してる？ Dynamo以外の 選択肢も考えて 複雑なクエ リが必要？ 数百万アイテム級、 数百GB級に なりそう？ Dynamoや NoSQLを 使った経験？ バックアップ やリストアは 必要？ アプリやバックエン ドを2～3回書き直す 覚悟はある？ DynamoのAPI の制約で監視 しにくいけど 大丈夫？ Dynamoは あなたの設計に ピッタリ！ 使うべき？ OK。小規模PJやプロ トタイプなら、もっ てこい RDB (Aurora) にしとけ 学習コスト高 いよ。他の DBにしたら? 今となっては当てはまらない部分もあるが、 慣れ親しんだRDBとは違うのでよく考えて 使いましょう
7. どこで使われてる？： 大規模・分散・サーバーレス 国内でも数百GB、数十億レコードでの事例もあり https://www.slideshare.net/KenNakanishi/amazon-dynamodb-37348630 来栖川電算でも使ってます
8. RDBとDynamoDBの基本用語 RDB DynamoDB テーブル テーブル プライマリキー：必須でない プライマリキー：必須 属性（Attribute）列＝カラムとも言う 属性（Attribute） レコード アイテム スキーマあり スキーマレス（スキーマなし） インデックス インデックス ・Global Secondary Index ・Local Secondary Index 実行計画 なし JOIN なし
9. アイテム構造 ①ドキュメント JSONやXMLのように階層構造や 配列や集合などが使える ②スキーマレス プライマリキー以外は、アイテムご とにバラバラになってもよい。 運用しながらスキーマを変えられる { "event_id": 12345678, "name": "JAWS-UG名古屋 DBまつり", "begins": "2018-10-17 19:00", "venue": "JPタワー", "geo": { "lat": 35.17111, "lon": 136.882416 }, "members": [ "kawaji", "kobayashi", "sugimoto", "mori", "tatsuno" ] } この例は分かりやすく一般的なJSONにし ています。実際のDynamoDBの構造はもう 少し複雑です。
10. プライマリキーとテーブルの構造 ①パーティションキーのみ ②パーティションキー＋レンジキー パーティションキーのハッシュ値で分割 パーティション＝物理的に別れたストレージ テーブル パーティションキーのハッシュ値で分割 テーブル 同じパーティションキーのものは レンジキーでソート済み パーティション内は特にソートされてない 同じパーティションキー の集まりはQueryが高速
11. 属性に使えるデータ型 分類 データ型 Java スカラー型 ただ1つの値 数値 10進38桁精度 すべての数値型 UTF-8文字列 1文字以上 String バイナリ base64文字列 ByteBufferなど 真偽値 Boolean/boolean Null null ドキュメント型 1つ以上の値 リスト List<T> マップ ユーザ定義型やMap<K,V> セット型 同じ型の1つ以上の値 数値セット Set<数値型> 文字列セット Set<String> バイナリセット Set<Byte> 日付：数値（unixtime）または 文字列（ISO-8601形式）として保存
12. DynamoDBアイテムの取り出し操作 GetItem Query Scan 取得対象 指定のハッシュキー（とレ ンジキー）を持つアイテム 指定のハッシュキー（とレ ンジキー）を持つアイテム のうち、条件に合うもの 全アイテムから条件にあう もの。RDBフルスキャン相当 取得数 1 0以上 0以上 インデックス 使われる 使われる 使われない A1 A2 A3 B1 B2 C1 C2 D1 E1 E2 GetItem Scan Query テーブル
13. DynamoDBアイテムの更新操作 PutItem UpdateItem 同じプライマリキーのアイテムが 存在しないとき 新規作成 新規作成 存在するとき 置き換え すべての属性の指定が必要。 指定してない属性は消える 差分更新 更新したい属性だけ指定。 指定してない属性はそのまま
14. DynamoDBでできないこと：トランザクション 分散DBを前提としてるので、複数レコードや複数テーブルにまたが る変更を1つの論理操作にできない。 代替手段 ▪ １レコード – 楽観ロック（Compare and Swap） ：取得時の更新日から変わってなけ れば更新 – 原始的アップデート（Atomic Counter） ：連番IDなど ▪ 複数レコード/テーブル – 更新操作をキューにためて、1つずつ処理していく 擬似的にトランザクションを実現するライブラリがあります（Java用AWS SDKのみ対応） https://github.com/awslabs/dynamodb-transactions
15. DynamoDBの フルマネージドな部分
16. DynamoDBでAWSにお任せできること ▪ ハードウェアの調達、構築 ▪ ストレージの容量管理（無制限！） ▪ DBソフトウェアのインストール、更新 ▪ 高可用性（同一リージョンで3AZに分散） ▪ 性能のスケールアウト ▪ 分散DBへのレプリケーション ▪ 2018年: バックアップ Dynamo固有の部分に ついて説明します
17. DynamoDBの性能 ▪ 「1秒間の性能＝キャパシティがどれだけ欲しい」をテー ブルごとに指定できます ▪ 必要なだけスケールアウトできます ▪ データの素性に基づいた「実行計画」がないので、予測 はしやすいです。 Read Capacity Unit 読み込みキャパシティ Write Capacity Unit 書き込みキャパシティ 1 CU の意味 最大4KBの1アイテムを 1秒あたり1回読める（強力な整合性） 1秒あたり2回読める（結果整合性） 最大1KBの項目を 1回書き込める 1 CU の料金 0.000148 US$/RCU 0.000742 US$/RCU 1 ヶ月の料金例 最大1KBで500RCU → $51.6 最大1KBで50WCU→$13.58
18. オートスケール ▪ 負荷に応じて、性能が足りなくなりそうなら、 自動でスケールアップ
19. DynamoDBの性能：コンソールやAPIで設定 注意：スケールダウンは1日4回まで
20. グローバルテーブル ▪ 複数リージョン（東京、北米、欧州…）にま たがった、論理的に1つのテーブルを作れる ▪ あるリージョンで書き込んだら、他のリー ジョンにレプリカされる ▪ あるリージョンがダウンしていても、他の リージョンを読込にできる
21. バックアップ ▪ 2018年の新機能 ▪ スケジュール または オンデマンド（随時） ▪ DB全体のスナップショットを保存し、いつで もリストアできる ▪ 差分更新なので比較的速い
22. その他の便利機能
23. Stream（変更の通知） ▪ アイテムに変更があったときに通知する仕組 – 作成/変更/削除 ▪ 通知をトリガーに、 Lambdaで処理できます – 例）別のDBやElasticsearchにレプリカ
24. 有効期限（TTL: Time-To-Live） ▪ アイテムに有効期限用の属性をもたせると、 期限が来たら自動で削除できる ▪ Streamと組み合わせると「古いコンテンツは 別の安いストレージに移動」など使える
25. 監視：CloudWatch Metrics ▪ 読込/書込のリクエスト回数 ▪ レイテンシ ▪ キャパシティの使用状況 ▪ スロットリング（キャパが足りず実行されな かった）の回数 ▪ などなど