DynamoDB で柔軟な検索をするためのテクニック

Amazon DynamoDBはマネージドサービスとして提供されているサーバーレスNoSQLデータベースであり、管理の手軽さや従量課金制のコストメリットの面から採用する事も多いかと思います。

ただその一方で検索機能においては、NoSQLのため柔軟な検索が苦手だったりデータ取得に制限があったりと、従来型RDBや全文検索エンジンと比べて設計面や運用面で注意すべき点が存在します。

今回は、DynamoDBで検索機能を設定する際に工夫すべきポイントについてご紹介します。

はじめに：パーティションキーとソートキー

DynamoDBでは、アイテムを検索するためのキー（プライマリキー）はパーティションキー（以下PK）とソートキー（以下SK）の2種類しか指定できません。PK単体のみ、もしくはPKとSKの組み合わせでデータが一意になるようにする必要があります。

データの格納場所（パーティション）を決める属性になります。

検索時にはPKは完全一致でのみ検索ができます。

パーティションの中でアイテムが並ぶ順番を決める属性で、SKを使用してパーティション内で検索を行うことができます。

begins_with、between、>、< などの演算子による範囲のクエリも使用可能ですので、PKと比べて扱いやすいキーになっています。

PKおよびSKにしか検索条件をかけられませんので、この2つのキーの選択がテーブル設計において重要になります。

先述の通り、PKとSKでしか検索キーとして指定できませんので、特にSKをいかに良い感じに選択できるかが鍵になります。

情報を効率的にクエリできるように、関連情報を収集して1か所にまとめるSK（= 複合SK）を選択するのが1つのテクニックです。

公式デベロッパーガイドにもSK設計のベストプラクティスとして、地理的場所を示すテーブルでの複合SKの構成例が載っています。

[country]#[region]#[state]#[county]#[city]#[neighborhood]

部分一致条件を指定可能なSKをこのような構成にする事で、 「SKが日本#大阪# で始まる」のように複合的な検索が実現可能となります！

グローバルセカンダリインデックス（以下GSI）は、データはそのままで、PKおよびSKを別の属性に変更することができます。

実際のテーブルとは別に、PKを変更し全く同じデータを持つもう1つの仮想テーブル（= 射影）を作るイメージです。

このGSIを検索条件毎だったりで用意してあげる事で、 「元テーブルのPKとSKのみでの検索」という制約に縛られる事なく柔軟かつ効率的に検索が可能となります。GSIはテーブル構築後に後から追加設定できるところも嬉しいポイントです！

ちなみに、GSIはデフォルトでスパースですので、指定したPKおよびSKの属性を含むベーステーブル内の項目だけが表示され、それ以外の部分は表示されません。この点もデータ量削減に繋がり効率的です！

今回は、DynamoDBで検索を行う際の工夫についてご紹介しました。

DynamoDBは検索面で色々と制約がありますが、メリットも十分大きいですので、採用する選択肢は全然アリな印象です。

データの形式や量によっても何を選択するのが正解かは変わってきますので、実際のユースケースに合わせた検討は必要になりますが、設計を工夫して要件に立ち向かってもらえたらと思います！