脱 COUNT DISTINCT のススメ

こちらの記事は、AWS Analytics Advent Calendar 2022 の 11 日目のエントリーです。AWSクラウドデータウェアハウスサービスである Amazon Redshift でクエリが遅いので高速化したいという話があり、チューニングした事例を書こうと思います。

Redshift における自動チューニング

データウェアハウスを運用、あるいは利用していると実行に時間のかかるクエリに遭遇することはままあると思います。Redshift においては Automatic table optimizationAutomated materialized views という機械学習の仕組みがエンジンに搭載されており、作られているテーブル定義や流れるワークロードをもとに、自動的にテーブルに格納されるデータの分散方式を変えたり(分散キー)、データを並び替えるキーを変えてくれたり(ソートキー)、マテリアライズドビューを作成してくれます。つまり、ワークロード環境にあったテーブル物理設計を自動で行い、クエリの高速化を手伝ってくれるというわけです。以下の "Automate your Amazon Redshift performance tuning with automatic table optimization | AWS Big Data Blog"で示されたグラフの例のように、時間の経過とともに分散キーの見直しが図られて実行時間が短縮し、その後さらにソートキーの見直しが図られて実行時間が短縮する、といった形ですね。このような仕組みがあるので、多くの場合は特に何もせずともいい感じに処理してくれるケースが多いはずです。

https://d2908q01vomqb2.cloudfront.net/b6692ea5df920cad691c20319a6fffd7a4a766b8/2021/09/23/BDB1235-IMG12.jpg

docs.aws.amazon.com

docs.aws.amazon.com

それでもさらにチューニングが必要なとき 

とはいえ、これですべての問題が解決するとは限らないし、そもそもテーブル物理設計(分散キー、ソートキー、マテリアライズドビューなど)の変更だけでは限界があるケースもあります。そんな時にはクエリの書き方を見直すのも一つです。*1

分散キーとかソートキーとか、テーブル物理設計にまつわるチューニングの話は正式ドキュメントを含めいろいなところに情報が出ているけど、クエリ部分についてはあまり情報がない気がしたので、今回は、クエリチューニングの一例を紹介します。

データ分析クエリでよく使われる、COUNT DISTINCT

COUNT DISTINCT、それは分析クエリでもよく使われる存在にしてなかなか厄介なやつでございます。まぁ言わずもがなですが、ある列の値をもとに重複を排除して取り出してその数をカウントする処理で、基本的に重いと言われているやつですね。たとえば大量のアクセスユーザーログデータが格納されたテーブルから、ユニークユーザーの数を出すときなんかに使われます。

今回、Redshift 上を流れる長文クエリで非常に時間のかかっているものがあり、ボトルネック解析をしていたところ、特定のサブクエリの箇所で時間がかかっていそう、ということが分かりました。そのサブクエリの中身を見ると COUNT DISTINCT の処理が多用されていたため、ここを書き換えることで性能を改善しました。

このブログでは、事情により実際のクエリは書けないため、サンプルデータを使ってどのようにクエリを書き換えたかを記載します。

COUNT DISTINCT を GROUP BY + COUNT に変えてみた

サンプルデータとしては、標準ベンチマークTPCH スキーマの lineitem テーブル(約60億件)を使います。

dev=# select count(*) from lineitem;
count
------------
5999989711
(1 row)

COUNT DISTINCT を含む元のクエリです。複数列で COUNT DISTINCT しています。

dev=# select 
 l_linestatus, 
 count(distinct l_shipdate), 
 count(distinct l_commitdate), 
 count(distinct l_receiptdate) 
from lineitem 
group by l_linestatus;

 l_linestatus | count | count | count 
--------------+-------+-------+-------
 F            |  1263 |  1323 |  1292
 O            |  1263 |  1323 |  1292
(2 rows)

Time: 208819.605 ms

208 秒くらいかかりました。

これを、GROUP BY + COUNT の処理に書き換えます。

dev=# select
 l_linestatus, 
 count(l_shipdate), 
 count(l_commitdate), 
 count(l_receiptdate) 
from (
  select
   l_linestatus, 
   l_shipdate, 
   null as l_commitdate, 
   null as l_receiptdate 
  from lineitem 
  group by l_linestatus, l_shipdate 
 union all 
  select
   l_linestatus, 
   null as l_shipdate, 
   l_commitdate, 
   null as l_receiptdate 
  from lineitem 
  group by l_linestatus, l_commitdate 
 union all 
  select 
   l_linestatus, 
   null as l_shipdate, 
   null as l_commitdate, 
   l_receiptdate
  from lineitem 
  group by l_linestatus, l_receiptdate
) 
group by l_linestatus;

 l_linestatus | count | count | count 
