Amazon Redshift 新エントリーノードタイプ dc2.large と dc1.large の徹底比較
はじめに
先日、Amazon Redshiftの新しいノードタイプ dc2.large と dc2.8xlarge がリリースされました。Amazon Redshift: 新しいノードタイプ「DC2」が発表されました でご報告したとおり、「Amazon Redshiftに新世代のDC2ノードが追加 – 価格はそのままで最大2倍の性能向上」と発表されていますが、実際のユースケースでどれ位の性能向上が見られるか試してみたいと思います。
Dense Compute 2（dc2）ノードでは、安価で高パフォーマンスのデータウェアハウスを作成できるように、高速 CPU、大容量 RAM、および NVMe-SSD が使用されます。ディスク容量よりもIOや処理性能を重視したノードタイプで、上位のノードタイプとしてdc2.8xlargeが提供されています。また、dc2.largeはRedshiftが提供する最も利用費が安いノードタイプです。
スペックの新旧比較
dc2はdc1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。
dc1.large と dc2.large
| Node Size | vCPU | ECU | Memory (GiB) | Storage | I/O | Node Range | Slices | Total Capacity |
|---|---|---|---|---|---|---|---|---|
| dc1.large | 2 | 7 | 15 | 0.16 TB SSD | 0.20GB/s | 1–32 | 2 | 5.12 TB |
| dc2.large | 2 | 7 | 15.25 | 0.16 TB NVMe-SSD | 0.60GB/s | 1–32 | 2 | 5.12 TB |
dc1.8xlarge と dc2.8xlarge
| Node Size | vCPU | ECU | Memory (GiB) | Storage | I/O | Node Range | Slices | Total Capacity |
|---|---|---|---|---|---|---|---|---|
| dc1.8xlarge | 32 | 104 | 244 | 2.56 TB SSD | 3.70GB/s | 2–128 | 32 | 326 TB |
| dc2.8xlarge | 32 | 99 | 244 | 2.56 TB NVMe-SSD | 7.50GB/s | 2–128 | 16 | 326 TB |
性能検証 - dc1.large vs dc2.large
パフォーマンスの計測条件
- クエリ性能検証 リージョン：バージニア（us-east-1）
- クラスタ：dc1.large と dc2.large ともに 2ノードクラスタ構成
- データ：AWSが提供しているサンプルデータ（s3://awssampledb/ssbgz/）
- レコード数：約６億レコード
- テーブル：lineorder
--DROP TABLE "lineorder";
CREATE TABLE IF NOT EXISTS "lineorder"
(
"lo_orderkey" INTEGER NOT NULL
,"lo_linenumber" INTEGER NOT NULL ENCODE delta
,"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 ENCODE bytedict
,"lo_shippriority" VARCHAR(1) NOT NULL ENCODE runlength
,"lo_quantity" INTEGER NOT NULL ENCODE delta
,"lo_extendedprice" INTEGER NOT NULL ENCODE lzo
,"lo_ordertotalprice" INTEGER NOT NULL ENCODE lzo
,"lo_discount" INTEGER NOT NULL ENCODE delta
,"lo_revenue" INTEGER NOT NULL ENCODE lzo
,"lo_supplycost" INTEGER NOT NULL ENCODE delta32k
,"lo_tax" INTEGER NOT NULL ENCODE delta
,"lo_commitdate" INTEGER NOT NULL ENCODE delta
,"lo_shipmode" VARCHAR(10) NOT NULL ENCODE bytedict
)
DISTSTYLE KEY
DISTKEY ("lo_partkey")
SORTKEY (
"lo_orderdate"
)
;
データロード時間の計測
S3からRedshiftにデータをロード（COPYコマンド）する時間を計測します。以下の処理ではデータのロード、VACUUM、ANALYZEが内部的に実行されます。
dc1.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
-- COPY lineorder FROM 's3://awssampledb/ssbgz/lineorder0000_part_00.gz' COPY lineorder FROM 's3://awssampledb/ssbgz/lineorder' CREDENTIALS 'aws_iam_role=arn:aws:iam::123456789012:role/RedshiftRole' COMPUPDATE OFF GZIP ; COPY Time: 1403450.740 ms (23:23.451)
dc2.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
-- COPY lineorder FROM 's3://awssampledb/ssbgz/lineorder0000_part_00.gz' COPY lineorder FROM 's3://awssampledb/ssbgz/lineorder' CREDENTIALS 'aws_iam_role=arn:aws:iam::123456789012:role/RedshiftRole' COMPUPDATE OFF GZIP ; COPY Time: 1230910.691 ms (20:30.911)
一数行インサート・複数行インサート時間の計測
Redshiftでは、空のテーブルに対して INSERT INTO ... SELECT でデータを投入するとソート済みデータとして投入できますが、後ほどVACUUM時間を計測したいので、ソート状態にならないように事前に１レコード投入しているところがポイントです。
dc1.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
-- 一行インサート時間 - 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 Time: 1927.633 ms (00:01.928) -- 複数行インサート時間 - 約６億レコードをコピー INSERT INTO lineorder_cp SELECT * FROM lineorder; INSERT 0 600037902 Time: 481281.076 ms (08:01.281)
dc2.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
-- 一行インサート時間 - 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 Time: 1341.825 ms (00:01.342) -- 複数行インサート時間 - 約６億レコードをコピー INSERT INTO lineorder_cp SELECT * FROM lineorder; INSERT 0 600037902 Time: 325370.569 ms (05:25.371)
VACUUM時間の計測
約６億レコードのデータに対してVACUUM FULLを実行します。内部的にDELETE、SORTが実行されるので一般に時間のかかる処理です。
lineorder_cpテーブルの未ソート割合（pct_unsorted）100(100%)の状態であることを確認
事前にlineorder_cpテーブルの未ソート割合が100%であることを確認します。
tablename | megabytes | rowcount | unsorted_rowcount | pct_unsorted | recommendation ----------------------------+-----------+-----------+-------------------+--------------+------------------------- lineorder | 28728 | 600037902 | 0 | 0 | n/a lineorder_cp | 28668 | 600037903 | 600037902 | 100 | VACUUM SORT recommended
dc1.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
VACUUM lineorder_cp; VACUUM Time: 2361741.838 ms (39:21.742)
dc2.large
メトリックス： QUERIES/CPU/NETWORK | WRITE | READ
VACUUM lineorder_cp; VACUUM Time: 2234033.311 ms (37:14.033)
lineorder_cpテーブルの 未ソート割合（pct_unsorted）0(0%)の状態であることを確認
VACUUM実施後にlineorder_cpテーブルの未ソート割合が0%であることを確認します。
tablename | megabytes | rowcount | unsorted_rowcount | pct_unsorted | recommendation ----------------------------+-----------+-----------+-------------------+--------------+---------------- lineorder | 28728 | 600037902 | 0 | 0 | n/a lineorder_cp | 28752 | 600037903 | 0 | 0 | n/a
ANALYZE時間の計測
VACUUMをかけたことに加え、INSERT INTO ... SELECT で投入したデータに対してANALYZEが実行されていませんので、テーブルをANALYZEを実行して、適切なクエリプランが得られるように準備します。
dc1.large
ANALYZE lineorder_cp; ANALYZE Time: 40893.048 ms (00:40.893)
dc2.large
ANALYZE lineorder_cp; ANALYZE Time: 29371.240 ms (00:29.371)
行カウント時間の計測
実際のユースケースでは条件付きクエリーを実行して結果を得ることが多いですが、今回はクライアントの実装やネットワークIOで計測値がブレるのを避けるため、行カウントする時間を計測しています。また、以前であれば、コンパイル時間を排除するために、参照系クエリは２回実行して、2回目の時間をベンチマークの計測値としましたが、現在はResult Cachingがデフォルトで有効になっており、結果キャッシュを返すので１度目の値を計測値としています。
dc1.large
SELECT COUNT(*) FROM lineorder WHERE lo_custkey < 2000000 and lo_linenumber < 7; count ----------- 385740049 (1 row) Time: 5906.958 ms (00:05.907)
dc2.large
SELECT COUNT(*) FROM lineorder WHERE lo_custkey < 2000000 and lo_linenumber < 7; count ----------- 385740049 (1 row) Time: 5097.764 ms (00:05.098)
集計インサート時間の計測
DWHでは、ビックデータに対して１次集計、２次集計...マート作成等の集計テーブルの作成が日常的に行われます。以下の検証用クエリでは、フィルタ・集計・ソートした結果をディープコピーして、集計テーブルを作成する時間を計測します。
dc1.large
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 Time: 404.250 ms INSERT INTO lineorder_summary SELECT lo_linenumber, lo_custkey, SUM(lo_ordertotalprice) as lo_ordertotalprice FROM lineorder_cp WHERE lo_orderdate >= '1993-01-01' AND lo_orderdate < '1997-01-01' GROUP BY lo_linenumber, lo_custkey ORDER BY lo_ordertotalprice, lo_linenumber, lo_custkey; INSERT 0 13982744 Time: 83363.175 ms (01:23.363) ``` #### dc2.large ```sql 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 Time: 348.203 ms INSERT INTO lineorder_summary SELECT lo_linenumber, lo_custkey, SUM(lo_ordertotalprice) as lo_ordertotalprice FROM lineorder_cp WHERE lo_orderdate >= '1993-01-01' AND lo_orderdate < '1997-01-01' GROUP BY lo_linenumber, lo_custkey ORDER BY lo_ordertotalprice, lo_linenumber, lo_custkey; INSERT 0 13982744 Time: 66380.902 ms (01:06.381)
性能の検証結果
これまでの検証結果を御覧頂いたとおり、全ての検証項目において dc2.largeは概ね20〜30%の性能向上が確認できました。
- データロード： 13.3% ↑
- 一行インサート： 30.4% ↑
- 複数行インサート： 32.4% ↑
- VACUUM： 5.4% ↑
- ANALYZE： 28.2% ↑
- 行カウント： 13.7% ↑
- 集計インサート： 20% ↑
最後に
今回の検証では、クエリの傾向を把握する目的でシンプルなクエリを同時実行無しで計測しています。他にも結合、フィルタ、集計のクエリを実行しましたが、概ね20〜30%範囲でした。このようなシンプルなクエリでは、READ/WRITEよりもCPUのボトルネックが先に顕在化してdc2の「IOが3倍」という特性を活かしきれず、２倍の性能向上に至らなかったと推測しています。複雑なクエリーが同時に複数実行するユースケースで、かつボトルネットがREAD/WRITEの場合、ノードタイプをdc1からdc2に変更をすることで、今回の検証結果よりも良い結果が得られるのではないかと考えられます。何れにしてもAWS利用費が変わらず、チューニングレスで20〜30%の性能向上という結果は検討に値すると言えるでしょう。
