共通の測定フレームワーク:
両システムとも、同一のソースデータセット、分析ワークロード、目標レートモデル、クエリスケジュール、結果フォーマットを使用しました。送信先固有のアダプターが配信とタイミングを処理しました。パート 1 では共通の手法を解説しており、Redshift のアーキテクチャには同プロバイダー向けの実装詳細が記録されています。
データセットと準備:
完全な NBBO データセットは、113,219,565,734 行の幅の狭い 12 カラムのデータで構成されています。生データのソートカラムは、銘柄記号とイベントタイムスタンプである (sym, t) です。日次サマリーには、銘柄記号と UTC 日である (sym, day) を使用し、行数、合計、価格の最小値・最大値を保持しました。
継続的なワークロード:
新しいイベントは毎秒 100 万件を目途に投入され、その間、集計クエリとドリルダウンクエリがそれぞれ 10 分間隔と 1 時間間隔のスケジュールで実行されました。これは、継続的に生成され、到着と同時に準備されるデータをモデル化しています。Redshift の集計クエリは最後に完了した日次 MV リフレッシュを読み取ります。取り込みの進捗を揃えても、そのスナップショットは ClickHouse の挿入時サマリーと同等の鮮度にはなりません。
推奨構成とサイジング:
ClickHouse Cloud は 16 CPU、64 GiB の読み取りノードを使用しました。Redshift は、ライブデータ共有 (datashare) で接続された個別のライターおよびリーダーワークグループを使用しました。リーダーは 32 RPU に固定しました。RPU はプロバイダーのキャパシティ単位であり、同一の CPU やメモリリソースを意味するものではありません。MSK は 3 台の kafka.m7g.xlarge ブローカー、24 パーティション、レプリケーションファクター 3、ブローカーあたり 500 GB のストレージを使用しました。
① 準備コスト:
このモデルには、ClickHouse の完全な 2 ノード HA 取り込みサービスと、Redshift のライターに加えて MSK ブローカーおよびストレージのコストが含まれます。採用されたライターキャパシティシナリオでは、プロデューサーの稼働時間全体にわたって 32 アクティブ RPU を計上しています。当初の長時間実行テストでは 128 ライター RPU を使用しましたが、その後の特性評価により、32 RPU で目標を維持でき、16 RPU では維持できないことが判明しました。コストは 32 RPU でモデル化されており、記録されたレイテンシと鮮度は長時間実行テストの数値を維持しています。
② クエリコストと ③ 実行時間:
ClickHouse は、記録されたクエリ実行時間を読み取り側のコンピュート料金に基づいて算出します。Redshift は、毎時間のリーダーの compute_seconds を、記録された経過時間の割合に応じて各ステートメントに配分し、その配分されたクエリコストを算出します。累積実行時間は、採用されたクエリ実行時間の合計です。この配分は、完全な請求書を再現するのではなく、クエリの処理負荷を表すためのものです。
目標レートと実際の測定レート:
Redshift の完了したテスト実行では、全 113,219,565,734 行を 113,227 秒 (約 31.45 時間) で取り込み、平均 毎秒 999,933 行を記録しました。ClickHouse は約 36.75 時間で取り込みを完了し、平均して毎秒約 86 万行でした。目標値は共通でしたが、実際の進捗には差が生じました。なお、Kafka への配信、ストリーミングビューへの反映、子 MV への反映は、それぞれ独立したマイルストーンです。
レポート対象期間:
クエリごとのレイテンシプロットは 1,000 億行の時点で終了しています。準備コストはプロデューサーの全稼働時間をカバーしており、累積クエリコストと実行時間は、参照エンドポイントを通じて得られたアクティブな取り込み時の有効な測定値を使用しています。その後のクエリ測定結果や鮮度サンプルは除外されています。また、ライターモデルには、後述する両方の子 MV リフレッシュ経路も含まれています。
料金の基準:
ClickHouse Cloud は、コンピュートユニット (CU) あたり 1 時間あたり $0.3903 を使用しています。Redshift はリポジトリに登録されている eu-west-2 の料金レート である $0.467/RPU-時を使用しています。MSK は 1 ブローカー時間あたり $0.47175、ブローカーストレージは 1 GB 月あたり $0.116 を使用しています。採用された完全経路サマリーには、モデルと高精度の入力値が保持されています。
① 完全な準備コスト:
フルパスシナリオには、113,227 秒のプロデューサー稼働時間全体にわたるライターコンピュート、MSK ブローカーの稼働時間、および日割り計算されたブローカーストレージが含まれます。ライターはストリーミング取り込み、バックグラウンドソート、および両方の子 MV のリフレッシュをカバーします。
ClickHouse Cloud:
2 CU × 36.75 時間 × $0.3903/CU-時 = $28.68705 (両方の HA 取り込みノードを含む)。
Redshift ライター:
32 アクティブ RPU のシナリオでは、32 × (113,227 ÷ 3,600) 時間 × $0.467/RPU-時 = $470.01785778 となります。長時間のテスト実行では 128 ライター RPU を使用しましたが、32 RPU のコストシナリオは、その後の追従性評価に基づいており、最初の実行時の請求額そのものではありません。
MSK:
3 ブローカー × プロデューサー稼働時間 × $0.47175/ブローカー時間 + 1,500 GB × $0.116/GB-月 × 稼働時間 ÷ 730 = 合計 $52.00912922。
共有準備経路:
ライター + MSK = $522.02698699。このスコアでは、この総額が 1 回請求されます。2 つの読み取り選択肢の間で分割されたり、比較内で二重に計上されたりすることはありません。
② 正規化クエリコスト:
ClickHouse は記録された実行時間に基づいて課金します。Redshift は、各時間のリーダーの SYS_SERVERLESS_USAGE.compute_seconds を、ステートメントの経過時間の割合に応じてその時間内に開始されたステートメントに配分し、採用されたクエリのシェアは $0.467/RPU-時で計算されます。
ClickHouse Cloud:
丸められたコストサマリーの入力値を使用すると、8 CU × $0.3903/CU-時 × (集計 10.207 秒 + ドリルダウン 47.915 秒) ÷ 3,600 ≈ $0.05041 となります。
Redshift 集計処理:
確定した時間ごとの配分では、760 回の集計クエリ実行に対して $2.955693203 が割り当てられます。これは、各クエリの実経過時間に一律の 32 RPU レートを乗算するのではなく、記録されたリーダーのコンピュート使用量とステートメントの実行時間を使用しています。
Redshift ドリルダウン処理:
66 回の実行に対して $22.011782831 が割り当てられ、正規化クエリコストの合計は $24.967476034 となります。2 つのワークロードを合わせると、53.4635461 RPU-時の割り当てリーダーコンピュートとなります。
配分の境界:
billed_times または billed_rpu_seconds と名付けられた履歴エビデンスフィールドには、1 時間あたりのコンピュート配分が保持されています。それらの名称は実際の請求書を証明するものではありません。データベースストレージ、クライアントの AZ 間転送、プロデューサー VM のコスト、割引、およびその後の取り込み完了後の測定値は、主要な集計スコープから除外されています。MSK のブローカーストレージは、準備コストのコンポーネントに含まれています。
③ 累積クエリ実行時間:
ClickHouse: 集計 10.207 秒 + ドリルダウン 47.915 秒 = 58.122 秒。Redshift: 集計 722.871916 秒 + ドリルダウン 5,370.670031 秒 = 6,093.541947 秒。
比較の対象範囲:
① では、プロデューサーの稼働時間全体と、設定された 32 RPU ライターモデルを使用します。② および ③ では、ストリーミングビューに対する 4 クエリの集計バッチ 190 回と、2 クエリのドリルダウンバッチ 33 回を使用します。ライターは型付きの子テーブルも維持しますが、型付きクエリの実行はこのスコアの対象外です。レイテンシの統計には、別途 1,000 億行の対象期間を使用しています。
最終スコア:
ClickHouse: ($28.68705 + $0.05041) × 58.122 = 1,670.27865。Redshift: ($522.02698699 + $24.967476034) × 6,093.541947 = 3,333,133.70523。その比率は 1,995.555 倍であり、四捨五入して 1,996 倍となります。
ClickHouse ライター使用率の結果は、バックグラウンドメンテナンスと並行して取り込みが継続していることを示しています。CPU 使用率は利用可能な 4 コアのうち約 3.1 コアにとどまり、追跡されたメモリはキャパシティ内に収まり、バックグラウンドマージは毎秒数百万行を処理し、パーティションあたりのアクティブパート最大数は約 100 で推移しました。これらの診断結果は、今回の比較で再利用された ClickHouse のソース実行時の状態を示しています。
高可用性のために両ノードが維持されたため、準備コストには 2 ノード構成全体のデプロイが含まれます。
同一の取り込み課題:
ソースは高頻度の書き込みを生成し、それを効率的な分析用ストレージへと変換する必要があります。ClickHouse はネイティブな非同期挿入を通じてこれらを受け入れます。Redshift の推奨される高レートストリーミングパスには、MSK ブローカークラスターとそれを取り込むライターワークグループが含まれ、どちらも準備コストに計上されます。
Redshift のストリーミングパス:
プロデューサーは 16 プロセスと lz4 圧縮を使用しました。MSK は 3 つのアベイラビリティゾーンにわたる 3 つのブローカー、24 パーティション、レプリケーション係数 3 を提供しました。Redshift はストリームを直接取り込み、中間の S3 ロードジョブは追加しませんでした。
ClickHouse のネイティブパス:
async_insert を有効にした通常の INSERT リクエストは、受信側の各ノードでバッファリングされました。適応型フラッシュタイムアウトが受信トラフィックに応じて対応しました。順序付けと事前集約は取り込みノード上で実行され、専用の取り込みサービスは、独立してサイジングされた読み取りサービスとストレージを共有しました。
共通のペーシング:
両方のアダプターは同一の Parquet データセットを読み取り、同一の目標レートモデルのもとで同一のスキーマをデコードしました。並列度とクライアントのバッチサイズは、各送信先の API に合わせて調整されており、強制的に同一にされたわけではありません。
ClickHouse のバッチ:
クライアントは非同期挿入を通じて 3,000 行のバッチを送信しました。デフォルトのバッファリングでは、100 MiB のバッファ到達、50 ミリ秒から 1 秒の間の適応型タイムアウト、または 450 件のキュー内挿入クエリという 3 つのしきい値のうち、最初に達した時点でフラッシュされました。
Redshift の配信:
プロデューサーのアクノリッジメントは Kafka への配信を報告するものであり、すべてのダウンストリームビューの完了を意味するものではありません。ストリーミング取り込みは生のストリーミングビューを更新し、個別のリフレッシュトランザクションが型付きプロジェクションと日次サマリーを更新します。
バッチサイズの境界:
クライアントの INSERT バッチと Kafka バッチは転送単位です。これらは最終的な MergeTree パート、Redshift ストレージブロック、または日次 MV リフレッシュサイズを定義するものではありません。
進捗とリフレッシュのエビデンス:
モニターは取り込み中に SYS_STREAM_SCAN_STATES をサンプリングし、子リフレッシュをジャーナルに記録しました。これらの特定時点の観測結果はワークロードの実行中に記録されたものであり、実行後のビューから再構築されたものではありません。
インクリメンタルメンテナンス:
2 つの子 MV は quotes_streamed 上に直接定義され、RESTRICT でリフレッシュされます。リフレッシュジャーナルのサーバーステータスがインクリメンタル更新であることを識別します。Manual や Auto といったラベルだけでは、インクリメンタルリフレッシュかフルリフレッシュかを判断できません。各子は独立してリフレッシュされます。
ライターキャパシティの境界:
図の 32 RPU は、採用されたキャパシティシナリオに基づいています。特性評価において、32 RPU は中央値約 5 秒のストリーミングラグで目標を維持できましたが、16 RPU では遅れが生じました。長期測定は 128 RPU のライターで記録されました。32 RPU で価格を算定したからといって、それらのレイテンシや鮮度の測定値が 32 RPU での再実行結果になるわけではありません。
Redshift 系列:
鮮度のエビデンスには、アクティブなエンドポイントを介した成功した日次リフレッシュ記録を使用しています。これはリフレッシュ完了の間隔だけでなく、日次 MV に反映された Kafka イベントウォーターマークを測定します。ラグサンプラーが行の進捗タイムラインを提供します。
統計と表示:
アクティブな日次 MV 系列には 1,884 件の観測値が含まれ、ラグは中央値で 46 秒、P95 で 53 秒、最大で 79 秒でした。グラフには中央 5 件の観測値による移動中央値を適用しており、表示される曲線は約 64 秒に達します。最初の非単調なラグサンプルと、取り込み後の 463 件の日次リフレッシュは除外されています。
ClickHouse のベースライン:
ゼロラインはベンチマークのセマンティクスに基づく生データからサマリーへのベースラインであり、個別にポーリングされたソースからクエリへのメトリクスではありません。生テーブルとインクリメンタル MV は、フラッシュされた同一の挿入ブロックを消費します。これは取り込み遅延がゼロであると主張するものではなく、Redshift 系列と同じソースウォーターマークの境界を使用するものでもありません。
スナップショットの規約:
クエリは日次 MV のコミットされたコンテンツを読み取ります。ベンチマークでは、クエリのたびに強制的にリフレッシュを行ったり、より新しいストリーミング行から結果を再構築したりはしませんでした。したがって、測定された集約レイテンシには、Redshift のサマリーリフレッシュのラグが含まれます。
リフレッシュの規約:
AUTO REFRESH YES がストリーミング取り込みを駆動します。Redshift は別の MV 上に定義された MV に対する自動リフレッシュを許可しないため、コントローラーがダウンストリームの MV を個別にリフレッシュします。RESTRICT は、コミットされた親の状態から指定された子のみを更新します。これにより、型付きプロジェクションのリフレッシュ遅延が日次サマリーの鮮度に累積するのを防ぎます。
ライブ共有の規約:
共有によって、ライターのコミットされたオブジェクトがリーダーワークグループに公開されます。これにより読み取りコンピュートと準備コンピュートが分離されますが、オブジェクトがより最新になるわけではなく、クエリがアクセスする前に最新の行がソートされるわけでもありません。
読み取りパスの境界:
主要なドリルダウン結果はライブストリーミングビューから取得したものです。代替手段として型付きプロジェクションも維持され、測定されました。そのクエリ実行はこの記事のスコアからは除外されていますが、そのリフレッシュとストレージレイアウト処理は共有の準備シナリオに残されています。
サイジングの境界:
リーダーは長期実行中、base=max 32 RPU に固定されました。ライターのキャパシティは準備コストのために個別にモデル化されています。スコアは、これらの宣言されたコスト前提と記録された読み取りパスの結果を組み合わせたものであり、プロバイダーの文字通りの請求書として提示しているわけではありません。
クエリの定義:
パート 1 では A1〜A4 と D1〜D2 について説明しています。Redshift の SQL は、エンジン固有の置換を行いつつ、シンボルフィルターと全履歴のスコープを維持しています。D1 は最初と最後の価格を取得するためにウィンドウ関数を使用し、D2 は近似離散パーセンタイルとモーメント計算を使用します。超過尖度の規約が ClickHouse の生の母集団尖度とは異なるため、そのフィールドに関する厳密な数値的等価性は主張していません。
キャッシュポリシー:
enable_result_cache_for_session はオフでした。基盤となるデータキャッシュは通常通り動作することが許可され、ベンチマークではクエリ間でそれらをフラッシュしませんでした。
タイミング:
Redshift のレイテンシには秒単位に変換した SYS_QUERY_HISTORY.elapsed_time を使用し、ClickHouse には記録されたランナーの所要時間を使用しています。中央値、P99、最大値は、0 < raw_rows ≤ 1,000 億の平滑化されていないクエリごとの観測値をプールしたものです。P99 は線形補間を使用しています。累積ランタイムも同じ記録されたタイミング基準を使用しています。
レイテンシグラフ:
各システムは、それぞれ観測された取り込み進捗の位置にプロットされています。集約の傾向線には中央 7 件の観測値による移動中央値を使用し、ドリルダウンにはエッジウィンドウを縮小させた 5 件の観測値を使用しています。外れ値は除外していません。曲線は表示上の平滑化であり、統計と累積合計には元々記録された所要時間を使用しています。
インタラクティブな読み取り値:
プロットの下の値は、選択した行数における表示傾向に従います。対数スケールによりミリ秒と秒を一緒に読み取ることができ、線形スケールは絶対的な差異を示します。各グラフには独自の再生コントロールと行位置コントロールがあります。
採用された累積ワークロード:
抽出されたデータには、システムごとに 190 回の 4 クエリ集計バッチと、ストリーミングビューに対する 33 回の 2 クエリドリルダウンバッチ(760 + 66 = 826 回の実行)が含まれます。ClickHouse の観測値は、1,132 億 1,956 万 5,734 行の基準範囲を通じて、Redshift の行の進捗に単調に揃えられています。その後の取り込み後の観測値は除外されています。
累積グラフ:
クエリの所要時間は、将来の実行を前の位置に平滑化したり補間したりすることなく、対応する取り込み件数の時点でステップ合計として加算されます。準備コストの線は、取り込み全体の合計を行の進捗に応じて比例配分したものであり、時間ごとの従量課金コストの追跡ではありません。スコアは取り込み経過時間ではなく、クエリの所要時間を合計したものです。
ストリーミングビュー:
ストリーミングビューはペイロードを SUPER として保持し、sym と t を型付きソートキーカラムに昇格させます。D1 と D2 は型付きの sym カラムをフィルタリングしてプルーニングの意図を維持し、結果を計算する際にペイロードのメジャーフィールドをキャストします。これは、ClickHouse の型付き生テーブルとは異なる表現です。
型付きの代替手段:
兄弟関係にある型付き MV は、同一の (sym, t) ソートキーと EVEN 分散を使用して、ペイロードフィールドをカラムに射影します。そのクエリは同じ Redshift ドリルダウンロジックを実装しています。長期実行中には両方の表現が測定されました。
観測された結果:
アクティブな取り込みの比較において、型付きの代替手段はストリーミングビューの 2.11 倍のドリルダウンランタイムを累積しました。D1 はほぼ同等でしたが、D2 は型付きデータ上で 4.42 倍低速でした。本記事では、測定結果がより高速であったストリーミングビューを読み取る代替手段を採用しています。
コストの境界:
ライターと MSK の準備コストには両方の子リフレッシュが含まれており、読み取りの代替手段間で変更なく共有されます。ストリーミングビューのスコアには、型付きクエリの実行を追加するのではなく、その集約およびドリルダウンクエリの割り当て分のみが請求されます。
解釈:
ベンチマークは、記録された完全なクエリ結果を測定します。バックグラウンドソート、ペイロードナビゲーション、クエリの構築、またはその他のエンジン処理に起因するギャップの大きさを個別に分離するものではありません。完全な実行結果が異なることを示している場合、短時間の特性評価から型付きレイアウトの方が高速であると想定することはできません。