--------------+-------+-------+-------
 F            |  1263 |  1323 |  1292
 O            |  1263 |  1323 |  1292
(2 rows)

Time: 94580.686 ms

94秒に短縮されました。返ってくる結果は COUNT DISTINCT のクエリと同じです。

これ、クエリが長くなって可読性は悪いですが、何をしているかというと

  1. まず最初に () で囲まれたサブクエリの中で DISTINCT を使わず GROUP BY を使って列ごとに重複排除
  2. それぞれを UNION で連結する
  3. UNION で連結した重複排除済みのデータをカウントする

という感じです。

おまけ1:APPROXIMATE COUNT DISTINCT

余談として、もし COUNT DISTINCT 結果に厳密な精度を求めない場合(ある程度ざっくりの傾向値でいいよ、という場合)は、HyperLogLog の仕組みを使った APPROXIMATE COUNT DISTINCT を使うのも手です。精度が落ちるかわりに、非常に高速に結果を返すことができます。

APPROXIMATE COUNT DISTINCT パターン

dev=# select 
 l_linestatus, 
 approximate count(distinct l_shipdate), 
 approximate count(distinct l_commitdate), 
 approximate count(distinct l_receiptdate) 
from lineitem 
group by l_linestatus;

 l_linestatus | count | count | count 
--------------+-------+-------+-------
 O            |  1266 |  1330 |  1296
 F            |  1260 |  1315 |  1293
(2 rows)

Time: 61995.861 ms

COUNT DISTINCT の結果と若干数値が異なりますが、61秒と非常に高速に結果を返しました。

おまけ2:1つの COUNT DISTINCT を含むクエリの書き換え

ここまでの例はクエリ内に複数の COUNT DISTINCT がある場合の書き換えでしたが、もし一つの COUNT DISTINCT がある場合なら、もう少しシンプルになります。

COUNT DISTINCT パターン

dev=# select
 l_linestatus, 
 count(distinct l_shipmode) 
from lineitem 
group by l_linestatus; 

 l_linestatus | count 
--------------+-------
 F            |     7
 O            |     7
(2 rows)

Time: 134243.333 ms

GROUP BY + COUNT パターン

dev=# select
 l_linestatus, 
 count(l_shipmode) 
from (
  select
   l_linestatus,
   l_shipmode 
  from lineitem 
  group by l_linestatus,l_shipmode
) 
group by l_linestatus;

 l_linestatus | count 
--------------+-------
 F            |     7
 O            |     7
(2 rows)

Time: 55941.845 ms

この例の場合だと、COUNT DISTINCT から GROUP BY + COUNT に書き換えることで、実行時間が134秒から55秒と、半分以下になりました。

脱 COUNT DISTINCT のススメ(困ったときだけ)

COUNT DISTINCT を GROUP BY + COUNT に変えることによって、パフォーマンス向上が確認できました。COUNT DISTINCT を使ったクエリのパフォーマンスにお困りの方は、脱 COUNT DISTINCT を試してみてはいかがでしょうか。

ただ、当たり前ですが念の為補足しておくと、COUNT DISTINCT を使っていてもそれほどパフォーマンスに困っていないなら、わざわざ書き換える必要はないです。Redshift のエンジンバージョンアップによって性能向上も期待できるし、なによりクエリの可読性も大事です。

また、何か書きたいと思います。See you next time!

*1:性能改善の手段としては、テーブル物理設計やクエリの見直しがすべてではなく、データモデル(テーブル論理設計)自体を見直す、リソースを増やす(Redshift Provisioned の場合はノード数を増やす、Redshift Serverless の場合は RPU を増やす)など他にももちろんあります、念の為…

Amazon Redshift 2021 年振り返り

こちらの記事は、AWS Analytics Advent Calendar 2021 の 20 日目のエントリーです。
2021 年も残り 10 日ほどとなってきましたが、みなさまいかがお過ごしですか?僕は週 2-3 程度、早朝にジョギングをしているのですが、最近グッと寒くなってきたので朝起きるのが辛くなってきました。。

さて、アドベントカレンダーに何を書こうかなと考えていたところ、ちょうど先週末の AWS Big Data Blog にて What’s new in Amazon Redshift – 2021, a year in review という記事が投稿されました。よいタイミングなので、この記事の内容を踏まえつつ、オリジナルコメントを多分に交えながら、2021 年の Amazon Redshift のアップデートについて振り返りたいと思います。

