0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@asahide

ClickHouse の取り込み、サイズを上げる前にやること

0
Posted at

1. はじめに

1.1. 背景

分析基盤では「データを取り込みながら、集計結果も最新に保つ」構成をよく作ります。生データを貯めるだけなら取り込みは単純ですが、実際にはダッシュボードやアラートが参照する集計テーブルも同時に更新したい、という要件が付いてきます。

ClickHouse でこれを実現する標準的な方法がマテリアライズドビュー（以下 MV）です。ClickHouse の MV は定期的に作り直すものではなく、INSERT をトリガとして動きます1。挿入されたデータのブロックに対して集計の SELECT が走り、その結果が集計テーブルへ書き込まれます。取り込んだ瞬間に集計が更新されるので、参照側は常に最新の値を読めます。

裏を返すと、MV の更新は取り込み処理の一部です。取り込みが遅いとき、その時間には MV の更新も含まれています。

今回は暗号資産の約定データを取り込みながら、1 分ごとの値動きのまとめを MV で更新する構成を作りました。1 分の間の始値・高値・安値・終値と出来高（OHLCV と呼ばれます）、それに取引金額を出来高で割った平均価格（VWAP）です。チャートを描くときの基本的な単位で、生の約定データを毎回集計し直すと重いため、事前に集計しておく対象の典型例になります。

公式ブログには、取り込みスループットは CPU コア数に対して線形にスケールするという記述があります2。取り込みが遅いときにサービスサイズを上げるという判断は、この記述を根拠にできそうです。ただし MV を付けた構成でも同じように当てはまるのかは書かれていません。 そこを実測したのが今回です。

1.2. 今回の検証ゴール

# 検証したいこと 確認できれば OK の状態
1 サービスサイズを上げると取り込みが速くなるか 8 / 16 / 30 vCPU で同じデータを取り込み、行毎秒を比較できる
2 取り込み時間の内訳はどうなっているか 読み取り・パース・書き込み・MV の各段階の所要時間を分離できる
3 速くする方法があるか 基準に対する短縮率と、集計結果が変わっていないことを示せる

1.3. 結論の先出し

  • サイズを上げても速くならなかった。1 本の INSERT で測ると、8 vCPU が 36.36 秒、30 vCPU が 37.88 秒。CPU は 8 コア中 3 コア分しか使われていない
  • 原因は MV。MV を外すと同じ取り込みが 4 分の 1 の時間で終わる。MV を 1 つでも付けると INSERT 全体が単一ストリームで処理されるためで、集計の中身は関係ない
  • 並列に投げると、そこで初めてコア数の差が出た。8 vCPU は CPU を使い切って 8.45 秒で頭打ち、30 vCPU は 4.14 秒まで短くなった

コア数に線形にスケールするという公式の記述は、並列に投げていれば当てはまります。単一の INSERT のままサイズだけ上げても、その効果は得られませんでした。

2. 検証環境

項目 内容
サービス ClickHouse Cloud 26.2.1.525
リージョン AWS ap-northeast-1（東京）
サイズ 8 vCPU / 32 GiB と 30 vCPU / 120 GiB（各 2 レプリカ）
データ Binance 公開アーカイブの約定データ（Spot / 日次 / ZIP 圧縮 CSV）

計測対象は 1 シンボル 108 ファイル、83,946,164 行です。データは同一リージョンの S3 にあるため、取り込みはローカル環境の影響は受けません。s3() テーブル関数でサーバー側から直接読んでいます。

測定中にサイズが変わらないよう、オートスケールは無効にしてあります3。

3. 取り込み経路の構築

3.1. テーブルと MV

約定データを受ける生テーブルと、1 分足の OHLCV と VWAP を持つ集計テーブルを作ります。集計テーブルは AggregatingMergeTree で、始値と終値は argMin / argMax で取ります。

