はじめに AWSのマネージドNoSQLであるDynamoDBについて調べたことをまとめてみました。 RDBMS暦が長いと、なかなかに難しいですね。 理論 キーの考え方 DynamoDBでレコード(Item)を一意に決定するプライマリキーには以下の2通りがあります。 パーティションキー パーティションキー＋ソートキー パーティションキーはハッシュキー、ソートキーはレンジキーと呼ばれていたりします。 パーティションキーといった方がしっくりきますね。 パーティションキーはその名の通り、パーティションを分割して保存されます。パーティションキーが異なるItemは独立性が高く、パーティションキーを横断した処理はDynamoDBは苦手とします。 一方、ソートキーは同じパーティション内で順序を含めて保存されます。 同一パーティションキー内のデータをユニークに決定する属性です。 例として某アイドルのテーブル

私が現在関わっているシステムの DynamoDB では現在、予想される最大負荷に十分に耐えられるキャパシティを設定しておけばいいだろうという設定が横行しています。 もちろん、システムのアクティブユーザー数や毎日の負荷状況などがわかっていればそれでよいのでしょうが、このシステムは Twitter キャンペーンと合わせて利用されることが多く、負荷状況はキャンペーンの内容などによって結構まちまちなので少し読みにくいです。 また、毎日〇〇時に高負荷状態になるといった感じではなく、稼働直後に最大負荷を迎えて以降はそれに比べるとかなり低い負荷で安定稼働という状況がよくあります。安定稼働を始めたらキャパシティを下げるなどの対応はしていますが、どうにも札束で殴っているような状況です。 というわけで、一度 DynamoDB の料金体系を理解して安定性は損なわず、よりお得に利用できる方法を探ってみたいところ。

DynamoDBには以下の単語が登場します。 パーティションキー ソートキー プライマリキー ローカルセカンダリインデックス グローバルセカンダリインデックス これらのキー・インデックスについて改めて整理してみました。 まず「パーティション」「データの読み書きを行うAPIの種類」について整理します。その後、キーの種類について整理します。 パーティション DynamoDBのデータは複数のパーティションに分散して保存されます。このときデータがどのパーティションに保存されるかは パーティションキー を元に決定されます。 また ソートキー が設定されている場合、データはパーティション内でソートキーを元に並べ替えられて物理的に近くに配置されます。 例として、AnimalType（パーティションキー）とName（ソートキー）で構成されるPetsテーブルのデータは以下のように分散して保存されます。 （図