目次

 

Amazon Redshift の 3 つのイノベーションエリア

Redshift は高速でシンプルかつ費用対効果の高いデータウェアハウスサービスであり、AWS のサービスの中でも進化の速いサービスのうちの一つです。2012 年末の登場以来、非常に多くの進化を遂げてきましたし、こと 2021 年だけを見ても 50 以上の新機能がリリースされています。本記事の執筆日から約半年前の 2021 年 4 月には、Amazon Redshift の進化の歴史のこれから(日本語版) / Amazon Redshift evolution history and future direction (English version) という資料にこれまでのアップデートの道のりをまとめましたが、こちらの内容も一部古くなってしまっている事実があるほど、絶え間なく進化を続けているのです (資料は何度かアップデートしたものの、最近更新できていませんでした…どこかのタイミングで更新します)。

speakerdeck.com

そんな Redshift ですが、近年では、ユーザーフィードバックに基づき、以下の 3 つの領域にフォーカスして開発が進められています。

  1. Easy analytics for everyone
  2. Analyze all of your data
  3. Performance at any scale

1 つ目の Easy analytics for everyone ですが、まさに読んで字の如くですが「すべてのユーザーに使いやすい分析環境を」というコンセプトを指します。一昔前までは、企業の分析環境 (データウェアハウス) の導入を考えるユーザーは、IT 部門のような基盤提供を行う方々、それもデータウェアハウス周辺のテクノロジーについて精通された方々が中心でした。しかし昨今では、データアナリストやデータサイエンティストのような基盤の利用者の方であったり、(必ずしも IT に閉じない) さまざまな知識バックグラウンドをもった業務ユーザーの方であったりと、その範囲が大きく広がっています。そのため、Redshift を誰にとっても使いやすくするための機能追加や拡張に注力しています。

2 つ目は Analyze all of your data「すべてのデータを分析できるようにする」です。ユーザーが最新のデータを使って分析を行いたいと思った時に、必ずしもすべてのデータがその瞬間に手元にある、つまりデータウェアハウスに集まっているとは限りません。一方で、多くのユーザーは、データガバナンスやコスト効率など様々な観点からデータのサイロ化 (同じデータを複数システムで二重持ちや三重持ちする) を極力避けたいとも考えられています。そのため、データウェアハウスにあらゆるデータをコピーし保持する (あるいは保持し続ける) のではなく、データの源泉であるリレーショナルデータベースやデータレイクなどにあるデータも含めて透過的にアクセスし、すべてのデータを分析したいという声をいただいています。そのようなニーズに応えるため、周辺の AWS サービスとの連携強化を中心とした機能拡張を継続的に行っています。

3 つ目の Performance at any scale は、「テラバイトからペタバイト、それ以上といったあらゆる規模で高いコストパフォーマンスを」という内容です。複雑なクエリをいかに高速に処理することができるか、というのは今も昔もデータウェアハウスに求められるものの代表的なものの一つです。近年ではそれを以下に低コストで実現できるか、という視点が非常に重要になってきており、その両翼をサポートするような拡張を続けています。

それでは Redshift におけるこれら 3 つの投資領域について 2021 年にどのようなアップデートがあったのか、見ていきましょう。

 

Easy analytics for everyone

Redshift Serverless (パブリックプレビュー)

まずは何と言っても re:Invent 2021 で発表された Redshift Serverless (パブリックプレビュー) でしょう。Redshift Serverless は、従来の Redshift で必要だったクラスターのプロビジョニングと管理が不要となる、Redshift のサーバーレスオプションです。事前にリソース確保が不要で、サーバーレスエンドポイントに直接クエリを投げるだけで動的にリソースをスケーリングして処理してくれます。ユーザーは初回に AWS マネージメントコンソールの Redshift ページから数クリックで Redshift Serverless にサインアップして開始できます。

Redshift Serverless で利用できる機能は基本的に従来のクラスター型の Redshift と変わりませんが、より "Easy analytics for everyone" を指向したオプションであり WLM(ワークロード管理), Concurrency Scaling(同時実行スケーリング), パラメーター設定などを含めた細かい管理は 2021 年 12 月時点ではできないようになっています。Redshift Serverless は、データウェアハウスなどの深い知識なしに、パワフルな Redshift の分析パワーを得てより手軽に分析を行いたいユーザーに向いています。逆に言うと、きめ細やかな設定調整やチューニングを施し、基盤の最適化を追い求めたいユーザーは、引き続きクラスター型 Redshift のほうがマッチする場合があります。

