DynamoDBを調べたメモ

DynamoDB 使ったほうがいいんじゃない！？！？という話になったので、調べたメモ。まじでメモ。

+ 金額感
    + ストレージ利用料 + キャパシティユニットと呼ばれる処理単位 + リクエスト数
    + キャパシティユニット
        + 書き込みの制約
            + 1つの書き込みキャパシティユニットで秒間1回書き込める
            + 1つのキャパシティユニットで1KBまで
        + 読み込みの制約
            + 1つの読み込みキャパシティユニットで秒間2回読み込める
            + 1つのキャパシティユニットで4KBまで
        + これを消費する量をスループットと呼んでいる
            + Dynamoを使っている上でスループットが上がらない、はキャパシティユニットを上げればいい
        + 読み書きそれぞれ別の値を設定できる
        + オートスケールも可能。70%をしきい値に増やしたり減らしたりできる
        + この制約があるので一括でドッバー！みたいなことができない
    + キャパシティユニットの課金が厳しいのでがっつりDBストアというよりは、無限にスケールできるKVSのイメージ
+ ストレージ
    + 縦にも横にも自動でめっちゃ伸びる
    + 実態はSSD。ソフトウェア的なものはAWS独自？まあ気にしなくて良い領域
+ インデックスの設定が必要
    + なぜ必要？
        + 無限にスケールが出来る、一方でどうやってデータを検索するの？
        + 高速に検索するために、データに対して、一意に絞りこめるようなキーを設定してあげる必要がある
    + どんなインデックスがある？
        + プライマリ
            + HashKey or HashKey + RangeKey
            + 一意に絞りこめるキーと値の幅のインデックスが設定できる
        + LSI
            + ローカルなセカンダリインデックス
            + HashKey + RangeKey のときだけ使える
            + 別のRangeKeyを増やすイメージ
        + GSI
            + グローバルなセカンダリインデックス
            + プライマリキーはそれとして、別のインデックスを設定できる
        + セカンダリインデックスを設定するときのオプションで金額が変わる
            + 「射影しなかった属性データはインデックスでのクエリ結果に含まれない」っぽい
                + もし射影してない属性データが欲しい場合は改めてテーブル側から取得する必要があり
                + その分余計なユニットを消費してしまうので逆にコストが高くなることも
    + HasKeyは分散させないとスループットが出ない
        + ストレージがいい感じに分散されるため
        + 単に日付をべべっとしたデータを入れると分散されない
+ 整合性
    + 2つある
    + つよい
        + つよい。ちゃんと整合性を見てくれる
        + スループットを倍消費する
    + ふつう
        + ふつう。書き込みは同期じゃなくてちょい遅延がある
        + スループットは通常（1キャパシティユニットで秒間2回読み込める）
+ データバックアップ
    + 勝手に分散保存されるので不要（S3といっしょ）
    + バックアップしようとするとキャパシティユニットがつらい
+ RDS, Dynamo, S3 を比べてみる
    + RDS
        + スケール
            + スケールアップ、縦横分割は自分でやる
        + スピード
            + インデックスが効けば早い
            + データ量が増えるとつらい
                + 日ごとにめちゃめちゃ増えるデータに対しては難しい
            + Auroraで多少改善できるかも？
        + 検索
            + わりかし柔軟に検索できる
        + 一貫性
            + ◎トランザクション
        + その他
            + 要するにMySQLなので理解が容易
    + Dynamo
        + スケール
            + 無限にスケール出来る、縦横分割を考えなくていい
        + スピード
            + 強制的にインデックスが効くので早い
            + DAXというオプションで加速できる
        + 検索
            + インデックスに基づく簡単な検索は出来る
            + テーブルをくっつけるような複雑目なものは無理
                + ElasticSearchと連携して最高の検索ソリューションを提供できる
        + 一貫性
            + トランザクションはない
        + その他
            + キャパシティユニットを超えるとエラーになるのでスパイク対応が難しい？
                + オートスケール＋ライブラリがリトライ対応してると最高
    + S3
        + スケール
            + 無限にスケール
        + スピード
            + 他と比べると遅め
            + おそすぎてやばい！というほどではなく、耐えられるくらいの遅さ
        + 検索
            + 検索することはできない、一意に絞りこめるキーを決める必要がある
            + ElasticSearchにまるっと放り込んで検索することもできるっちゃ出来る
        + 一貫性
            + トランザクションはない
        + その他
            + 要するにファイルストレージ
            + 保存コストは一番安いが、取り出しコストは大きめ？
+ 余談
    + GoogleAnalyticsはBigTableがバックエンド

勉強した色々な記事

• gist:6006745
• Amazon DynamoDBの紹介と東急ハンズでの活用について
• ビッグデータだけじゃない Amazon DynamoDBの活用事例
• DynamoDBについて今更調べたのでメモ | 株式会社ランチェスター
• AWS上のデータベースサービスが沢山あってよくわからないので、整理してまとめてみた - Qiita
• 何が違う？DynamoDBとRDS – サーバーワークスエンジニアブログ
• DynamoDBのメモ書き＋使ってみた雑感 - アルパカDiary Pro
• コンセプトから学ぶAmazon DynamoDB【Amazon RDSとの比較篇】 ｜ Developers.IO
• RDS(RDBMS)とDynamoDB(NoSQL)の使い分けについて - keiwt’s diary