Amazon Redshift から ClickHouse への移行

このドキュメントでは、Amazon Redshift から ClickHouse へのデータ移行の概要を説明します。

はじめに

Amazon Redshift は、構造化データおよび半構造化データ向けにレポート作成と 分析機能を提供するクラウドデータウェアハウスです。ClickHouse と類似した カラム指向データベースの原則に基づき、大規模データセット上の分析ワークロードを 処理できるように設計されています。AWS が提供するサービス群の一部として、 分析用データのニーズに対して AWS ユーザーが標準的に選択するソリューションと なっていることがよくあります。

Amazon エコシステムとの緊密な統合により既存の AWS ユーザーにとって魅力的である一方で、 リアルタイム分析アプリケーションの基盤として Redshift を採用したユーザーは、その用途に より最適化されたソリューションを必要とするケースが少なくありません。その結果として、既存の Redshift ワークロードを置き換える、あるいは並行してデプロイする「スピードレイヤー」として、 より優れたクエリ性能とデータ圧縮のメリットを得るために ClickHouse を選択するケースが増えています。

ClickHouse と Redshift の比較

AWS エコシステムへの投資比率が高いユーザーにとって、Redshift は データウェアハウスのニーズに直面した際の自然な選択肢となります。Redshift は ClickHouse と次の重要な点で異なります。Redshift は、複雑なレポーティングや分析クエリを要する データウェアハウス向けワークロードに対してエンジンを最適化しています。 すべてのデプロイメント形態において、次の 2 つの制約により、 Redshift をリアルタイム分析ワークロードに利用するのは困難です。

• Redshift は各クエリ実行プランごとにコードをコンパイルします。 これにより、初回クエリ実行に大きなオーバーヘッドが発生します。クエリパターンが予測可能で、 コンパイル済み実行プランをクエリキャッシュに保存できる場合、このオーバーヘッドは 正当化できます。しかし、クエリが都度変化するインタラクティブなアプリケーションにとっては 課題となります。Redshift がこのコードコンパイル結果のキャッシュを活用できる場合であっても、 多くのクエリで ClickHouse の方が高速です。"ClickBench" を参照してください。
• Redshift はすべてのキューで同時実行数を 50 に制限しています。 これは BI には十分ですが、高い同時実行性を必要とする 分析アプリケーションには不適切です。

一方で、ClickHouse も複雑な分析クエリに利用できますが、 リアルタイム分析ワークロード向けに最適化されており、アプリケーションを駆動したり、 ウェアハウスのアクセラレーションレイヤーとして機能します。その結果として、Redshift ユーザーは一般的に 次の理由から Redshift を ClickHouse に置き換えるか、あるいは補完的に利用します。

Advantage	Description
Lower query latencies	ClickHouse は、ストリーミング挿入が行われている状況や高い同時実行性の下でも、クエリパターンが変化する場合を含めて、より低いクエリレイテンシを実現します。インタラクティブなユーザー向け分析ではキャッシュミスは避けられませんが、そのような場合でも ClickHouse はクエリを高速に処理できます。
Higher concurrent query limits	ClickHouse は同時実行クエリ数に対してはるかに高い上限を設定しており、リアルタイムなアプリケーション体験には不可欠です。ClickHouse では、セルフマネージド環境でもクラウドでも、各サービスに必要な同時実行性を達成するためにコンピュート割り当てをスケールアップできます。許可されるクエリ同時実行レベルは ClickHouse で構成可能であり、ClickHouse Cloud ではデフォルト値は 1000 に設定されています。
Superior data compression	ClickHouse は優れたデータ圧縮を提供し、ユーザーは総ストレージ使用量（ひいてはコスト）を削減するか、同じコストでより多くのデータを永続化し、そのデータからより多くのリアルタイムインサイトを得ることができます。詳細は、以下の「ClickHouse と Redshift のストレージ効率の比較」を参照してください。