ClickHouse オンデマンドコンピュート

• オンデマンドコンピュートによるステートレスなクエリ実行
• 新しい CBO (オプティマイザ)
• 新しい分散クエリ実行

​

On-Demand Compute を使用するタイミング

• アドホッククエリおよび分析クエリ: コンピュート負荷の高い SELECT クエリを追加の worker で実行します。
• 重要度の低い読み取りワークロード: 一部の読み取り処理をプライマリサービスからオフロードします。
• データレイクへのクエリ: サポートされている Apache Iceberg、Delta Lake、または SharedMergeTree のデータに対して、追加の worker でクエリを実行します。
• 一時的な追加コンピュート: プライマリサービスのサイズを変更することなく、対象となるクエリ向けに worker をリクエストします。

​

仕組み

1. 対象となる SELECT クエリを、指定した数の worker を要求しつつ ClickHouse Cloud サービスに送信します。エンドポイント、認証、RBAC の設定を変更する必要はありません
2. 次に、クラスターがプールに接続し、指定された数の worker を要求します
3. worker は最低 60 秒間リースされ、クエリがそれより長く続く場合はリースが自動的に更新されます
4. worker はクエリを受け取り、実行します
5. その後、レスポンスがクライアントに返されます
6. worker は消去されます。

​

オンデマンドコンピュートの使用

​

Settings

​

例

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 0, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c1c96ede-0c4c-414f-b103-f27f0b7d34c7


Elapsed: 0.992 sec.

Received exception from server (version 26.9.1):
Code: 344. DB::Exception: Received from nuqae0jhz5.eu-west-1.aws.clickhouse-staging.com:9440. DB::Exception: make_distributed_plan cannot distribute this query: it contains the step ReadFromPreparedSource which could not execute remotely. (SUPPORT_IS_DISABLED)

SELECT count()
FROM nyctaxi.trips
SETTINGS distributed_plan_fallback_to_local_execution = 1, make_distributed_plan = 1, distributed_plan_workers_num = 5

Query id: c7b09855-e3c3-40ef-9790-5374e0726f26

   ┌─count()─┐
1. │   21932 │
   └─────────┘

1 row in set. Elapsed: 0.896 sec.

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0

​

同時実行クエリ

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;
SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 3, ...;

SELECT ... SETTINGS make_distributed_plan = 1, distributed_plan_workers_num = 5, ...;

​

プールがリクエストを満たせない場合

​

監視

​

割り当てられたworker数

SELECT
    ProfileEvents['StatelessWorkerRequested'],
    ProfileEvents['StatelessWorkerProvided']
FROM clusterAllReplicas(default, system.query_log)
WHERE query_id = '<YOUR_QUERY_ID>'
  AND type != 'QueryStart';

SELECT
    sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
    l_shipdate >= DATE '1994-01-01'
    AND l_shipdate < DATE '1994-01-01' + INTERVAL 1 YEAR
    AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
    AND l_quantity < 24
SETTINGS
    make_distributed_plan = 1,
    distributed_plan_workers_num = 5,
    enable_parallel_replicas = 0,
    log_comment = 'on-demand-private-preview'

​

利用可能なリージョン

​

料金

​

制限事項

• SELECT クエリのみ。 worker は INSERT クエリ、mutation、DDL、バックグラウンド処理を実行しません。
• サポートされるフォーマット。 プライベートプレビューでは Apache Iceberg、Delta Lake、SharedMergeTree をサポートします。
• 並列レプリカ。 並列レプリカは無効にする必要があります。
• worker のサイズ。 各 worker は 8 vCPUs と 32 GiB のメモリを備えています。
• worker の上限。 プライベートプレビュー期間中、1 クエリあたり最大 5 つの worker をリクエストできます。
• プール容量。 worker の割り当てはベストエフォートです。リクエストした数より少ない worker しか割り当てられない場合があります。利用可能な worker がない場合、クエリは失敗します。
• パフォーマンス。 パフォーマンスはクエリによって異なります。worker の割り当て、分散プランニング、plan ステージの転送によって latency が増加する可能性があります。クエリの形状によっては、プライマリ service で実行する場合よりも性能が低下することがあります (通常のサブ秒クエリは、おそらく自身のクラスターで実行したほうが高速です)
• クエリの互換性。 distributed planner はすべてのクエリプランをリモートで実行できるわけではありません。サポートされていないクエリでは SUPPORT_IS_DISABLED 例外が返される場合があります。

​

ロードマップ

• 既知の制限 (SUPPORT_IS_DISABLED のギャップ) の解消
• サイズの異なる worker の pool
• stateful 実行と同等のクエリパフォーマンスの安定化
• background merge のサポート
• 料金体系
• worker pool の autoscaler のキャリブレーション
• 組み込みのオブザーバビリティ
• On-Demand Compute 専用の permission
• データレイク workload の拡張 (書き込み、compaction など)

​

Security

• worker ごとに 1 つの service: worker は lease の期間中、単一の service に貸し出されます。2 つの service が同時に共有することはありません。
• service 間での再利用なし: lease が終了すると、その worker は破棄され、新しい worker に置き換えられます。worker が別の service に再割り当てされることはありません。
• 永続データなし: worker は永続ストレージを持たず、lease の終了後に存続することもありません。
• service と同一リージョン: worker は、それを lease する service と同じリージョンで実行され、厳格なデータ所在地ルールに従います。
• 既存のアクセス制御がそのまま適用: IP アクセスリストとプライベート エンドポイントは、これまでとまったく同じように service endpoint を制御します。On-Demand Compute によって、設定や保護が必要な endpoint が新たに増えることはありません。
• 既存の authentication と RBAC: クエリは、その service 上の他のクエリと同じ USER および privileges の下で実行されます。worker が独自の identity や permission モデルを持つことはありません。

​

ネットワーク分離

• worker に到達できるのは自分の service のみです。 path は、その worker の現在の lease と、その 1 つの service に対してのみ存在します。
• 未割り当ての worker には到達できません。 pool で待機中の worker は、lease されるまで、いずれの service との間にもネットワーク path を持ちません。
• 異なる service に lease された worker は相互に到達できません。 同一 lease 内の worker どうしは plan stages や中間結果を exchange しますが、異なる lease の worker は同じ pool を共有していても互いに分離されたままです。
• path は worker とともに削除されます。 lease を終了すると worker は破棄され、トラフィックの到達が許可されていた唯一の対象がなくなります。
• リクエストの path は最小限に保たれます。 service は、worker を lease および更新するために worker assignment service へ到達します。この path はクエリデータを一切運ばず、assignment API に限定されています。

​

内部の authentication と authorization

• worker ごとに 1 つの credential: worker がお客様の service に lease されると、プラットフォームは worker ごとに unique な signed token を発行します。各 token は、その 1 つの worker に対してのみ、かつお客様の service に対してのみ有効です。
• 短命で lease に紐づく: token は、それを生成した lease とともに失効します。lease を更新すると新しい token が発行され、lease が終了すると、その token では何も authentication できなくなります。
• プラットフォームに対して検証される: worker は、リクエストで渡された内容を信頼するのではなく、提示された token をプラットフォームの identity service に対して validate します。

​

よくある質問