[アップデート] Amazon QuickSight のデータセットでユニークキーが設定出来るようになったので挙動を検証してみた

[アップデート] Amazon QuickSight のデータセットでユニークキーが設定出来るようになったので挙動を検証してみた

Clock Icon2024.12.21

いわさです。

先日の Amazon QuickSight のアップデートでデータセットにユニークキーが設定出来るようになりました。

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-quicksight-unique-key-dataset/

QuickSight ユーザーからすると素通り出来なさそうな非常に気になる機能ですが、結論から言うとイメージしていたユニークキーとは違いました。
ただ、従来はテーブルビジュアルをレンダリングする際に余計な内部処理が走っていたのですが、ユニークキーを設定してやることでそのあたりの無駄な処理をスキップしてレンダリングパフォーマンスが向上する可能性があります。
AWS のアナウンスによると最大 60% 短縮されるとのこと。本当か?

本日はユニークキーを設定したデータセットと設定していないデータセットの挙動を比較してみました。
大規模なデータセットを用意して最初試したところ、ユニークキーを設定しても読み込みがなかなか終わらずでパフォーマンス比較までは出来なかったのですが、ユニークキーを設定した場合にドキュメントに記載されている挙動を確かにしており、パフォーマンス改善の可能性は確認出来ました。

ユニークキーの設定方法

ユニークキーですが、データセットの編集画面で設定することが出来ます。
次のようにフィールドのコンテキストメニューから「Set as unique key」を選択します。

1D88AB1C-1909-4F5E-B4DF-A0F3CE808094.png

ユニークキーとして指定されたフィールドは次のように鍵マークのアイコンが付与されます。

40E35E67-49B6-44BC-8B4D-E01EC70DBF79.png

ただし、この時点ではまだ指定だけされた状態で、データセットの保存まで行うことで分析やダッシュボードに反映されます。保存を忘れないように気をつけましょう。

86AFF0CF-52D5-4738-933C-B51EEA404FD5.png

ユニークキーを指定出来るフィールドはひとつまでです。複合ユニークキーの設定は出来ません。
ユニークキー設定済みの場合は次のように「Set as unique key」が非活性になります。

8E01BE12-1312-43E7-87AE-0379C06FF666.png

ユニークキーを別のものに付け替えたい場合は既存ユニークキーフィールドから「Remove as unique key」を実行しましょう。

B0ADCCDF-BC83-4409-A4F1-969047E77298_4_5005_c.jpeg

ユニークキーの仕様

QuickSight のユニークキーフィールドについて次のドキュメントが追加されています。
でこのユニークキーですが、どうやらレコード識別を行うためのものではないです。そのためか、値重複が存在するフィールドに対してユニークキーも設定可能で一意制約違反も起きません。

https://docs.aws.amazon.com/quicksight/latest/user/set-unique-key.html

この機能の最大の目的ですが、「テーブルビジュアルを使った場合にユニークキーフィールド以降はソートフィールドとして無視する」という点にあります。
これまで、テーブルビジュアルではフィールドウェルに追加されている順で全フィールドがソートされるのが既定の動作でした。知らなかったのですが、上記仕様によってソートが不要なフィールドについてもソート処理が発生し、レンダリングが完了するまで余計な時間がかかっていたそうです。
ユニークキーを指定してやることにより、そのユニークキーで指定された後はソートする必要がないフィールドとして判断されるようです。これによってパフォーマンスが向上するみたいですね。

例えば、以下の場合でc1がユニークキーだった場合、まず c2 でソートされ、続いてc1でソートされます。
従来であれば続いてc3でソートされるのですが、c1がユニークキーなのでこれ以上のソートは不要だろうということで、c3v1v2でのソートは行われません。なるほど。

647AEE01-EB64-4952-8083-BCFDC6377840.png

フィルターを使った場合の取得が早くなるようなインデックス的な挙動を目的としているのかなと最初思ったのですが違いました。

ユニークキーを設定して試してみる

ちょっと簡単な実験をしてみました。

幸いにも(?)ユニークキーフィールドの中で値の重複が許可されています。
なので、次のようなデータセットを用意してみました。c1がユニークキーなのですが、ユニークキーの中で値が重複しています。
続けてc2c3フィールドも存在しますので、これらの複数フィールドがどうソート順に影響するの確認してみましょう。

F3E45D2F-CA38-444F-BB8F-C4A0DCC790FC.png

上のビジュアルがユニークキー設定ありのデータセット、下のビジュアルがユニークキー設定なしのデータセットです。
ユニークキーありの場合だと、c1のみでソートされた後、c2c3でソートされていないことがわかります。
一方でユニークキーなしの場合は、c2c3でもソートされていることがわかります。
ドキュメントに記載のとおり、ユニークキーより右側のフィールドではソートされていないことがわかります。

F633BA39-03DB-4978-A990-6D64DFCAC709.png

続いて、ユニークキーの左にフィールドが存在する場合はどうなるでしょうか。
この場合ですが、これはユニークキーより左のフィールドはソート考慮されています。
c2でソートされた後にその中でc1でソートされていることがわかりますね。c3ではソートされていません。

816DD58B-9CBB-4860-BA11-1BC51756A390.png

さいごに

本日は Amazon QuickSight のデータセットでユニークキーが設定出来るようになったので挙動を検証してみました。

思っていたユニークキーと少し違ったのですが、テーブルビジュアルは最大 200 フィールドまで表示が可能なので、追加した全フィールドでソートされる倍は確かに無駄なソート処理でパフォーマンス劣化があったのかもしれません。
横に長いテーブルビジュアルを使われている方は今回のユニークキー機能を試してみると良さそうですね。

上記のようなピンポイントのユースケースで効果が出るもので、少なくとも今までのデータセット設計から変わるようなものでは無さそうかなという感じです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.