Lapis Lazuli

technical blog for web developer

【AWS】DynamoDBの仕組みを理解する

最近NoSQLであるDynamoDBを使用したので、そのとき学んだことをまとめていきたいと思います。

DynamoDBの仕組み

DynamoDBキーバリュー型のNoSQLになります。なのでキーを元にレコードの情報を引っ張ってくる形式になります。
比較的構造としてはシンプルなのですが、その分、RDSと同じような使い方をするには難しい部分もありますので注意が必要です。

まずDynamoDBにはパーティションキーとソートーキーという二種類のキーがあります。
パーティションキーはテーブルに必須で、いわゆるPKとして使うものです。
ソートーキーの方はオプションですが、パーティションキーとソートーキーを組み合わせてPKとするときに使用します。
あとの項目はレコード毎に自由です。書き込む際に型を指定して値を書き込んでいきます。

検索時にはパーティションキーの指定が必須になります。他の項目をキーにして検索はできません。
また、ソートーキーを設定している場合、ソートーキーのみの検索も不可能です。あくまでも補助的なキーという位置づけなので、基本的にパーティションキーとの組み合わせで使用します。
組み合わせる場合、セットでユニークキーになる形にしないといけないので、この辺りは扱うデータによっては注意する必要があります。(UUIDをキーにすると普通に衝突して大惨事になるw)

グローバルセカンダリーインデックス

とはいえ、これらのキーだけだと要件によっては不便な事もあると思います。
その時はグローバルセカンダリーインデックス(GSI)という機能を使うといいでしょう。
GSIは追加で設定できるインデックスで、自由に属性を選んでインデックスを貼ることができます。
GSIも通常のテーブルと同じくパーティションキーとソートーキーが設定できます。
と、ここまで書いて気がついたかもしれませんが、GSIは裏側でもう一つテーブルを使っている形になります。
作成するとき、元テーブルの情報をどこまで同期する(射影といわれます)かを設定できるのですが、全ての属性を射影すると単純に2倍のディスク容量を使う事になります。
キーのみか自分で属性を選択することもできるので、この辺りは上手く最適化していきたいものです。
キーのみにしてもう一度元テーブルをスキャンかけたら元も子もないですし。
あとはGSIは5つまでなので、RDSのように無作為にインデックスを貼るわけにはいきません。

ローカルセカンダリーインデックス

グローバルに対してローカルセカンダリーインデックス(LSI)というものも存在します。
これはパーティションキーが共通でソートーキーを独自に設定できるインデックスです。GSIが独立しているのに対して、テーブルに依存したキーになっているのでローカルと言うのでしょう。
LSIはソートーキーを追加して補完するときに使うのですが、GSIと違ってテーブルを作るときにしか設定できません。
後から追加できないので、イマイチ使い勝手が悪かったりします。作れる数はGSIと同じです。

R/WCUについて

Dynamoで最も特徴的なのはリード/ライトキャパシティの仕組みでしょうか。
読み書きのキャパシティ数を設定して、それによってパフォーマンスを変動させる事ができます。課金もプロビジョンタイプならキャパシティユニット単位ですので、柔軟に設定することができます。
25CUまでは無料だったりするので、低パフォーマンスで試すには安いコストで使用できるのがメリットですね。
ただ、サービスで検討するときには、大体RDSではカバーしきれない領域ができたときだと思うので、それなりにパフォーマンスを要求されるケースが多いと思いますが・・・


というふうに長くなりましたが、今回はDynamoDBに仕組みを説明しました。
実際に使うときのノウハウは次回にでも書きたいと思います。