DynamoDBのファセットを解説😎ファセットを使いこなしてしてDynamoDB設計の上級者へ!

DynamoDBのファセットを解説😎ファセットを使いこなしてしてDynamoDB設計の上級者へ!

こんにちは!

最近では、AWS 社の NoSQLWorkBench を使用した DynamoDB 設計案件が増えてきました。

お客様のビジネスの要件定義をもとにデータモデリングを行う際、Swagger のようにコード上でデータアクセス定義ができたらなぁ…という思想から採用しました。(スプレッドシートの管理に限界を感じました…)

NoSQLWorkBench をまだ使用されていない方は、是非一度ダウンロードして使ってみてください!

本記事では、NoSQLWorkBench の設計項目に存在する「ファセット」について解説をしていきます。

想定する読者

  • DynamoDB を使用してプロダクト開発を行っているヒト
  • DynamoDB のアーキテクチャーを行っているヒト
  • DynamoDB を使用したチーム開発に悩んでいるヒト

はじめに

ファセットは DynamoDB の機能ではありません

ファセットは、GSI、LSIのようなDynamoDBの機能ではありません。後述で詳しく解説していきます。

ファセットは DynamoDB テーブルのアクセスパターンを定義します

 例えば、EC サイトのユーザーの商品お気に入り情報を保持するテーブル構造を考えてみましょう。

CustomerFavorite テーブル

# item
{
  customerId: '0001', // PK
  sk:'xxxxxx', // SK
  customerName: '田中太郎',
  email: 'yamada@example.com',
  productUrl: 'https://example.com/product01',
  description: 'ナイスな商品です。',
  updatedAt: '2020-09-01',
  createdAt: '2020-09-01',
}

ご覧の通り、この CustomerFavorite テーブルでは顧客情報と顧客のお気に入り情報を格納しています。

ここで肝心なのは、DynamoDB はプライマリーキー以外はスキーマレスです。

そのため、CustomerFavorite テーブルからデータ取得する際に、どれがユーザーの情報なのか、どれが商品情報なのか識別するのが、開発がスケールするにつれて辛くなります。

ここで登場するのがファセットです。

CustomerFavorite テーブルのファセットを考えてみる

CustomerFavorite テーブルに格納されている情報は、 2 つの分類に分けることができます。

  • 顧客情報
  • お気に入り情報

どの属性値が、どの分類に当てはまるのか。それを定義するのがファセットです。あくまでも定義だけで、機能面でアクセス可能になるようなものではありません。

Customer ファセット

AttributesAliasAttributesNameKey type
customerIdcustomerIdPK
typeskSK
{
  customerId: '0001', 
  type: 'xxxxxx', 
  customerName: '田中太郎',
  email: 'yamada@example.com',
}

Favorite ファセット

AttributesAliasAttributesNameKey type
customerIdcustomerIdPK
productUrlskSK
{
  customerId: '0001', 
  productUrl:'xxxxxx', 
  description: 'ナイスな商品です。',
  updatedAt: '2020-09-01',
  createdAt: '2020-09-01',
}

1 つの属性が項目によって複数の意味を持つ場合をオーバーローディングと言います

CustomerFavorite テーブルのソートキー sk は、顧客情報の場合は type を格納し、お気に入りの場合は url を格納します。

つまり、保持する値によって、Item の意味が異なることになります。 このように一つの属性の値によって、複数の意味を持つ設計を属性のオーバーロードといいます。 今回の例では sk がオーバーロードされた属性です。

一つの属性 sk が項目ごとに異なる意味を持つ状況では、テーブルのデータを一覧するだけでは何が格納されているのかを読み取るのが難しくなります。 この状況を改善するのがファセットですね。

開発が進んでいけば、今回の sk のようなオーバーローディングテクニックを使用したテーブルもいくつか発生することがあるので、ファセットは確実に設計するようにしましょう。( 特にわたしたちのような SIer 企業のクライアントワークでは、はじめに要件がかっちり固まっていないことが多いです )

設計情報に正しくファセットを含めることで、開発がスケールしてもチーム開発がしやすくなります。

TIPS

まとめ

開発が進むに連れて DynamoDB は、テーブルがどんな情報を格納しているのかを識別するのがだんだんと複雑になってきます。

設計者は、テーブルにどのような情報が格納されているのか視覚的に判断できるよう、設計の際には必ずファセットを使用しましょう。尚、当然ですが NoSQLWorkBench はファセットの設計に対応していますので、使えるに越したことはないでしょう。

DynamoDB の設計・開発は、お気軽にご相談ください。