DynamoDBのGSIとLSI、「どのキーを変えるか」で整理したらスッキリした

おはようございます、YASUです。

以前、DynamoDBのQueryとScanの違いを整理しましたが、DVAの模擬試験ではその先の「インデックス」「キャパシティ」「キャッシュ」まで問われます。ここがまたややこしかったので、今日はシンプルに3つだけ整理します。

結論

覚えるのは3つだけでした。インデックスは「どのキーを変えるか」でGSIかLSIかが決まる。キャパシティは「アクセスが読めるか」でオンデマンドかプロビジョニングかが決まる。DAXは「読み取りが多い」ときだけ効く。この3つの判断軸で、迷いが一気に減りました。

そもそもインデックスは何のためにあるのか

DynamoDBのQueryは、パーティションキー(必要ならソートキーも)を指定して取得する仕組みでした。ということは、キーに入っていない属性で検索したくなった時、Scanに頼るしかなくなります。そこで「別の切り口の索引」を追加するのがセカンダリインデックスです。種類はGSIとLSIの2つあります。

GSIとLSI、たった1つの質問で決まる

最初は違いがごちゃごちゃして覚えられませんでしたが、「どのキーを変えるのか」という1つの質問で整理できました。

パーティションキーを変えたい       → GSI
パーティションキーは同じで、ソートキーだけ変えたい → LSI

具体例で考えると分かりやすかったです。注文テーブルが「ユーザーID(パーティションキー)×注文日時(ソートキー)」で作られているとします。

• 「ユーザーごとの注文を、金額順に並べたい」→ ユーザーIDはそのままで並び順だけ変えたいので、LSI
• 「ある商品を買ったユーザーを探したい」→ 商品IDという、まったく別の軸で検索したいので、GSI

GSIとLSI、試験で問われる違い

制約が多いLSIは使いにくく、実務ではGSIが選ばれることが多いそうです。ただし試験では「作成後に追加したい」「強い整合性で読みたい」といった条件から、どちらを選ぶかが問われやすい印象でした。

見落としがちな落とし穴

調べていて驚いたのが、プロビジョニングモードで、GSIのキャパシティが足りないと、ベーステーブルへの書き込みまでスロットリング(流量制限)されてしまうという点です。索引を足しただけなのに本体の書き込みが詰まる、というのは、実務でも模擬試験でもひっかけになりそうです。

キャパシティモード:アクセスが読めるかどうか

DynamoDBには、読み書きの量を管理する2つのモードがあります。

判断軸はシンプルで、「アクセスが読めないならオンデマンド、読めるならプロビジョニング」です。最初はオンデマンドで始めて、アクセスの傾向が見えてきたらプロビジョニングに切り替える、という進め方もできるとされています(ただし切り替えには、前回の変更から一定時間あける必要があります)。

DAX:DynamoDB専用の「キャッシュ置き場」

最後がDAX(DynamoDB Accelerator)です。DynamoDBの前に置くインメモリキャッシュで、よく読まれるデータをメモリに持っておくことで、読み取りの応答時間をミリ秒からマイクロ秒に縮められます。DynamoDB互換のAPIで動くので、既存のアプリのコードをほとんど変えずに導入できる点も特徴です。

ただし、何でも速くなるわけではありません。ここが試験で狙われそうなポイントでした。

「DynamoDB専用のキャッシュ」と覚えておけば、「読み取り性能を上げたい」という要件が出てきた時にDAXを思い出せそうです。

まとめ

前回のQuery/Scanの話と合わせて、DynamoDBの全体像がだいぶ繋がってきました。次の模擬試験で、ここがどう変わるか楽しみです。それでは、また明日!