Redshift Serverless のコンピュートリソースがクエリするデータは Redshift RA3 と同じく Redshift Managed Storage 上のデータに加えて、Amazon S3 データレイク上に配置された CSV, JSON, Parquet といったオープンフォーマットファイル*1Amazon RDS/Aurora などのオペレーショナルデータベース上のデータも対象です。

料金はクエリの実行に使用された RPU (Redshift Processing Unit) に応じた秒単位課金 (詳細は Amazon Redshift pricing を参照) で、東京リージョンを含めた 6 リージョンでパブリックプレビューが開始されています。

f:id:josql:20211220175309p:plain

Redshift Query Editor V2

Redshift Query Editor V2 は、データアナリスト、データサイエンティスト、およびデータベース開発者が Redshift データウェアハウスおよびデータレイク内のデータを簡単に分析したり共有することをサポートする Web ベースのクエリエディタです。Redshift の提供する機能の一つであり、利用にあたって追加のコストは必要ありません。スキーマやテーブルの作成と参照、手元の CSV や S3 上にあるファイルを使ったデータロード、SQL クエリの作成と実行、クエリ結果の簡単な可視化を行うことができて非常に便利です。また、直近のエンハンスメントとして、SQL ノートブック機能 (プレビュー)もサポートしており、これにより、ユーザーがクエリを作成して Markdown を使ったコメントなどとともにドキュメントにまとめて、他のメンバーに共有することができます。ちょうど以下のようなイメージです。

f:id:josql:20211220173101p:plain

自動マテリアライズドビュー (パブリックプレビュー)

Redshift は頻繁に利用されるクエリのパフォーマンスを向上させるための機能の一つとして、特定のクエリパターンを実行した結果を別のデータセットとして保持しておき、クエリ実行時にデータを高速に取り出すための仕組みであるマテリアライズドビューをサポートしています。Redshift のマテリアライズドビューは、複数のテーブルを事前に結合したり、特定の軸で集計するなど様々なパターンの処理に対応し、その元となるテーブルが更新されると自動でリフレッシュされる仕組みが入っていたり、テーブルにクエリを投げると必要に応じて自動的にマテリアライズドビューを参照するように実行計画を書き換えるクエリリライトという機能も実装されており、非常に使い勝手がよいです。

f:id:josql:20211220175403p:plain

 

そんなマテリアライズドビューに関して、re:Invent 2021 で大きな発表がありました。それが「自動マテリアライズドビュー (パブリックプレビュー)」です。上記で説明したマテリアライズドビューはユーザー側で手動で設計・作成して管理する必要がありましたが、Redshift がワークロードを学習して自動で必要と判断したマテリアライズドビューを作成し、不要となれば削除するということをユーザーの代わりにやってくれるようになりました。既に自動テーブル最適化 (テーブルの分散キー、ソートキー、列圧縮などを自動設定)、自動ワークロード管理、Vacuum や Analyze の自動化など、自動パフォーマンスチューニングの仕組みが動いていますが、このアップデートにより更にノンチューニングでのパフォーマンス向上が期待できます。まさに、”Easy analytics for everyone” のための機能であると言えると思います。

Data API

DataAPI は、2020 年にリリースされた AWS Lambda, Amazon SageMaker Notebook, AWS Cloud 9 など、クラウドネイティブなサーバーレス Web アプリケーションやイベント駆動型アプリケーションから Redshift への簡単なアクセスを実現する機能です。Data API を使用すると JDBC/ODBC のようなドライバーを構成したり、データベース接続を管理したりする必要なく、API エンドポイントを呼び出すだけで Redshift に対して SQL コマンドを実行できるようになります。データベース接続の管理とデータのバッファリング処理は Data API 側で管理されます。 そんな Data API ですが、2021 年にはマルチステートメントクエリの実行とパラメーターのサポート大阪リージョンでのサポートなど様々な機能強化が行われました。 

Amazon Managed Grafana Redshift plugin

