『Amazon Redshift Result Caching』が Tableauなどカーソルを利用したクエリに対応しました

「カスタマーストーリー」を支えるツール特集

#Tableau

#Amazon Redshift

#AWS

石川覚

2018.02.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Amazon Redshiftのメンテナンスで適用される最新のクラスタバージョン1.0.1751で、カーソルクエリのクエリキャッシュに対応しました。2018/02/16にバージニアリージョンのメンテナンスで、クラスタバージョン1.0.1751にアップデートされたことが確認できました。先日のブログでは、キャッシュできなかったカーソルクエリのクエリキャッシュが有効になっているか、早速確認したいと思います。

Announcement: Amazon Redshift Maintenance (February 1st – February 22nd, 2018)

クエリ結果をキャッシュする新機能『Amazon Redshift Result Caching』を実際に試してみました

カーソルを利用したクエリによる検証

まずはpsqlからカーソルクエリを２回実行します。１回目のFETCHは 3257.633ミリ秒 (00:03.258)に対して、２回目のFETCHは259.987ミリ秒なので、キャッシュされていることが確認できました。

１回目

cmdb=> begin;
BEGIN
Time: 330.301 ms

cmdb=> declare lollapalooza cursor for
cmdb-> select count(*) from lineorder_cp where lo_orderkey%2 = 1;
DECLARE CURSOR
Time: 266.727 ms

cmdb=> fetch forward 5 from lollapalooza;
count
---------
5004490
(1 row)

Time: 3257.633 ms (00:03.258)

cmdb=> close lollapalooza;
CLOSE CURSOR
Time: 245.452 ms

cmdb=> commit;
COMMIT
Time: 227.669 ms

2回目

cmdb=> begin;
BEGIN
Time: 231.754 ms

cmdb=> declare lineorder_count cursor for
cmdb-> select count(*) from lineorder_cp where lo_orderkey%2 = 1;
DECLARE CURSOR
Time: 265.747 ms

cmdb=> fetch forward 5 from lineorder_count;
count
---------
5004490
(1 row)

Time: 259.987 ms

cmdb=> close lineorder_count;
CLOSE CURSOR
Time: 297.164 ms

cmdb=> commit;
COMMIT
Time: 227.562 ms

source_queryにクエリIDが設定されているのでキャッシュされていることが確認できます。１回目と２回目でカーソル名を変更していますが、カーソル名を変更してもキャッシュが有効になるようです。

userid | query | starttime | endtime | elapsed | substring | source_query
--------+---------+----------------------------+----------------------------+-----------+--------------------------------------------------------------+--------------
111 | 1979346 | 2018-02-17 17:19:24.640604 | 2018-02-17 17:19:24.640651 | 47 | fetch forward 5 from lineorder_count; | 1979335
111 | 1979335 | 2018-02-17 17:16:40.720733 | 2018-02-17 17:16:43.751426 | 3030693 | fetch forward 5 from lollapalooza; |

Tableau Desktop による検証

次は待望のTableauによる検証です。前回検証に利用したTableau のワークブックとバージョン（10.3.5）は同じもので再検証します。

Tableauは１つのビューを表示するために複数のクエリを実行します。２つのTableau Desktopから同時実行すると共にまだクエリキャッシュされていないので、クエリの結果が返るのに１分以上かかります。（赤で囲んだクエリのブロック）クエリビューのSQLがfetch 10000 in "SQL_CURxx";と表示されていることから、カーソルのクエリであることが確認できます。

これらのクエリ実行後にもう一度Tableau Desktopからクエリを実行すると、数百ミリ秒でクエリの結果が返ってくることが確認できます。（緑で囲んだクエリ）

クエリのキャッシュ状況を確認します。正確には、緑で囲んだクエリのブロックの内が２つのみがキャッシュされていました。

