AWS DynamoDB

wiki, tech, tech
Page content

DynamoDB

RDB vs. DynamoDB

コンセプトから学ぶAmazon DynamoDB【Amazon RDSとの比較篇】

  • RDB の ACID: データベースが持つ強い整合性を伴う特徴を、ACID（Atomicity, Consistency, Isolation, Durability）特性という。

    • consistency: どこからアクセスしても同じデータが観測できること
    • Atomicity: 一連の操作を全て適用commitするか全てキャンセルrollbackするかの二択として実現できること

  • RDB の検索性: where 句などによる検索性の高さ

  • RDB の可用性: Multi-AZの構成にしたとしても、稀に何らかの障害等により、MasterからSlaveへのフェイルオーバーが発生することがあり、この処理を行っている数分間は、可用性が損なわれる。また、障害以外にもセキュリティパッチの適用等の目的で、メンテナンスウィンドウにおける再起動が起こることがあります。つまり、RDSにおいてはサービスレベルの設計時点でメンテナンスウィンドウにおいて可用性が損なわれることは織り込み済みの事象と言えます。

  • RDB の拡張性: RDSはスケールアップのみをサポート。つまり、インスタンスタイプの変更です。規模の拡大に伴ってスケールアップを繰り返すと、すぐに限界が訪れてしまう可能性があります。読み込みだけに絞れば、Read replicaによるスケールアウトに対応しますが、レプリカをぶら下げられる数にも一定の制限があり、比較的天井が低いかも知れない

  • DynamoDB, NoSQL の BASE: Basically Available, Soft state, Eventually consistent

    • Basically Available: 可用性低下は想定せず、基本的にいつでも利用可能
    • Eventually consistent: データを更新した瞬間、複数ノードに分散している場合は一時的に返す値がばらつく（更新前のものと更新後のもの）が、最後には一緒になる（DynamoDB では 1秒 以内だとのこと）

  • DynamoDB の検索性: 予め決めた 1つの primary key と 5つの secondary index で検索する以外は、全走査になるため性能が落ちる

  • 複合キーを使うには: 1つをハッシュキーとして、もう一つをレンジキーとして指定すると良いらしい. 参考

DynamoDB のオートスケーリングとスロットリング

DynamoDB on-demand について

2018年11月の re:Invent にて、 Amazon DynamoDB On-Demand のリリースが案内されました。

  • 従来: provisioned mode, 今回: on-demand mode
  • 事前のキャパシティプランニングが一切不要、リクエスト分だけ応答でき、使った量に応じて課金

自分の用途に合うか？今のところ不要に思うんだけど、理由は以下：

  • 理由1. このグラフほどスパイキーなトラフィックは通常発生しない ddb-on-demand-image

  • 理由2. 平常時のトラフィック特性に対して割高。

  • 理由3. スパイクすると今のprovisionedだと捌ききれないけど、限られた場合な気がするのと、オートスケールすれば一過性。

    • そして溢れた時それが実際にどれくらい影響あるか、食らってみないとわからない ≒ 食らってからon-demand検討すればよくね？って舐めた考えしている（実感を持ってon-demandにしたいとも言う）

DynamoDB Global Table

DynamoDB の消費キャパシティをちゃんとグラフ化する

普通に既存のメトリックを選んでいじっても出来なくて、 Metric Math を取り入れて自分で計算しないといけない。 (詳細は https://www.georgeorge.com/blog/article/tech/aws-cloudwatch.html を参照。)

疑問: なんでこんなに需要がありそうなメトリックが提供されていないの？？？