2021 年 11 月、Amazon Managed Grafana 用の Redshift plugin がリリースされました。データの可視化ダッシュボード機能を提供するオープンソースのツールである Grafana のマネージドサービスである Amazon Managed Grafana のデータソースとして Redshift がサポートされ、Amazon Managed Grafana 上で Redshift クラスターのメトリクスをカスタマイズして表示し、モニタリングできるようになりました。そもそも AWS マネージメントコンソール上で Redshift クラスターのメトリクスはモニタリング可能ですが、ある程度テンプレが決まっているため、よりカスタマイズされた画面を使ってモニタリングしたい場合などはこの Grafana Redshift plugin を活用するといいと思います。以下は実行中のクエリの細かいメトリクスを一覧で可視化するカスタマイズ画面のイメージです。

f:id:josql:20211220190220p:plain

 

Analyze all of your data

Redshift Data Sharing

2021 年 3 月、Redshift Data Sharing の一般提供を開始しました。Redshift Data Sharing により、Redshift RA3 ノードタイプのクラスター内のデータをコピーまたは移動することなく、別の Redshift RA3 クラスターに共有し、それぞれのクラスターから一貫性のある同一データにアクセスできるようになります。この機能がリリースされる前は、クラスター間でデータ連携をする場合には一旦 S3 上にテーブルデータを Unload したうえで別クラスターのテーブルに Load する必要がありましたが、この機能が出たことによりデータパイプラインをシンプル化できるようになりました。また、データは共有しつつ用途に応じてクラスターを分けて Data Sharing 構成を組むことにより、コンピューティングリソースや請求単位の分離が可能になります。なお、2021 年 8 月にはクロスアカウントのサポート、同年 11 月にはクロスリージョンのサポート (プレビュー) Data Sharing 構成におけるパフォーマンス強化 (リザルトキャッシュの共有、Concurrency Scaling の利用をサポート) を発表し、その適用範囲を拡張し続けています。

AWS Data Exchange for Amazon Redshift (パブリックプレビュー)

2021 年 10 月に、AWS Data Exchange for Amazon Redshift がパブリックプレビューとして発表されました。AWS Data Exchange で様々なデータプロバイダーが提供する 3rd Party データを検索してサブスクライブし、Redshift 上ですぐにクエリすることができるようになりました。データプロバイダーは、AWS Data Exchange カタログに Redshift のデータセットを提供し、サブスクライバーにデータへの読み取り専用アクセスを直接許可します。この機能により、これらのサードパーティのデータセットを自社に取り込んで ETL することなく、自社のデータを組み合わせてクエリを実行することができます。この機能を使うには、Data Sharing 機能が使える Redshift RA3 ノードタイプを利用している必要があります。

Redshift ML

2021 年 5 月には Amazon Redshift ML の一般提供を開始しました。Amazon Redshift ML を利用すると、Redshift 上のテーブルデータをインプットとし、SQL を使って機械学習モデルを作成し、モデルを評価し、推論処理を実行することができます。バックグラウンドでは Amazon S3 にデータを Unload し、Amazon SageMaker (Autopilot / Neo) が呼び出されて使われますが、ユーザーはそれを意識する必要はありません。機械学習Python コーディングに精通していない SQL 使いの方から SageMaker を使いこなす ML エンジニアの方まで、幅広く試していただきやすい機能になっています。ちなみに、最近では K-means クラスタリングアルゴリズムによる教師なし学習モデルの作成もサポートされました。

Redshift ML の詳細は以下をご覧になってください。

speakerdeck.com

Redshift Federated Query が RDS/Aurora for MySQL をサポート

Redshift は RDS や Aurora のデータベースに格納されたテーブルに対して、Redshift を介して直接クエリを実行する Federated Query 機能をサポートしています。これまでは、RDS for PostgreSQL および Aurora for PostgreSQL のみ、データソースとしてサポートしていましたが、2021 年 9 月に RDS for MySQL および Aurora for MySQL のサポートを一般提供開始しました。たとえば RDS/Aurora for MySQL 上に最新マスタテーブルが存在し、そのマスタと Redshift 上のログデータを結合したクエリをライブで実行したい場合、Federated Query を利用することで RDS/Aurora からデータを移動させることなくその場で最新データの分析が可能になります。RDS/Aurora, Redshift, S3 データレイクにまたがるデータを一発のクエリで結合して分析することも簡単になりますね。

新しいデータ型 - SUPER, GEOGRAPHY, VARBYTE