userid | query | starttime | endtime | elapsed | substring | source_query
--------+---------+----------------------------+----------------------------+-----------+--------------------------------------------------------------+--------------
111 | 1979270 | 2018-02-17 16:50:13.860474 | 2018-02-17 16:50:13.94237 | 81896 | fetch 10000 in "SQL_CUR6"; |
111 | 1979269 | 2018-02-17 16:50:12.010486 | 2018-02-17 16:50:12.250597 | 240111 | fetch 10000 in "SQL_CUR5"; |
111 | 1979268 | 2018-02-17 16:50:09.470273 | 2018-02-17 16:50:09.47153 | 1257 | fetch 10000 in "SQL_CUR4"; | 1979235
111 | 1979267 | 2018-02-17 16:50:07.620518 | 2018-02-17 16:50:07.633758 | 13240 | fetch 10000 in "SQL_CUR3"; |
111 | 1979266 | 2018-02-17 16:50:05.909919 | 2018-02-17 16:50:05.909965 | 46 | fetch 10000 in "SQL_CUR3"; | 1979232
111 | 1979265 | 2018-02-17 16:50:03.78037 | 2018-02-17 16:50:03.790461 | 10091 | Undoing 1 transactions on table 930468 with current xid 1601 |
111 | 1979263 | 2018-02-17 16:50:01.58051 | 2018-02-17 16:50:01.592935 | 12425 | fetch 10000 in "SQL_CUR3"; |
111 | 1979250 | 2018-02-17 16:47:45.591152 | 2018-02-17 16:48:05.21233 | 19621178 | fetch 10000 in "SQL_CUR5"; |
111 | 1979249 | 2018-02-17 16:47:44.980564 | 2018-02-17 16:48:04.650164 | 19669600 | fetch 10000 in "SQL_CUR6"; |
111 | 1979245 | 2018-02-17 16:47:09.380962 | 2018-02-17 16:47:44.127174 | 34746212 | fetch 10000 in "SQL_CUR4"; |
111 | 1979244 | 2018-02-17 16:47:09.250335 | 2018-02-17 16:47:43.525722 | 34275387 | fetch 10000 in "SQL_CUR5"; |
111 | 1979236 | 2018-02-17 16:45:55.05139 | 2018-02-17 16:46:50.583719 | 55532329 | fetch 10000 in "SQL_CUR4"; |
111 | 1979235 | 2018-02-17 16:45:54.845873 | 2018-02-17 16:47:06.603082 | 71757209 | fetch 10000 in "SQL_CUR4"; |
111 | 1979234 | 2018-02-17 16:45:53.481088 | 2018-02-17 16:45:53.500133 | 19045 | fetch 10000 in "SQL_CUR3"; |
111 | 1979233 | 2018-02-17 16:45:53.306055 | 2018-02-17 16:45:53.325288 | 19233 | fetch 10000 in "SQL_CUR3"; |
111 | 1979232 | 2018-02-17 16:45:51.671135 | 2018-02-17 16:46:45.542399 | 53871264 | fetch 10000 in "SQL_CUR3"; |
111 | 1979231 | 2018-02-17 16:45:51.550456 | 2018-02-17 16:47:06.605614 | 75055158 | fetch 10000 in "SQL_CUR3"; |
111 | 1979230 | 2018-02-17 16:45:47.017257 | 2018-02-17 16:45:49.478176 | 2460919 | Undoing 1 transactions on table 930466 with current xid 1601 |
111 | 1979229 | 2018-02-17 16:45:47.012191 | 2018-02-17 16:45:49.478969 | 2466778 | Undoing 1 transactions on table 930464 with current xid 1601 |
111 | 1979228 | 2018-02-17 16:45:45.010532 | 2018-02-17 16:45:45.022491 | 11959 | fetch 10000 in "SQL_CUR3"; |
111 | 1979227 | 2018-02-17 16:45:41.710555 | 2018-02-17 16:45:44.9669 | 3256345 | fetch 10000 in "SQL_CUR3"; |

最後に

全てのTableauユーザーは、クラスタのメンテナンスが適用されたら直ちにこのクエリキャッシュの恩恵が得られるはずです。Tableauのベストプラクティスに準じた結果セットが大きすぎないクエリであれば、このアップデートのパフォーマンス向上を体感できるはずです。数週間以内に東京リージョンへ適用されると思いますので、Tableauはユーザーの皆さんは楽しみにお待ち下さい。