Amazon Redshift: 気付いたらクラスタの『カーソル数設定』の仕様が変わっていた件

小ネタです。

先日、Amazon Redshiftに於けるパラメータグループに関するドキュメントを読んでいたところ、以下の記述を見つけました。

※追記：当エントリで言及している内容は2015年07月に対応されたものである(2015/07/24:廃止されたパラメータ)、との御指摘を頂きました。ありがとうございます！

• ドキュメント履歴 - Amazon Redshift

max_cursor_result_set_size パラメータは廃止されました。カーソル結果セットのサイズの詳細については、Amazon Redshift Database Developer Guideの「カーソルの制約」を参照してください。

Amazon Redshift パラメータグループ デフォルトパラメーター値 - Amazon Redshift

Amazon Redshiftに於ける『カーソル』の扱いは、以前は以下エントリで言及しているような内容でした。パラメータグループの所定の項目値(max_cursor_result_set_size)を設定する事で『クラスタで使えるカーソルの最大値÷max_cursor_result_set_size=クラスタで使えるカーソル数』となり、このカーソル数がRedshiftにアクセスする際の上限数と関連していた形でした。(WLMに於ける同時実行レベルの上限=50を超えられない為、増やせたとしてもカーソルの最大値も50まで)

• Amazon Redshiftで扱う”カーソル”の設定について ｜ Developers.IO

max_cursor_result_set_sizeが廃止された事で、この部分がどのように変わったのでしょうか。実際に内容を確認して見たいと思います。

クラスタに於けるカーソルの結果セット容量

まずはクラスタに於けるカーソル利用の為の総容量について。この部分については既存仕様のまま(クラスタ規模によって扱える総容量が異なる)の様です。

• DECLARE - Amazon Redshift

クラスターのカーソル設定を表示(STV_CURSOR_CONFIGURATION)

ここが既存と変わって来ている部分となります。システム系テーブルのSTV_CURSOR_CONFIGURATIONで、現在利用しているクラスタの状況を表しています。

• STV_CURSOR_CONFIGURATION - Amazon Redshift

試しに何も(カーソルを)利用していない状態で試してみましょう。クラスタで使えるディスクスペース値(384000MB=384GB)は固定値で表示されていますが、その他の値はカーソル未使用の為0となっています。

# SELECT
    current_cursor_count,
    max_diskspace_usable,
    current_diskspace_used
  FROM
    STV_CURSOR_CONFIGURATION;
 current_cursor_count | max_diskspace_usable | current_diskspace_used 
----------------------+----------------------+------------------------
                    0 |               384000 |                      0
(1 row)

カーソルを使う様な処理をRedshiftに投げてみた上で、このテーブルに対しクエリを再度実行してみます。すると以下の様に状況が変わりました。9600MB=9.6GBのカーソルが1つ作成されています。

# SELECT
    current_cursor_count,
    max_diskspace_usable,
    current_diskspace_used
  FROM
    STV_CURSOR_CONFIGURATION;
 current_cursor_count | max_diskspace_usable | current_diskspace_used 
----------------------+----------------------+------------------------
                    1 |               374400 |                   9600
(1 row)

今度は同時にカーソルが発行されるように処理も並行して投げてみます。カウントと総使用量が変わりましたね。

# SELECT
    current_cursor_count,
    max_diskspace_usable,
    current_diskspace_used
  FROM
    STV_CURSOR_CONFIGURATION;
 current_cursor_count | max_diskspace_usable | current_diskspace_used 
----------------------+----------------------+------------------------
                    2 |               364800 |                  19200
(1 row)

アクティブなカーソルの情報を表示(STV_ACTIVE_CURSORS)

システム系テーブルのSTV_ACTIVE_CURSORSでは、このテーブルを参照した時点でのアクティブなカーソル情報が一覧として表示されます。上記の2カーソルが利用されている状態で情報を参照したものが以下となります。

• STV_ACTIVE_CURSORS - Amazon Redshift

# SELECT
   TRIM(userid) AS userid,
   TRIM(name) AS name,
   TRIM(xid) AS xid,
   TRIM(pid) AS pid,
   TRIM(starttime) AS starttime,
   TRIM(row_count) AS row_count,
   TRIM(byte_count) AS byte_count,
   TRIM(fetched_rows) AS fetch_rows
FROM
   STV_ACTIVE_CURSORS;
 userid |         name          |   xid   |  pid  |      starttime      | row_count | byte_count | fetch_rows 
--------+-----------------------+---------+-------+---------------------+-----------+------------+------------
 100    | sql_cur0x7feba275c790 | 3118044 | 11555 | 2016-01-06 12:31:42 | 195276    | 19918152   | 27503
 100    | sql_cur0x7fa63291f060 | 3118048 | 11556 | 2016-01-06 12:31:43 | 195276    | 19918152   | 15914
(2 rows)

変更点

上記の内容を踏まえると、クラスタに於けるカーソルの設定についてはRedshift側がよしなに制御してくれるのでユーザーが個別で設定する必要が無くなった、というのが変更点となるようです。仮に今回検証したサイズのカーソルがクラスタでの利用可能容量を超える数だけ作られた場合、384000/9600=40となり40個までは自動で作成されて行く、という形になると思われます。ちなみに今回検証したクラスタのサイズはdc1.large複数ノードだったためカーソル総容量容量が384GBでの計算でしたが、これがdc1.8xlargeであれば3000000MB(3TB)となり、3000000MB/9600MB=312.5となります。『300個もカーソル作れるの？』となりそうですが、WLMに於ける同時実行レベルの上限は50のままで変わりませんので、同時実行の上限は行ったとしても50まで、というのは変わらなさそうです。(※逆に言うと、この値を変更しておかないとデフォルト値=5のままとなりますので、同時実行数が6以上となる環境の場合であればまず最初にこの値を見直す必要があるかと思います。)

まとめ

以上、Amazon Redshiftに於けるカーソル(数)の設定が変更されていた件に関するご紹介でした。この辺りの設定を意識しなくて済むようになったのは嬉しいところですね。こちらからは以上です。