メインコンテンツへスキップ
このドキュメントでは、Amazon Redshift から ClickHouse へのデータ移行の概要を紹介します。

はじめに

Amazon Redshift は、構造化データおよび半構造化データ向けのレポート機能と 分析機能を提供するクラウドデータウェアハウスです。これは、 ClickHouse と同様のカラム指向データベースの原則に基づき、大規模なデータセットに対する 分析ワークロードを処理できるよう設計されています。AWS の サービスの一部であることから、分析データ基盤を必要とする AWS ユーザーにとって、 Redshift はしばしば最初に選ばれる既定のソリューションとなっています。 Amazon エコシステムとの緊密なインテグレーションにより、既存の AWS ユーザーにとって 魅力的な選択肢である一方、Redshift をリアルタイム分析 アプリケーションの基盤として採用したユーザーは、この用途にはより最適化された ソリューションが必要だと気づくことになります。その結果、 優れたクエリ性能とデータ圧縮の恩恵を得るために、既存の Redshift ワークロードを 置き換える形、あるいは既存環境と並行して「スピードレイヤー」として導入する形で、 ClickHouse を採用するケースが増えています。

ClickHouse vs Redshift

AWS エコシステムに大きく依存しているユーザーにとって、データウェアハウジングの要件に対して Redshift は自然な選択肢です。Redshift はこの重要な点で ClickHouse と異なります。つまり、複雑なレポーティングや分析クエリを必要とするデータウェアハウジングのワークロード向けにエンジンが最適化されていることです。どのデプロイ形態でも、以下の 2 つの制約により、Redshift をリアルタイム分析ワークロードに利用するのは困難です。
  • Redshift はクエリ実行計画ごとにコードをコンパイルします。 これにより、初回のクエリ実行時に大きなオーバーヘッドが発生します。このオーバーヘッドは、クエリパターンが予測可能で、コンパイル済みの実行計画をクエリキャッシュに保存できる場合には許容できます。しかし、クエリが変化しやすいインタラクティブなアプリケーションでは課題となります。Redshift がこのコードコンパイル cache を活用できる場合でも、ほとんどのクエリで ClickHouse のほうが高速です。「ClickBench」を参照してください。
  • Redshift はすべてのキュー全体で同時実行数を 50 に制限しています。 これは BI には十分でも、高い同時実行性が求められる分析アプリケーションには不向きです。
一方、ClickHouse も複雑な分析クエリに利用できますが、アプリケーションの基盤としても、データウェアハウスの高速化レイヤーとしても、リアルタイム分析ワークロード向けに最適化されています。そのため、Redshift ユーザーは通常、以下の理由から Redshift を ClickHouse に置き換える、または ClickHouse を追加導入します。
利点説明
より低いクエリレイテンシClickHouse は、高い同時実行性の下でも、さらにストリーミング insert が発生している状況でも、多様なクエリパターンに対して低いクエリレイテンシを実現します。インタラクティブなユーザー向け分析では避けられないことですが、クエリが cache にヒットしない場合でも、ClickHouse は高速に処理できます。
より高い同時実行クエリ上限ClickHouse は同時実行クエリ数に対してはるかに高い上限を設定でき、これはリアルタイムなアプリケーション体験に不可欠です。ClickHouse では、セルフマネージドでも Cloud でも、各 service でアプリケーションに必要な同時実行性を実現できるよう、コンピュート割り当てをスケールアップできます。許可されるクエリの同時実行数は ClickHouse で設定可能で、ClickHouse Cloud のデフォルト値は 1000 です。
優れたデータ圧縮ClickHouse は優れたデータ圧縮を提供しており、総ストレージ使用量、ひいてはコストを削減できます。また、同じコストでより多くのデータを保持し、そこからより多くのリアルタイムなインサイトを得ることもできます。以下の「ClickHouse vs Redshift Storage Efficiency」を参照してください。
最終更新日 2026年6月10日