2021 年には新しいデータ型のリリースも多くありました。2021 年 5 月に発表された SUPER 型は、JSON のような半構造化データをネイティブに取り扱うためのデータ型で、ネストされた複雑な半構造化データを前処理することなくテーブルに取り込むことができたり、ネストデータの値の探索や展開 (Unnest) を行う PartiQL 言語をサポートしています。2021 年 11 月に発表された GEOGRAPHY 型は、空間データ(位置情報) を平面モデルではなく楕円体モデルとして表現する空間データ型です。元々サポートされていた GEOMETRY 型とともに 2 つの主要な空間データ型がサポートされたことになります。更に、ESRI ArcGIS が Redshift の GEOMETRY / GEOGRAPHY をサポートした旨を発表するなど、この分野での Redshift の活用も熱い分野になってきていると思います。また、同じく 2021 年 11 月には VARBYTE 型も発表されました。これはバイナリデータを格納するためのデータ型で、特に同様のデータ型を持つ別のデータベースから Redshift へ移行したいケースでは重宝すると思います。

 

Performance at any scale

Redshift RA3 ノードタイプ

2019 年にコンピューティングとストレージの独立したスケーリングを可能とする RA3 ノードタイプがリリースされて以来、RA3 でのみサポートされる機能のリリースが増えてきています。先にご紹介した Data Sharing 機能はその代表的なものの一つですし、RA3 クラスターのクエリパフォーマンスを更に高速化する、分散型ハードウェアアクセラレーションキャッシュの AQUAVPC 内の Redshift クラスターに対して、別の VPC やオンプレミス環境から接続するためのクロス VPC サポートなども 2021 年に一般提供を開始した RA3 ノードタイプでのみ利用できる機能です。

このように、RA3 を前提とした機能拡張が進んできたこともあり、DS2, DC2 など旧世代のノードタイプ利用ユーザーからの RA3 ノードタイプへの切り替えニーズが高まっています。そこで移行をサポートする機能として、DS2 ノードタイプを Reserved Instance (RI) で契約しているユーザー向けに、RA3 RI 移行機能の提供を開始しました。また、移行に際してパフォーマンス上の懸念を解消するためのソリューションとして、既存クラスターワークロードを完全再現するための Redshift Simple Replay ユーティリティも提供されています。

なお、RA3 ノードタイプは 3 種類のサイズ (小さいノードタイプから順に RA3.xlplus, RA3.4xlarge, RA3.16xlarge) をサポートしていますが、いずれも最小構成が 2 ノードからとなっていました。2021 年 12 月には、RA3.xlplus が 1 ノード構成のサポートを開始され、更に安価に Redshift を試せるようになりました。

Concurrency Scaling 書き込みクエリのサポート (プレビュー)

Concurrency Scaling (同時実行スケーリング) は、2019 年にリリースされた機能で、ワークロードの突発的なバースト時にバックグラウンドで自動で追加の Redshift クラスターを起動し、並行クエリを待たせることなく実行することで Redshift の並列スループットを向上させることが可能です。リソースは事前にプロビジョニングしたり購入する必要はなく、ピーク時に追加リソースで処理されたクエリの実行時間 (秒) に対してのみ課金されますが、1 日 1 時間分は無償クレジットが付与されるため多くのケースでは無料の範囲で利用できます。また、日毎、週毎、月毎といった単位で Concurrency Scaling の利用上限を設けることができ、予期せぬコスト発生を抑制することも可能です。

これまで、Concurrency Scaling がサポートするクエリは SELECT, Unload などの読み取りクエリに限られていましたが、2021 年 11 月に書き込みクエリのサポートをプレビューとして開始しました。Redshift で同時実行性の高い INSERT, DELETE, UPDATE, COPY などの ELT ワークロードが稼働する環境では、Concurrency Scaling を活用することでパフォーマンスを最適化することができるかもしれません。

 

まとめ

Amazon Redshift の 2021 年振り返りを行ってきました。ここで振り返った内容は What’s new in Amazon Redshift – 2021, a year in review をベースにピックアップされた一部のものでしたが、それでもかなりの長文になってしまいました。最後までお読みいただき、ありがとうございます。

2022 年はどのような進化が待っているのでしょうか?一つ分かっていることは、Kinesis Data Streams とのインテグレーションである、Stream Ingestion の limited preview が始まっていることだけです。これも今から楽しみですね!

またアップデートが溜まってきたら、何か書きたいと思います。See you next time!

 

 

*1:クラスター型の Redshift では、Redshift Spectrum フリートのリソースが使われますが、Redshift Serverless では Redshift Serverless のコンピュートリソースが使われます。公式のドキュメンテーションで Redshift Serverless が Spectrum をサポートしていない旨の記述があるのはそのためです