GSI OVERLOADING について 自分なりにまとめてみた

みなさま Xin Chao.

ある日、お客様より DynamoDB に関するお問い合わせを受け、いろいろ調べてみたところ、あまりに情報がなかったので驚いたことがあります。 それは...

DynamoDB の GSI (グローバルセカンダリインデックス) OVERLOADING とは？ です。

GSI OVERLOADING は、「GSI 多重定義」や「GSI オーバーロード」 と表記される場合もあります。

備忘録を兼ね、自分で理解した内容を事例も交え、書き残しておこうと思います。

GSI OVERLOADING とは

「AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern」 を見ると、以下のように説明されています。

スライドの説明はその後も続きますが、そもそも自分は勉強不足ということもあり、1 度読んだだけでは概念が理解できませんでした...。

自分の理解

RDBMS でのテーブルの例

例えば RDBMS (リレーショナルデータベース) で、以下のようなテーブルがあるとします。 みなさんにはあまり馴染みがないかもしれませんが、自分の興味か続くよう F1 ネタを例にしてみました。

RDBMS では、プライマリキーとなっている「カーナンバー」はもちろんのこと、インデックスを作成することにより「ドライバー名」や「国籍」「チーム」「初優勝年」を検索キーとして、検索することが可能です。

DynamoDB に そのまま作成した場合

RDBMS のテーブルを、そのまま DynamoDB に作成すると、以下のようになります。

DynamoDB の場合、パーティションキー または パーティションキー＋ソートキー を検索キーとした場合のみ、検索が可能です。 したがって、このテーブルでは、「カーナンバー」を検索キーとして検索することしかできません。

「ドライバー名」で検索するには、以下のような GSI を定義する必要があります。

さらに、「国籍」で検索するには、以下のような GSI も必要になります。

さらに、さらに、「チーム」で検索するには、以下のような GSI も必要になります。

さらに、さらに、さらに、「初優勝年」で検索するには、以下のような GSI も必要になります。

今回の例では、以上 4 つの GSI で済みましたが、より多くのカラムを持ったテーブルの場合、GSI の制限 (1 テーブルあたり 20 GSI の初期制限, 申請により緩和可能) を意識する必要があります。

また、各 GSI にはキャパシティユニットを割り当てる必要があるため、コスト的な面も気になります。

DynamoDB で GSI OVERLOADING を意識して作成した場合

GSI OVERLOADING を意識して RDBMS のテーブルを DynamDB に作成すると、以下のようになります。

横に並んでいた各カラムの内容を、1 つの「カラムA」内に縦に並べるイメージです。

この時点ではカーナンバー (＋カラムA の内容) を検索キーとして検索できるだけです。

そこで、以下のような GSI を定義します。

すると、テーブルのプライマリパーティションキー＋プライマリソートキー, GSI のパーティションキー＋ソートキー を使って、以下のような検索を行うことができます。

GSI を 1 つ定義しただけで「ドライバー名」「国籍」「チーム」「初優勝年」を検索キーとした検索を行うことが可能になりました。

まとめ

テーブル構造を工夫することにより、1 つの GSI で複数の検索要件を満たすことができる、というのが GSI OVERLOADING であると理解したつもりです。

テーブル構成が複雑になってしまうデメリットもありますが、テーブルあたりの GSI 数制限や、検索キーに応じて GSI を増やさなければならないといったことを回避できるというメリットがあります。

なお、GSI とは何ぞや？ LSI (ローカルセカンダリインデックス) というものもあったよな？ という方は、以下のブログが参考になりますのでご参照ください。

コンセプトから学ぶAmazon DynamoDB【GSI篇】

コンセプトから学ぶAmazon DynamoDB【LSI篇】