Amazon Redshiftの新しいインスタンスタイプ「DS」を試してみた
はじめに
先日、新しい高密度ストレージノード ds2.xlargeとds2.8xlargeの2つのサイズが提供されましたが、価格は据え置きで、vCPU、ECU、メモリ（GiB）、IOが倍ぐらい向上しています。ざっくり倍くらいの性能向上が見られるのではと予想していますが、実際にどれ位の性能向上が見られるか試してみたいと思います。また、移行方法やオトクな情報についてもご紹介いたします。
スペックの新旧比較DS
ds1.xlarge と ds2.xlarge
| vCPU | ECU | メモリ（GiB） | ストレージ | I/O(GB/s) | Network | 価格 | |
|---|---|---|---|---|---|---|---|
| ds1.xlarge (dw1.xlarge) | 2 | 4.4 | 15 | 2TB HDD | 0.3 | Moderate | $1.190/1時間 |
| ds2.xlarge | 4 | 14 | 31 | 2TB HDD | 0.5 | Enhanced | $1.190 /1 時間 |
| 改善点 | 2倍 | 3倍 | 2倍 | ー | 2倍 | 拡張ネットワーキング | ー |
dw1.8xlarge と ds2.8xlarge
| vCPU | ECU | メモリ（GiB） | ストレージ | I/O(GB/s) | Network | 価格 | |
|---|---|---|---|---|---|---|---|
| ds1.8xlarge (dw1.8xlarge) | 16 | 35 | 120 | 16TB HDD | 2.40GB/s | 10 Gbps | $9.520/1時間 |
| ds2.8xlarge | 36 | 116 | 244 | 16TB HDD | 4.00GB/s | Enhanced – 10 Gbps | $9.520 /1 時間 |
| 改善点 | 2倍 | 3倍 | 2倍 | ー | 2倍 | 拡張ネットワーキング – 10 Gbps | ー |
性能検証 - ds1.xlarge vs ds2.xlarge
パフォーマンスの計測条件
- クエリ性能検証 リージョン：東京リージョン（ap-northeast-1）
- クラスタ：ds1.xlarge と ds2.xlarge ともに single node
- データ：AWSが提供しているサンプルデータ（s3://awssampledbapnortheast1/ssbgz/lineorder0000_part_00.gz）
- レコード数：7500万レコード
- テーブル：lineorder
CREATE TABLE lineorder ( lo_orderkey INTEGER NOT NULL, lo_linenumber INTEGER NOT NULL, lo_custkey INTEGER NOT NULL, lo_partkey INTEGER NOT NULL, lo_suppkey INTEGER NOT NULL, lo_orderdate INTEGER NOT NULL, lo_orderpriority VARCHAR(15) NOT NULL, lo_shippriority VARCHAR(1) NOT NULL, lo_quantity INTEGER NOT NULL, lo_extendedprice INTEGER NOT NULL, lo_ordertotalprice INTEGER NOT NULL, lo_discount INTEGER NOT NULL, lo_revenue INTEGER NOT NULL, lo_supplycost INTEGER NOT NULL, lo_tax INTEGER NOT NULL, lo_commitdate INTEGER NOT NULL, lo_shipmode VARCHAR(10) NOT NULL ) distkey(lo_orderkey) sortkey(lo_orderdate, lo_custkey);
データロード時間の計測
まずは他のデータソースからRedshiftにデータをロード（COPYコマンド）する時間を計測します。以下の処理ではデータのロード、VACUUM、ANALYZEが内部的に実行されます。
ds1.xlarge
COPY lineorder FROM 's3://awssampledbapnortheast1/ssbgz/lineorder0000_part_00.gz' CREDENTIALS 'aws_access_key_id=xxx;aws_secret_access_key=yyy;token=ccc' GZIP; INFO: Load into table 'lineorder' completed, 75004738 record(s) loaded successfully. COPY 時間: 650482.375 ms
ds2.xlarge
COPY lineorder FROM 's3://awssampledbapnortheast1/ssbgz/lineorder0000_part_00.gz' CREDENTIALS 'aws_access_key_id=xxx;aws_secret_access_key=yyy;token=ccc' GZIP; INFO: Load into table 'lineorder' completed, 75004738 record(s) loaded successfully. COPY 時間: 269101.802 ms
一数行インサート・複数行インサート時間の計測
Redshiftでは、空のテーブルに対して INSERT INTO ... SELECT でデータを投入するとソート済みデータとして投入できますが、後ほどVACUUM時間を計測したいので、ソート状態にならないように事前に１レコード投入しているところがポイントです。
ds1.xlarge
-- 一行インサート時間 - 100%非ソート状態とするため先頭にわざと１レコード追加 INSERT INTO lineorder_cp VALUES(1,1,1,1,1,1,'9','8',1,1,1,1,1,1,1,1,'7'); INSERT 0 1 時間: 1867.643 ms -- 複数行インサート時間 - 7500万レコードをコピー INSERT INTO lineorder_cp SELECT * FROM lineorder; INSERT 0 75004738 時間: 90486.852 ms
ds2.xlarge
-- 一行インサート時間 - 100%非ソート状態とするため先頭にわざと１レコード追加 INSERT INTO lineorder_cp VALUES(1,1,1,1,1,1,'9','8',1,1,1,1,1,1,1,1,'7'); INSERT 0 1 時間: 736.959 ms -- 複数行インサート時間 - 7500万レコードをコピー INSERT INTO lineorder_cp SELECT * FROM lineorder; INSERT 0 75004738 時間: 42181.881 ms
※ lineorder_cpテーブルのソート割合（sort_percentage）0(0%)の状態であることを確認
status | tablename | sorted_rows | rows | sort_percentage
--------------+---------------------+-------------+----------+-----------------
1_sorted | lineorder_cp | 1 | 75004739 | 0.000
1_sorted | lineorder | 75004738 | 75004738 | 1.000
VACUUM時間の計測
７５００万レコードのデータに対してVACUUM FULLを実行します。内部的にDELETE、SORTが実行されるので一般に時間のかかる処理です。
ds1.xlarge
VACUUM FULL lineorder_cp; VACUUM 時間: 984606.407 ms
ds2.xlarge
VACUUM FULL lineorder_cp; VACUUM 時間: 360415.435 ms
※ lineorder_cpテーブルのソート割合（sort_percentage）1.0(100%)の状態であることを確認
status | tablename | sorted_rows | rows | sort_percentage
--------------+---------------------+-------------+----------+-----------------
1_sorted | lineorder_cp | 75004739 | 75004739 | 1.000
1_sorted | lineorder | 75004738 | 75004738 | 1.000
ANALYZE時間の計測
VACUUMをかけたことに加え、INSERT INTO ... SELECT で投入したデータに対してANALYZEが実行されていませんので、テーブルをANALYZEを実行して、適切なクエリプランが得られるように準備します。
ds1.xlarge
ANALYZE lineorder_cp; ANALYZE 時間: 32057.025 ms
ds2.xlarge
ANALYZE lineorder_cp; ANALYZE 時間: 21204.449 ms
行カウント時間の計測
実際のユースケースでは条件付きクエリーを実行して結果を得ることが多いですが、今回はクライアントの実装やネットワークIOで計測値がブレるのを避けるため、行カウントする時間を計測しています。
ds1.xlarge
SELECT COUNT(*) FROM lineorder WHERE lo_custkey < 2000000 and lo_linenumber < 7; count ---------- 48223756 (1 行) 時間: 4974.918 ms
ds2.xlarge
SELECT COUNT(*) FROM lineorder WHERE lo_custkey < 2000000 and lo_linenumber < 7; count ---------- 48223756 (1 行) 時間: 3330.948 ms
集計インサート時間の計測
DWHでは、ビックデータに対して１次集計、２次集計...マート作成等の集計テーブルの作成が日常的に行われますので、集計をして INSERT INTO ... SELECT で、集計テーブルを作成する時間を計測します。
ds1.xlarge
CREATE TABLE lineorder_summary ( lo_linenumber INTEGER NOT NULL, lo_custkey INTEGER NOT NULL, lo_ordertotalprice INTEGER NOT NULL ) distkey(lo_custkey) sortkey(lo_ordertotalprice, lo_linenumber, lo_custkey); CREATE TABLE 時間: 35.914 ms INSERT INTO lineorder_summary SELECT lo_linenumber, lo_custkey, SUM(lo_ordertotalprice) as lo_ordertotalprice FROM lineorder_cp GROUP BY lo_linenumber, lo_custkey ORDER BY lo_ordertotalprice, lo_linenumber, lo_custkey; INSERT 0 13094201 時間: 49472.154 ms
ds2.xlarge
CREATE TABLE lineorder_summary ( lo_linenumber INTEGER NOT NULL, lo_custkey INTEGER NOT NULL, lo_ordertotalprice INTEGER NOT NULL ) distkey(lo_custkey) sortkey(lo_ordertotalprice, lo_linenumber, lo_custkey); CREATE TABLE 時間: 155.345 ms INSERT INTO lineorder_summary SELECT lo_linenumber, lo_custkey, SUM(lo_ordertotalprice) as lo_ordertotalprice FROM lineorder_cp GROUP BY lo_linenumber, lo_custkey ORDER BY lo_ordertotalprice, lo_linenumber, lo_custkey; INSERT 0 13094201 時間: 22612.040 ms
検証結果
これまでの検証結果を御覧頂いたとおり、ds2.xlargeは概ね２倍以上の性能向上が確認できます。特に定期的に実行が必要となるデータロードやVACUUM、集計インサート等が良い結果が得られています。
ds1からds2の移行は超簡単
基本的に移行したいクラスタを選択してresizeでds1からds2するだけです。後は全て自動でデータ移行してくれます。
移行時の補足
- endpoint 及びリーダーノード Private IPに変更はありません
- リーダーノードのPublic IPは変更されます
- 移行している間は、通常よりも負荷が高くなり、データの参照のみ、更新はできません
- 移行に要する時間は使用済みのディスク量に依存します
【朗報】ds1のRIは乗り換えできます！
Updating your Dense Storage RIs with New Generation DS2 Instances
すでにds1（旧dw1）のRI（リザーブドインスタンス）をご購入のお客様には上記のタイトルのメールが届いているので、お気づきかもしれませんが、リザーブドインスタンスを移行できます。ds2のリザーブドインスタンス再購入していただくことが前提で、ds1のリザーブドインスタンスをキャンセルして移行します。（弊社「クラスメソッド・メンバーズ」加入のお客様はご相談ください）
最後に
これまで、CPUとIOのどちらかが上限に達すると性能が頭打ちになっていましたが、CPUとIOが共に２倍以上になったことで全ての検証項目において圧倒的に良い結果が得られました。 現在ds1(旧dw1)をご利用中の皆さんがds2に移行するための条件は全て整いましたので、ぜひご検討ください。
