DynamoDBがスケールしねーぞの話に関するメモ

You probably shouldn’t use DynamoDB https://t.co/Y8cOEDqgeq 10GB毎にノードが勝手に増えるので分散writeで速度激落ちのDynamoDB，実は全然スケールしないという．巨大データは素直にBigTableを使えと． pic.twitter.com/zh8CRImbz6

— Yuta Kashino (@yutakashino) 2017年7月8日

こういう話が流れてきたので元記事を読んでみたのだけど、そもそもDynamoDBの仕組みを把握してなかったので理解ができなかった。ということで、ざっと調べた結果を、自分（Cassandraをがっつり触ってた経験あり）が後から読んでわかればいいや程度のメモに。

DynamoDBとは

• オートスケールするDB
  • データはパーティションに分割されていて、パーティションはパーティションキーを元に特定する
  • パーティションとデータ分散 - Amazon DynamoDB
• ストレージ容量ではなくスループットで課金される
  • Read Capacity Unit (RCU)：1RCUで、1秒あたり最大2回のRead
    • Consistent Readオプションを使う場合、2倍のユニットを消費する
  • Write Capacity Unit (WCU):1WCUで、1秒あたり最大1回のWrite
• パーティションはデータサイズとスループット設定により自動で分割される
  • 1パーティションが10GBを超えるか、1パーティションに対し3000RCU/1000WCUを超えるスループット設定がなされた場合に分割
  • テーブルのベストプラクティス - Amazon DynamoDB

DynamoDBのスループット設定の考え方の注意点

このスライドを一回読むとよさそう。

(SDD407) Amazon DynamoDB: Data Modeling and Scaling Best Practices | AWS re:Invent 2014 from Amazon Web Services

www.slideshare.net

端的には、

100,000RCUを持っていたとしても、パーティションが50個あれば、1パーティションあたりのRCUは2,000となる。

で、パーティションキーを元にアクセスするパーティションを特定する性質上、以下ようなアクセスの偏りが生じるケースがある。

元記事の指摘ポイント

• 10GBで自動でパーティション分割してしまう。ユーザーサイドで制御不要。
• パーティション分割されると、1パーティションごとに割り当たるスループットが落ちてしまう。

言いたいことはわかるけど、DynamoDBの仕組み（課金の仕組み）を考えると、なかなか難しい問題。分散DBは難しい。