2017-08-04 13 views
0

データがs3から数分ごとにredshift(kinesis firehoseから)に読み込まれるシステムを構築しました。私はそのメインテーブルからデータを取得し、それを顧客ごとのテーブルに分割します。Redshiftクエリを最適化できません

メインテーブルには数億行があります。私は読んだことがある

SORTKEY (customer_id, time) 
DISTKEY customer_id 

すべてが、これは私のテーブルを構築するための最適な方法だろう示唆:私のように定義されたキーを持つ

create table {$table} as select * from {$source_table} where customer_id = '{$customer_id} and time between {$start} and {$end}' 

:サブテーブルを作成する

は、このようなクエリで行われます/クエリがパフォーマンスは絶対にひどいです。サブテーブルを作成するには、選択する行数がわずかであっても1分以上かかる。

何か不足していますか、クラスタをスケールするだけですか?

+0

これらのDISTKEYとSORTKEYは、メインテーブルまたはサブテーブルにありますか? CREATE TABLEではなくSELECTとしてクエリを実行すると、実行にはどれくらい時間がかかりますか? –

+0

SELECTとCREATE TABLEのパフォーマンスはほぼ同じです。 –

答えて

1

より良いキーをお持ちでない場合は、DISTSTYLE EVENと同じソートキーを使用することを検討する必要があります。

理想的には、ディストリビューションキーは結合で使用される値であり、データをクラスタ全体に均等に分散する必要があります。 customer_idをディストリビューションキーとして使用し、そのキーをフィルタリングすると、すべての作業が1つのスライスで行われることになります。

これを実際に見るには、システムテーブルを見てください。まず、クエリの例を見つける:

SELECT * 
FROM stl_query 
WHERE userid > 1 
ORDER BY starttime DESC 
LIMIT 10; 

その後、svl_query_reportに照会あなたのステップごとにスライスごとにbytesを見て:

SELECT * 
FROM svl_query_report 
WHERE query = <your query id> 
ORDER BY query,segment,step,slice; 

最高のテーブル構造を設計する上で非常に詳細なガイドを持っています私たちを見てください"Amazon Redshift Engineering’s Advanced Table Design Playbook"

+0

これは理にかなっています。パフォーマンスが向上することを確認するために、均等な分布で実験します。 –