CREATE TABLE ingest_bench.trades
(
    symbol          LowCardinality(String),
    trade_id        UInt64,
    price           Float64,
    qty             Float64,
    quote_qty       Float64,
    ts              DateTime64(3),
    is_buyer_maker  Bool,
    is_best_match   Bool
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (symbol, ts);

パーティションは日次だと細かすぎるため月次にしてます4。

集計テーブルへ書き込む MV は次のとおりです。集計は挿入されたブロックの単位で閉じるため、ブロックをまたいだ再集計は行われません。そのぶんは AggregatingMergeTree が後段のマージでまとめます。

CREATE MATERIALIZED VIEW ingest_bench.trades_1m_mv
TO ingest_bench.trades_1m
AS
SELECT
    symbol,
    toStartOfMinute(ts)     AS minute,
    argMinState(price, ts)  AS open,
    maxState(price)         AS high,
    minState(price)         AS low,
    argMaxState(price, ts)  AS close,
    sumState(qty)           AS volume,
    sumState(quote_qty)     AS quote_volume,
    countState()            AS trade_count
FROM ingest_bench.trades
GROUP BY symbol, minute;

VWAP の分子には quote_qty をそのまま使えます。元データの quote_qty が price × qty と一致することを実データで確認したため、掛け算を省いています。

3.2. 取り込み

ZIP アーカイブの中の CSV は :: 記法で直接読めます。

INSERT INTO ingest_bench.trades
SELECT 'SOLUSDT', trade_id, price, qty, quote_qty,
       fromUnixTimestamp64Micro(toInt64(time)) AS ts, is_buyer_maker, is_best_match
FROM s3('https://s3-ap-northeast-1.amazonaws.com/data.binance.vision/data/spot/daily/trades/SOLUSDT/SOLUSDT-trades-2026-07-*.zip :: *.csv',
        NOSIGN, 'CSV',
        'trade_id UInt64, price Float64, qty Float64, quote_qty Float64, time UInt64, is_buyer_maker Bool, is_best_match Bool');

4. 単一の INSERT ではコア数を増やしても速くならない

まず素直に、同じデータを 2 つのサイズへ 1 本ずつ投げます。

サイズ 取り込み時間 万行/秒
8 vCPU / 32 GiB 36.36 秒 231
30 vCPU / 120 GiB 37.88 秒 222

各 3 回の平均で、差は 4% です。コア数を 3.75 倍にして 1 秒も速くなりませんでした。

3 サイズ（8 / 16 / 30 vCPU）で 501,282,394 行を取り込む形でも同じ傾向でした。INSERT が使ったスレッド数の合計は 17 から 61 までコア数に比例して増えているのに、行/秒は 228 万から 218 万へむしろ微減しています。スレッドは確保されているのに仕事が増えていません。

5. どこに時間が消えているのか

処理を段階的に追加しながら測りました。同じデータ、同じサービス（30 vCPU）です。

段階 処理内容 所要
読み取りのみ SELECT count() 1.6 秒
読み取り＋パース Null エンジンへ投入 3.2 秒
＋ MergeTree への書き込み MV なしのテーブルへ INSERT 9.8 秒
＋ MV 本番と同じ構成 37.9 秒

読み取りのみの値は count() が全列をパースしない最適化を含むため、下限として扱います。パース込みで評価できるのは Null エンジンへの投入までです。

読み取りとパースは 16 vCPU から 30 vCPU で 26% 短くなり、コア数の恩恵を受けています。ところがその部分は全体 37.9 秒のうち 3.2 秒で、8% しかありません。残りの大半を占める MV の処理が短くならないため、総時間が変わりませんでした。

5.1. MV を外すと処理時間は 4 分の 1 に

MV の有無だけを変えて比較します。比較用のテーブルは CREATE TABLE ... AS で作っており、エンジンもソートキーもパーティションも同一です。

サイズ MV あり MV なし MV のぶん 割合
16 vCPU 37.8 秒 9.3 秒 28.5 秒 75.4%
30 vCPU 37.9 秒 9.83 秒 28.07 秒 74.1%

MV を外すと 37.9 秒が 9.83 秒になります。取り込み時間のうち MV のぶんが 28 秒あり、全体の 74% を占めていました。各 3 回でばらつきは 3% 以内で、割合も絶対値も安定しています。

MV が取り込みコストを押し上げること自体は既に報告があります。Altinity は 2022 年に、MergeTree に単一の MV を付けた場合の挿入スループット低下を 38〜55% と測っています5。今回の 74% はそれより大きい値ですが、同じ現象と考えてます。

5.2. CPU が余っている

30 vCPU の環境で 1 本の INSERT を流している間、CPU 使用量は上限 30 コアに対して 5〜10 コアで推移していました。8 vCPU の環境で測ると、片方のノードが 8 コア中およそ 3 コア分を使い、もう片方はアイドルです。

もう片方がアイドルなのは、s3() の取り込みが 1 ノードでしか動かないためです。ファイル一覧を各ノードへ配る s3Cluster はアーカイブを開けなかったので（7 章）、素の s3() を使っており、取り込みは 1 ノードに閉じるため、 2 レプリカの半分は使われません。

管理画面の推奨サイズ欄には、30 vCPU で運用している状態に対して 7 vCPU が表示されていました。推奨値は CPU 使用率の実測から目標使用率 53% で逆算されているようです6。

30 vCPU で運用中の画面。推奨サイズは 7 vCPU、CPU 使用量は上限 30 コアに対して 5〜10 コアで推移している

動いているノードの「およそ 3 コア」の中身も見ておきます。log_query_threads を有効にして 1 本の INSERT のスレッド別 CPU 時間を取ると、この INSERT が使ったのは 2.34 コア分でした。残りは背景マージです。同じ時間帯の part_log に 14 回・7,720 万行ぶんのマージがあり、0.82 コア相当を使っています。2.34 と 0.82 を足すと 3.16 コアで、管理画面の値と合います。

取り込み自体は 2.34 コアしか使えていません。1 本の INSERT が単一ストリームで処理されているためですが、その理由は 6.1 章で扱います。

このあと 6 章で並列度を上げますが、そこでも上限 30 コアに対して 12 コア程度までしか上がりませんでした。

並列度を上げた時間帯の CPU 使用量。上限 30 コアに対してピークで 12 コア程度

5.3. MV 専用の計測値では 13% と出る

ClickHouse には MV ごとの所要時間を記録するテーブルがあります7。この値を見ると、MV は取り込み時間の 13.2% しか使っていません。5.1 で測った 74% とは 5.7 倍ずれています。

18 回の計測すべてで 13% 台と安定していたため、MV を外して比べるまで気づきませんでした。このずれには理由があります（8.3 章）。

6. 並列に投げると、そこで初めてコア数の差が出る

CPU が余っているなら、投げる側を増やせば埋まるはずです。108 ファイルを N 分割し、N 本の INSERT を同時に実行しました。

並列度 8 vCPU 30 vCPU 両者の比
1 36.36 秒 37.88 秒 0.96
2 21.67 秒 21.95 秒 0.99
4 17.03 秒 12.56 秒 1.36
8 12.51 秒 7.92 秒 1.58
16 9.13 秒 5.36 秒 1.70

並列度 1 と 2 ではサイズの差が出ません。 並列度 4 のあたりから差が開き始め、並列度 16 では 1.70 倍になります。

8 vCPU 側は並列度 16 で 8 コア中 7.0〜8.15 コアを両ノードで使い切っており、ここが頭打ちでした。30 vCPU 側は並列度 24 で 4.18 秒まで伸び、まだ頭打ちになっていません。

並列効率は下がり続けます。並列度 8 で 60%、16 で 44%、24 で 38% です。効率が目に見えて落ち始めるのは 8 から 12 のあたりでした。

管理画面の推奨サイズも、8 vCPU に戻したあとは現在のサイズと一致しました。30 vCPU のときに 7 vCPU を推奨していたのと対照的です。

8 vCPU に戻したあとの画面。推奨サイズが現在のサイズと一致し、CPU 使用量は上限 8 コアに対して 5〜8 コアで推移している

同じ画面のレプリカ数のグラフには、リサイズの最中に 2 台から 4 台へ増えて戻る動きが記録されています。新しいレプリカを追加してから古いレプリカを削除する方式によるものです8。

6.1. 設定 1 行でも 3.62 倍になる

parallel_view_processing を有効にすると、単一の INSERT のままでも 37.88 秒が 10.48 秒になりました。ClickHouse Cloud のデフォルト値は 0 です。

SET parallel_view_processing = 1;

ドキュメントの説明は「複数の MV を並列に処理するか」で9、MV が 1 本の今回は差が出ないはずです。ところが 26.2 の実装では、この設定は INSERT のストリーム数を変えるだけで、MV が 1 本でも存在すればストリーム数が 1 に固定されます。本数は見ていません。スレッド別に見ても、MV を足すと実効並列度が 4.97 から 2.34 コアへ半減しており、この固定と合います。

つまりこの設定自体で並列化されるわけではありません。有効にしたまま max_insert_threads を 1 に絞ると 37.47 秒で、無効時の 38.73 秒と変わりませんでした。速くしているのは max_insert_threads で、parallel_view_processing はそれを使えるようにする鍵です。3.62 倍は Cloud のデフォルト値 4 と釣り合います。

ドキュメントの説明と実装が食い違っています。ClickHouse 側も認識していますが、修正はまだ入っていません10。挿入経路はバージョン差が大きいため、導入前にご自身の環境で確認することをおすすめします。

2 つの方法は同じことをしている

並列 INSERT とこの設定は、どちらも MV の計算を複数のスレッドに分けて同時に走らせる点で同じです。MV は挿入ブロックごとに計算されるので、もともと分割できます。単一ストリームだと 1 個ずつ順番に処理されるだけでした。

違いは分け方です。並列 INSERT は N 本の INSERT を並べて各自が担当ぶんの MV 計算を処理し、parallel_view_processing は 1 本の INSERT の内部を複数ストリームに割ってその中で分散させます。本数で分けるか 1 本の中で分けるかの差で、CPU を使い切る度合いは変わりません。

分け方が違っても結果が一致するのは、MV がブロックごとに部分的な集計状態を作り、AggregatingMergeTree が後段のマージでまとめるためです。どう分割しても、最後に統合すれば同じ 155,520 行になります。

6.2. パーツは問題にならなかった

CPU を使い切るほど並列で流し込むと、パーツの増えすぎが心配になります。実際には 1 パーティションあたりのパーツ数はピークで 65 でした。挿入が遅延され始めるしきい値は 1000 なので11、15 分の 1 の水準です。

並列取り込み中の詳細メトリクス。1 パーティションあたりのパーツ数はピークで 65、メモリは 32 GiB に対して 4〜8 GiB で推移している

メモリも 32 GiB に対して 4 GiB から 8 GiB で、制約になっていません。ディスクからの読み取りが 80 KB/秒どまりでファイルシステム経由が 900 MB/秒に達しているので、読み取りはほぼキャッシュから返っています。

6.3. 効果がみられなかった案

効果がみられなかった案も挙げておきます。

  • max_insert_block_size を上げても変化はありませんでした。名前からブロックの大きさを決めていそうに見えますが、26.2 の挿入経路にこの設定への参照はありません。ブロックをまとめる処理は min_insert_block_size_rows だけを見ています。実測でも、min 側だけを上げれば 37.72 秒が 26.78 秒（1.41 倍）になり、max 側は単独でも併用でも差を生みませんでした

  • optimize_on_insert を 0 にする手も差が出ませんでした。並列と併用したときに 9% 程度の差が出ますが、ばらつきに対して小さく、確実とは言えません

  • 集計状態を軽くする手も外れました。argMinState / argMaxState は値とタイムスタンプの両方を保持するため重いと考え、SimpleAggregateFunction にできる 5 つを置き換えた版を作りましたが、差は出ませんでした。挿入時のコストに差が出る根拠は公式にも見当たらず、なぜ変わらないのかまでは確かめられていません

3 つとも外れた一方、短くなったのは並列 INSERT と parallel_view_processing の 2 つだけです。MV のコストは集計の中身ではなく、INSERT が単一ストリームになることにありました。

6.4. 結果は変わっていない

最速構成は 30 vCPU で 4.14 秒、基準の 37.9 秒に対して 9.15 倍です。8 vCPU では 8.45 秒で 4.30 倍でした。

全 28 条件について、取り込み後の行数 83,946,164 と集計テーブルの 155,520 行、および総約定数・VWAP・高値安値・始値終値の合計が完全に一致しています。速くなっただけで、失われたものはありません。

optimize_on_insert を 0 にした場合だけ挿入直後に保存される行数が変わりますが、マージ後に 155,520 行へ収束し、読み出した集計値は同じでした。

6.5. 費用で見るとどちらが有利か

ClickHouse Cloud は時間単価を公表していません。ただしコンピュートはメモリ量に比例して課金されると明記されているため12、同じティア・同じリージョンなら割り当てメモリの比が単価の比になります。

8 vCPU / 32 GiB 30 vCPU / 120 GiB
メモリ（2 レプリカ計） 64 GiB 240 GiB
単価の比 1.00 3.75
最速構成の所要 8.45 秒 4.14 秒
同じ処理にかかる費用の比 1.00 1.84

同じ量を取り込むなら、小さいサービスを並列で回すほうが 1.84 倍安く済みます。 速いのは大きいほうですが、速さの伸び（2.04 倍）が単価の伸び（3.75 倍）に追いついていません。

料金の側は線形です。メモリを 3.75 倍にすれば料金も 3.75 倍で、垂直に大きくしても水平に増やしても総量が同じなら同じ、という一般的な考え方は成り立っています。

線形でないのは性能のほうでした。並列効率は並列度 2 で 86%、8 で 60%、16 で 44%、24 で 38% と落ちていきます。並列化できない部分が残る限り、リソースを増やしても見返りは小さくなります。 これは ClickHouse に限らず、並列化に上限がある処理すべてに当てはまります。

ただしこの計算が当てはまるのは、取り込みという 1 つの処理だけを速くしたい場合です。同じサービスで分析クエリも動いていて、取り込みがそれを遅くしているような状況なら、判断は変わります。奪い合いを緩めること自体に意味があるので、余裕を持たせる目的でサイズを上げるのは理にかなっています。

締め切りのある処理でも同じです。割高でも所要時間の短い構成を選ぶ理由はあります。なおこの試算にストレージ課金は含めていません。

7. ハマりどころ

公開データを ZIP のまま読む構成で踏んだものです。

圧縮サイズ 20 MiB を超える ZIP が読めません。 s3() でアーカイブを読むとき、20,971,520 バイトを超えると CANNOT_UNPACK_ARCHIVE になります。これは既知の不具合で、26.7.1.126 で修正されています13。検証に使ったのは 26.2.1.525 のため踏みました。WHERE _size による事前の絞り込みは展開後に評価されるため使えません。修正前のバージョンを使う場合は、'One' フォーマットで一覧とサイズだけを取り、読めるファイルを明示列挙する必要があります。

s3Cluster はアーカイブをリモートノードで開けません。 文言が unpack ではなく open、実行段階が Remote で、ファイルサイズによらず失敗します。上の 20 MiB とは別の症状です。ClickHouse 側にもアーカイブとクラスタ関数の組み合わせを検証課題として挙げた issue がありますが、未着手のまま残っています14。レプリカが 1 台のサービスでは他のノードへ処理を渡さないため成功してしまい、複数レプリカのサービスへ移して初めて表面化しました。

ワイルドカードは path 形式のエンドポイントでしか動きません。 これは不具合ではなく仕様です。ClickHouse は URL のホスト名を既知のサービス名のリストと照合してバケット名を決めており、data.binance.vision のような独自ドメインは対象外です。そのため https://data.binance.vision/data/spot/... を渡すと、ホスト直下の最初のパスセグメント data がバケット名として扱われます。単一ファイルの取得は組み立て直した URL が結果的に正しくなるため通りますが、glob の展開に必要な一覧取得は存在しないバケットへ発行されて失敗します。ブレース展開は列挙なので一覧取得が不要で、こちらも通ってしまいます。ブレースで動作確認してワイルドカードに変えた瞬間に壊れる、という順序で踏みやすい構図です。

なお 26.4 で URL の解釈方法を指定する設定が追加されているため、新しいバージョンでは独自ドメインでも扱えるようです。

同じデータソースでも時期によって単位が変わります。 Binance の約定データのタイムスタンプは 2017 年がミリ秒、2025 年以降がマイクロ秒でした。列の定義確認を最も古いファイルで行ったため、ミリ秒前提の変換式で全行が DateTime64 の上限に張り付きました。サンプルに最古のファイルを選ぶのは、フォーマットが安定している保証がないぶん危険です。

8. 考察

8.1. 公式の主張と実測の関係

取り込みスループットが CPU コア数に線形にスケールするという記述は、並列 INSERT を前提としています。公式ドキュメントにも、サーバーは INSERT を並行して実行でき、クライアント側で複数スレッドを走らせる方法が示されています15。

今回の結果はこれと矛盾しません。並列度 1 と 2 ではサイズによる差が出ず、並列度 4 から差が開き始め、小さいサイズのほうが先に CPU を使い切って頭打ちになりました。コア数を増やせばスケールします。スケールし始めるために並列度が要る、という条件が付くだけです。

見落としやすいのは、単一の INSERT では 8 コア中 3 コアしか使わない点です。この状態でコア数を増やしても、増えたぶんは使われません。

8.2. 推測は 3 回外れた

スレッドが増えても仕事量が増えないという観測から、待たされている先を順に調べました。表の秒数は計測した run のもので、37〜38 秒台のばらつきがあります。各行は同じ run の中での前後比較として見てください。

推測 検証方法 結果
S3 の読み取り帯域が天井 読み取りだけを計測 外れ。1.6 秒しかかからない
ダウンロードの並列度が足りない max_download_threads を 4 から 32 へ 外れ。38.3 秒が 38.2 秒
挿入スレッド数が足りない max_insert_threads を 4 から 16 へ MV なしでは短縮するが、MV ありでは変わらない
MV があると INSERT が単一ストリームになる MV あり・なしの比較 当たり

読み取り帯域を疑ったのは、50 GiB を 220 秒で読んだ計算がサイズによらず毎秒 230 MB 前後で一定だったためです。もっともらしい数字でしたが、読み取りだけを切り出すと 1.6 秒でした。全体が一定だったのは、支配的な部分が一定だったからにすぎません。

設定値を 1 つずつ動かすより、処理を段階的に足していく分解のほうが早く原因にたどり着きました。各段階の差分がそのままコストになるためです。

8.3. 13% と 74% はどちらも正しい

view_duration_ms は MV の実行時間で、ターゲットテーブルへの書き込みも含みます。MV が自分で使った時間としては正しい値です。

一方、MV を外すと全体が 74% 短くなります。この 74% には 2 つのものが混ざっています。MV が自分で使った時間（13%）と、MV があるせいで INSERT 全体が単一ストリームになり、使えなくなった並列度です。後者は MV が使った時間ではないので、view_duration_ms には現れません。

max_insert_threads だけを変えて測ると、view_duration_ms は 4.9 秒から 5.8 秒とほとんど動かないのに、全体に占める比率は 13% から 42% へ変わります。動いているのは分母のほうです。

MV に払っているコストを知りたければ、MV の実行時間ではなく、MV を外したときとの差を見る必要があります。 機能の実行時間と、その機能があることで全体に生じる影響は別物でした。

9. まとめ

  • 単一の INSERT では、サイズを上げても取り込みは速くならない。MV を 1 つ付けた時点で INSERT が単一ストリームに固定されるためで、集計の中身は関係ない
  • 対処は 2 つ。INSERT を並列に投げるか、parallel_view_processing を有効にして max_insert_threads を使えるようにするか。どちらも MV の計算を複数スレッドに分けて走らせる点は同じ
  • 並列に投げると両方のサイズが短くなり、そこで初めてコア数の差が出る。8 vCPU は CPU を使い切って 8.45 秒で頭打ち、30 vCPU は 4.14 秒まで短くなった

取り込みが遅いときは、サイズを上げる前に投げ方を見直すのが先でした。CPU を使い切ってもまだ足りないと分かってからサイズを検討するほうが、費用の面でも順序として合っています。

参考

  1. CREATE VIEW の Materialized View の項。集計は挿入ブロック単位で閉じ、ブロックをまたいだ再集計は行われません。 ↩

  2. Supercharging your large ClickHouse data loads – Part 2。取り込みスループットが CPU コア数に対して線形にスケールすることが示されています。 ↩

  3. Vertical autoscaling に、最小メモリと最大メモリを同値にすると設定を固定できると記載があります。 ↩

  4. MergeTree settings の max_parts_in_total の説明に、パーティションを小さく切りすぎることが設計上の誤りとして挙げられています。 ↩

  5. Performance impact of materialized views in ClickHouse（Altinity、2022 年 12 月）。MergeTree に単一の MV を付けた場合の挿入スループット低下を 38〜55% と報告しています。 ↩

  6. Scaling recommendations に、目標使用率 53% と recommended_cpu = max_cpu_usage / target_utilization の算出式が示されています。 ↩

  7. system.query_views_log は、クエリ実行時に走った依存ビューの情報を記録します。 ↩

  8. Make Before Break に「New replicas are added to the cluster before removing old replicas from it」と記載があります。 ↩

  9. Incremental materialized view の Parallel vs sequential processing の項。 ↩

  10. ドキュメントと実装の乖離は Issue #106845 で報告されています。修正 PR は一度取り込まれたあと差し戻されており、記事執筆時点で未解決です。 ↩

  11. MergeTree settings の parts_to_delay_insert。実効値は system.merge_tree_settings で確認しています。 ↩

  12. Billing overview の Compute の項に「meters compute on a per-minute basis, in 8G RAM increments」と記載があります。 ↩

  13. ClickHouse の GitHub issue #104681 および修正 PR #105103。 ↩

  14. アーカイブとクラスタ関数の組み合わせは Issue #64703 で検証課題として挙げられていますが、着手されていません。 ↩

  15. Selecting an insert strategy に、サーバーが INSERT を並行実行できることと、クライアント側で並列スレッドを走らせる方法が記載されています。 ↩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?