OLTPとOLAPを適材適所で組み合わせる - ClickHouse Cloudで実現する統合データスタック

db tech showcase 2026 Tokyo 講演資料
現代のシステムには、データを正確・低遅延に処理するOLTPと、蓄積された大量のデータを横断的に集計・分析するOLAPの両方が必要です。各処理の性能要求は根本的に異なり、混在させることはリソース競合による性能劣化、効率的なスケーリングの妨げの原因となりえます。

本セッションでは、PostgreSQLによる低遅延なOLTPと、ClickHouseによる高速かつコスト効率の高いOLAPを、リアルタイムCDCでつなぐ統合データスタックを紹介します。
本セッションを通じて、ClickHouse Cloudが提供する各サービスの役割と具体的な組み合わせ方法、事例、設計・運用上の考慮点に関する知見を獲得できます。

1. OLTPとOLAPを適材適所で組み合わせる ClickHouse Cloudで実現する統合データスタック ClickHouse 株式会社 ソリューションアーキテクト 榎本 貴之 2026.11.05
2. 発表者紹介：榎本 貴之Takayuki Enomoto) Solution Architect, ClickHouse - - - 2 システムインテグレーター、ゲーム会社におけるインフラエ ンジニアのキャリアを経て、2015 年にクラウドサポートエン ジニアとして AWS に参画。分析サービスのエキスパートと して、エスカレーション対応や高度な問題解決に従事 2021 年からは OpenSearch のソリューションアーキテク トとして、検索サービスの導入支援、技術課題解決を担当 OSS の OpenSearch コミュニティ運営にも携わる 現職では ClickHouse や Langfuse の導入支援を担当 ©2026 ClickHouse, Inc.
3. アジェンダ 3 はじめに 従来分析基盤の課題 DB の限界、DWH とスピードレイヤー 01 OLAP は ClickHouse で 速度、鮮度、同時実行数を大きく改善 02 統合は ClickPipes で CDC でニアリアルタイムに連携する 03 OLTP も ClickHouse プラットフォームで 連携をさらに簡単かつ高速に 04 ベストプラクティス 始めどき、費用、つなぐ前の準備 05 まとめ PostgreSQL で始めて伸ばす ©2026 ClickHouse, Inc.
4. 00 従来分析基盤の課題
5. すべては一つのデータベースから 本番の PostgreSQL 取引のトランザクション 社内ダッシュボード PostgreSQL for everything 利用者向けの統計 API 成長の初期は、どの処理も 本番の PostgreSQL で受けていた 5 ©2026 ClickHouse, Inc. How Polymarket scaled their data stack with Postgres and ClickHouse: https://clickhouse.com/blog/how-polymarket-scales-data-with-postgres-and-clickhouse Primary 全部をここで受ける
6. データと利用者の増加が、トランザクション処理を圧迫 本番の PostgreSQL ランキング計算によりリソースが逼迫。 トランザクション処理が不安定に 取引のデータが増えるにつれ、 社内ダッシュボードの問い合わせがタイムアウトするように Polymarket の Leaderboard。取引量と損益の ランキングを PostgreSQL の中で定期的に計算していた 6 ©2026 ClickHouse, Inc. スポーツや政治など、カテゴリ別の ランキングは負荷が増えるので実現できなかった How Polymarket scaled their data stack with Postgres and ClickHouse: https://clickhouse.com/blog/how-polymarket-scales-data-with-postgres-and-clickhouse
7. バッチベースの分析基盤導入による解決 (？) 過去に何が起きたか？ バッチレイヤー 事業A (店舗) DWH / レイク (履歴データ) バッチ処理 事業B Eコマース) 処理要件 要件 事業C (モバイル) 7 ©2026 ClickHouse, Inc. BI・加工 (帳票出力) 鮮度 目標応答時間 同時実行数 分〜日単位 数十秒〜分 少数
8. 多様化する分析、リアルタイム要件への対応が困難に 今、何が起きているか？ バッチレイヤー 社外の利用者 事業A (店舗) (視聴、広告、損益) DWH / レイク (履歴データ) バッチ処理 事業B Eコマース) 事業C (モバイル) 8 ©2026 ClickHouse, Inc. エージェント 各社が直面した課題 (要約、採点、振り分け) 鮮度 目標応答時間 同時実行数 要件 数秒以内 1秒未満 数百件以上 現実 3時間ごと 1分超 100件まで Fountain) InMobi、ピーク時) Gumlet How Fountain rebuilt its data plane on ClickHouse Cloud to power Cue, the Frontline Superintelligence: https://clickhouse.com/blog/fountain-agentic-ai-for-high-volume-hiring How InMobi achieved 20x faster queries and 80% cost savings with ClickHouse: https://clickhouse.com/blog/inmobi Gumletʼs key to processing billions of video and image requests daily: https://clickhouse.com/blog/gumlet-processing-billions-of-video-image-requests-with-clickhouse 自動の判断 (価格、不正、監視)
9. スピードレイヤーはバッチレイヤーを補完するが、代償を伴う 今、何が起きているか？ 特徴 トレードオフ バッチレイヤー 事業A (店舗) 事業B Eコマース) ストリーム処理で 秒単位の鮮度 • サービングレイヤーで バッチ処理 ミリ秒単位の応答 • ©2026 ClickHouse, Inc. (履歴データ) (要約、採点、振り分け) スピードレイヤー コンシューマー ストリーム 9 社外の利用者 (視聴、広告、損益) エージェント プロデューサー 事業C (モバイル) 速さと引き換えに、 決めた集計しか返せない • ストリーミング処理の DWH / レイク 導入による運用負荷の増大 • KVS / 検索エンジン (直近データ) 自動の判断 (価格、不正、監視)
10. 分析の主体は人間から エージェントへ エージェント主体 データ主体 目的に応じて最適なデータストアを使い分け アプリケーション USER USER RDB SRE データアナリスト USER USER DWH USER USER 多数の同時実行にミリ秒で返す分析が要る エージェント アプリケーション AGENT USER 全従業員 USER AGENT AI SRE USER AGENT Observability MCP MCP 同時実行数 数百件以上 頻度 応答要件 オンデマンド ミリ秒 トレードオフ 10 同時実行数 頻度 応答要件 数十件 〜数千件 スケジュール オンデマンド ミリ秒 〜数十秒 ©2026 ClickHouse, Inc.
11. The best-of-breed data stack: Postgres and ClickHouse 11 ©2026 ClickHouse, Inc. PostgreSQL  ClickHouse as the Open Source unified data stack: https://clickhouse.com/blog/postgres-clickhouse-oss
12. 01 OLAP は ClickHouse で
13. The Leading Database for AI 高速 ClickHouseは オープンソース の カラム型 OLAP データベース です。 1億行の集計が約 0.1秒(docs の例) 高い同時実行数 高QPSによる高速同時処理 膨大なデータをSQL で 高速 に 分析できるように設計されています。 高いデータ圧縮率 高い データ圧縮率 と スケーラビリティ 最適化されたクエリエンジンで 大幅なコスト削減 を実現します。 13 ©2026 ClickHouse, Inc. データにより数倍〜数十倍の容量削減 負荷に応じてダイナミックにスケール
14. ClickHouse の歴史 わずか 4 年 で 4,000 社以上の企業が ClickHouse Cloud を利用 2009 プロトタイプ 2016 オープン ソース 2021 ClickHouse Inc. 2022 ClickHouse Cloud 2024 AWS Tokyo Regionオープン ANTHROPIC Tesla 14 2025 Google Cloud Tokyo Region オープン
15. ClickHouse は幅広いユースケースに対応 USER USER 高速 クエリ Agent Tracing 業務 USER AI/ML OPS ランダム クエリ モデルチューニング モニタリング Streaming CDC Agent管理 AGENTS / AGENTS PLATFORM APPLICATIONS DB 業務 USER BI / 対話分析 自然言語クエリ 高速クエリ MCP 行動 DATA Context DATA マスタ DATA ベクトル DATA 業務 DATA 推論 LOG CS SRE SYSTEM LOG APP LOG Security LOG MCP ログ解析 自然言語クエリ Security データ共有 ログ格納 インシデント対応 AI解析支援 業務 / 外部 データ連携 15 ©2026 ClickHouse, Inc. STORAGE / Data Lake 構造化 非構造化 Open Table Format Data Catalog DWH LOG 共通データ基盤 バッチクエリ ログ基盤 ログ監視 アプリ / システムセ キュリティ / ログ収集
16. ClickHouse で鮮度、レイテンシ、同時実行数を大きく改善 今、何が起きているか？ バッチレイヤー 社外の利用者 事業A (店舗) (視聴、広告、損益) リアルタイム分析も過去データの分析も バッチ処理 DWH / レイク (履歴データ) 事業B Eコマース) ClickHouse による改善効果 従来 事業C (モバイル) 16 ©2026 ClickHouse, Inc. ClickHouse 導入効果 エージェント 鮮度 目標応答時間 同時実行数 3時間ごと 1分超 100件まで Fountain) InMobi、ピーク時) Gumlet 2分未満 3秒未満 500件 Fountain) InMobi、ピーク時) Gumlet、一度に) How Fountain rebuilt its data plane on ClickHouse Cloud to power Cue, the Frontline Superintelligence: https://clickhouse.com/blog/fountain-agentic-ai-for-high-volume-hiring How InMobi achieved 20x faster queries and 80% cost savings with ClickHouse: https://clickhouse.com/blog/inmobi Gumletʼs key to processing billions of video and image requests daily: https://clickhouse.com/blog/gumlet-processing-billions-of-video-image-requests-with-clickhouse (要約、採点、振り分け) 自動の判断 (価格、不正、監視)
17. ClickHouse Cloud のアーキテクチャ アプリケーション ClickHouse Cloud アカウント 結果 ノード :読み書きの処理を担う クエリ 各レプリカで読み書きを処理可能 各レプリカは個別に割り当てられた CPU、メモリ、高速なローカルストレージ をもつ エンドポイント HTTP / TCP プロキシ / ロードバランサ Keeper サービスコンピュート 共有 メタデータ レプリカ#1 レプリカ#2 サービスから共有アクセス ©2026 ClickHouse, Inc. レプリカ#3 + 台数を追加 Keeper:メタデータを束ねる パーツの一覧などのメタデータを持つ 全レプリカがここで同期する マルチレイヤーキャッシュ ストレージとカタログ 17 認証・計画・調整 共通ストレージ :データはここに データは高耐久のオブジェクトストレージ に一度だけ書き込む。読み取り時にロー カルストレージにキャッシュ ClickHouse Cloud architecture: https://clickhouse.com/docs/products/cloud/reference/architecture ClickHouse Cloud boosts performance with SharedMergeTree: https://clickhouse.com/blog/clickhouse-cloud-boosts-performance-with-sharedmergetree-and-lightweight-updates
18. 高鮮度を支える高速なデータ取り込み基盤 SELECT 書き込み方 イミュータブルな書き込み アプリから直接 既存のパーツは書き換えず、 新しいパーツを足すだけ クライアント SDK Python、Go、Java など) INSERT Compute Node Compute Node Compute Node SQL でまとめて 小さな書き込みはまとめる 非同期挿入(既定)でバッファにため、 まとめてからパーツにする INSERT INTO … SELECT S3 などのファイルから) 裏側で継続的に最適化 ストリーミングから Kafka、Flink、 ClickPipes など 小さいパーツは裏でマージ 読み取りを止めない パーツ オブジェクトストレージ 18 ©2026 ClickHouse, Inc. パーツ パーツ Tesla は本番で毎秒数千万行、 Cloudflare は毎秒数億行を書き込む How Tesla built a quadrillion-scale observability platform on ClickHouse: https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse How Cloudflare Processes Hundreds of Millions of Rows per Second with…: https://clickhouse.com/blog/how-cloudflare-processes-hundreds-of-millions-of-rows-per-second-with-clickhouse async_insert_* session settings: https://clickhouse.com/docs/reference/settings/session-settings/async-insert
19. 読み取り範囲を削減し、高速に分析 索引で条件に合わないグラニュールを外し、残りだけを読む 1 テーブル定義 CREATE TABLE events ( user_id UInt32, ts DateTime, value Float64 ) ENGINE  MergeTree ORDER BY (user_id, ts) PRIMARY KEY user_id ORDER BY は並び順 PRIMARY KEY は 索引に載せる列 19 ©2026 ClickHouse, Inc. 2 3 パーツ INSERT パーツ 1 列ごとに保存 パーツ 1 user_id パーツ 2 ts value パーツ 3 書き込むと、 パーツが足される user_id 1 5 9 98 INSERT グラニュール パーツ 1 黄色 = 索引 1 INSERT 4 120 205 パーツの中は列ごと。 ORDER BY 順に並ぶ ts value 1 5 9 9 98 120 120 205 最大 8,192 行ごとに区切り 先頭行の user_id を索引に
20. 読み取り範囲を削減し、高速に分析 索引で条件に合わないグラニュールを外し、残りだけを読む 1 テーブル定義 CREATE TABLE events ( user_id UInt32, ts DateTime, value Float64 ) ENGINE  MergeTree ORDER BY (user_id, ts) PRIMARY KEY user_id 2 3 パーツ INSERT パーツ 1 20 ©2026 ClickHouse, Inc. パーツ 1 user_id 書き込むと、 パーツが足される 4 グラニュール パーツ 1 黄色 = 索引 ts value 1 INSERT パーツ 2 user_id=80 があり得るのは、 索引の値が 9 のグラニュール INSERT だけ。そこだけを読む パーツ 3 ORDER BY は並び順 PRIMARY KEY は 索引に載せる列 列ごとに保存 user_id 1 5 9 98 120 205 パーツの中は列ごと。 ORDER BY 順に並ぶ ts value 1 5 9 9 98 120 120 205 SELECT sum(value) FROM events WHERE user_id = 80
21. 絞り込みの手法は様々 主キー索引に、必要に応じて Projection やスキップ索引を組み合わせ。主キー以外は後から追加可能 ① 主キー索引 PRIMARY KEY の列。 グラニュールごとに先頭の値を持つ テーブル作成後の変更は不可 ② Projection 別の列の並び順の索引。 _part_offset で元の行を引く ③ スキップ索引 グラニュール単位の要約。 minmax、 set、bloom_filter など 21 ©2026 ClickHouse, Inc. Index-based pruning in ClickHouse: https://clickhouse.com/blog/index-based-pruning Data skipping index examples: https://clickhouse.com/docs/concepts/features/performance/skip-indexes/skipping-indexes-examples
22. 複数の手法を組み合わせ、高いデータ圧縮率を実現 並べ替えと独自の CODEC が高圧縮率の秘訣 並び順で縮める CODEC で縮める 実際の圧縮率 ORDER BY で同じ値が続くように並べる 列の性質に合わせて符号化してから圧縮 公開データより ts DateTime CODEC(Delta, ZSTD) 性能テスト計測値 86.5倍 114 TiB  1.32 TiB CI テスト結果ログ 33.5倍 17.9 TiB  548 GiB 5.9倍 GitHub のイベント 4.46 TiB  770 GiB どれも既定の圧縮だけ。非圧縮は ClickHouse の列形式での大きさ 22 ©2026 ClickHouse, Inc. ClickHouse Release 24.6: https://clickhouse.com/blog/clickhouse-release-2406 Optimizing ClickHouse with Schemas and Codecs: https://clickhouse.com/blog/optimize-clickhouse-codecs-compression-schema ClickHouse Playground(2026年10月22日に取得): https://play.clickhouse.com
23. 前倒しで集計することで、計算負荷を削減 増分 Materialized View で挿入時にデータを集計。クエリは集計済みの結果を読むだけなので軽量 ソース Kafka S3 / レイク Bronze Silver Gold 生データ 洗浄済み 業務向け MergeTree 増分 MV Replacing MergeTree 定期 MV MergeTree 外部 DB 古い行は自動削除 TTL を設定) マージで重複統合 アプリが読む 増分 MVベーステーブルへの INSERT をトリガーに、変換した結果を後段テーブルにも INSERT するための定義 定期 MV決めた間隔でクエリを実行し直し、後段のテーブルを置き換える定義APPEND で追記も可) 生データBronzeも残るので、想定外の問いには元の行を読んで答えられる 23 ©2026 ClickHouse, Inc. Incremental materialized view: https://clickhouse.com/docs/concepts/features/materialized-views/incremental-materialized-view Refreshable materialized view: https://clickhouse.com/docs/concepts/features/materialized-views/refreshable-materialized-view The three villains to agentic observability: retention, sampling and rollups: https://clickhouse.com/blog/three-villains-agentic-observability
24. 書き込むときに列を計算する MATERIALIZED 列は INSERT のときに式で値を作り、普通の列として保存する。 INSERT される行 Timestamp MATERIALIZED は書くときに LogAttributes(Map) {'request_path': '/site/productCard', 'request_type': 'POST'} INSERT 時に式で値を作って保存。 読むときは計算しない INSERT のときに式で計算 ALIAS は読むときに 保存される列 Timestamp LogAttributes RequestPage RequestType RequestPage String MATERIALIZED path(LogAttributes['request_path']), RequestType LowCardinality(String) MATERIALIZED LogAttributes['request_type'], RemoteAddr IPv4 ALIAS LogAttributes['remote_addr'] 24 ©2026 ClickHouse, Inc. CREATE TABLESpecify column default values): https://clickhouse.com/docs/reference/statements/create/table Designing a schema for observability: https://clickhouse.com/docs/guides/use-cases/observability/build-your-own/schema-design 保存せず、問い合わせのたびに 式を当てる。後から足しやすい MV との違い MV は別の表に書く。この 2つは 同じ表の中に列を足す
25. コンピュートリソースは柔軟にスケール、分離可能 ワークロード 取り込み・変換 利用者の画面 社内の分析 処理ごとにサービスを分離可能 エンドポイントは別々。 データ・ユーザー・権限は共通 ウェアハウス サービス 1 読み書き エンドポイント 1 レプリカ#1 レプリカ#2 サービス 2 読み取り専用 エンドポイント 2 レプリカ#1 レプリカ#2 サービスごとにスケールが可能 垂直、水平オートスケール、 スケジュールベースや手動の スケーリングに対応 レプリカ#3 Read/Write 分離にも対応 オブジェクトストレージ (共有) 同じテーブル、同じデータ 25 ©2026 ClickHouse, Inc. 読み取り専用のサービスは マージを実行せず読み取りに専念
26. Private Preview アドホックなクエリも実行可能 ワークロード 取り込み・変換 利用者の画面 社内の分析 オンデマンドなクエリ処理用 ウェアハウス サービス 1 読み書き エンドポイント 1 レプリカ#1 レプリカ#2 サービス 2 読み取り専用 エンドポイント 2 レプリカ#1 レプリカ#2 レプリカ#3 On-Demand Compute ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー ClickHouse が管理する共有のワーカー オブジェクトストレージ (共有) 同じテーブル、同じデータ 26 ©2026 ClickHouse, Inc. 同じデータを読む クエリごとに一時的に割り当て
27. 02 統合は ClickPipes で
28. ACID が要求される処理には OLTP が必要 複数の文にまたがるトランザクションのACID 特性を保証するのは、OLTP の DB の役目。 原子性Atomicity) 送金は 1つのトランザクション 一連の処理をすべて反映するか、 まったく反映しないかのどちらかにする BEGIN; 口座 A 一貫性Consistency) 10,000円 両方確定か 両方取り消し 口座 B 10,000円 COMMIT; 実行の前後で、整合性を満たした状態を保つ 分離性Isolation) トランザクション間の干渉を、指定した分離レベルに応じて 防ぐ 永続性Durability) 注文、在庫、会員情報の更新も同じ コミット済みの結果は、システム障害後も失われない ClickHouse の ACID は単一パーティションへのINSERT 単位。 複数文のトランザクションは実験的機能Cloud 非対応) 28 ©2026 ClickHouse, Inc. Migrating from PostgreSQL Appendix: https://clickhouse.com/docs/get-started/migrate/postgres/appendix Transactional ACID) support: https://clickhouse.com/docs/concepts/features/operations/insert/transactions OLTP is expensive, you can ClickHouse it.: https://clickhouse.com/blog/oltp-is-expensive-you-can-clickhouse-it
29. 分析には今の数字が必要 リアルタイム分析では、最新の確定した変更をニアリアルタイムで連携する必要がある 定期的に取りに行く 変更を流し続ける CDC 鮮度が価値になる 順位も在庫も不正検知も 今の数字でないと遅い アプリを書き換えない 書き込み先は PostgreSQL だけ。 各種連携先への個別書き込みはしない 取りに行く間隔の分だけ、 数字が遅れる 29 ©2026 ClickHouse, Inc. 確定した変更を順に流す。 間隔は既定 1分、10秒以上を推奨 元のデータは1か所 PostgreSQL が最新情報の信頼できる ソースとなる Change Data Capture CDC) with PostgreSQL and ClickHouse - Part 1: https://clickhouse.com/blog/clickhouse-postgresql-change-data-capture-cdc-part-1 Postgres CDC connector for ClickPipes is now Generally Available: https://clickhouse.com/blog/postgres-cdc-connector-clickpipes-ga
30. CDC は構成が重く運用負荷が高い 自前で構築したパイプラインでは、層ごとに個別の監視と復旧を想定した設計が求められる 箇所ごとの監視と復旧 2 3 4 Debezium、Kafka、Sink、MV の 各箇所に監視と復旧が要る 行ごとの順序を守る 削除まで反映するなら、同じ行の 変更を順に届ける設計が要る 1 自前の運用は手間がかさむ 自前の Debezium は伸びにくく、 デバッグに時間を取られた 30 ©2026 ClickHouse, Inc. Change Data Capture CDC) with PostgreSQL and ClickHouse - Part 2: https://clickhouse.com/blog/clickhouse-postgresql-change-data-capture-cdc-part-2 How Seemplicity scaled real-time security analytics with Postgres CDC and…: https://clickhouse.com/blog/seemplicity-scaled-real-time-security-analytics-with-postgres-cdc-and-clickhouse How SewerAI is using ClickHouse to modernize sewer management at scale: https://clickhouse.com/blog/sewerai-sewer-management-at-scale
31. ClickPipes マネージドデータ統合パイプライン STREAMING MSK Kafka マネージドデータインジェストサービス Confluent DigitalOcean Managed Kafka Kinesis Redpanda WarpStream PubSub* Event Hubs OBJECT STORAGE S3 GCS DigitalOcean Blob Storage R2 CDC Change Data Capture) Aurora RDS Postgre MySQL MariaDB Supabase SQL AlloyDB CloudSQL MongoDB† BigQuery* 31 ©2026 ClickHouse, Inc. Private Preview または Public Beta • コンソールで設定し、継続的に取り込む • 最初に一括で読み込み、そのあとは変更だけを流す • ストリーミング、オブジェクトストレージ、 DB の CDC に対応 • リソースのスケール、レプリカ追加による並列処理をサポート
32. 数クリックで作成可能。 IaC にも対応 画面で接続先と表を選ぶだけ。同じ設定はTerraform と OpenAPI でも書ける。 数ステップで作成完了 接続先、パブリケーション、 表の選択、権限割り当て 閉域網に対応 SSH トンネル、AWS PrivateLink、 Google Cloud の PSC をサポート Terraform、OpenAPI 対応 どちらも GA。CDC の パイプをコードで管理できる 32 ©2026 ClickHouse, Inc. Ingesting data from Postgres to ClickHouse (using CDC https://clickhouse.com/docs/integrations/clickpipes/postgres ClickPipes Terraform reference: https://clickhouse.com/docs/integrations/clickpipes/programmatic-access/terraform Terraform & OpenAPI for ClickPipes is now Generally Available: https://clickhouse.com/blog/terraform-ga
33. ClickPipes は CDC をサポート 最初に一括で読み、以後は確定した変更を同期間隔ごとに流し続ける。 初回ロードは並列 表を行の範囲に分け、 並列に読み込む (既定は4並列) CDC は一定間隔 追加・更新・削除を 同期間隔ごとに届ける。 既定は1分、推奨は 10秒以上 列の追加も自動で反映 ソースの ADD COLUMN を検出。 DROP COLUMN は反映されない 33 ©2026 ClickHouse, Inc. Postgres CDC connector for ClickPipes is now Generally Available: https://clickhouse.com/blog/postgres-cdc-connector-clickpipes-ga Controlling the syncing of a Postgres ClickPipe: https://clickhouse.com/docs/integrations/clickpipes/postgres/controlling-sync Schema changes propagation support: https://clickhouse.com/docs/integrations/clickpipes/postgres/schema-changes
34. CDC の内部挙動 最初に一括で読み、以後は確定した変更をバージョン付きの行として届ける。 初回は並列で、まとめて読む 表を行の範囲に分け、 並列に読み込む (既定は4並列) 確定した変更だけを連携する 追加・更新・削除を流し続ける。 変更は秒単位で届ける 更新や削除は新しい行として 更新や削除は新しいバージョンの行とし て追加される。最新は FINAL で読むな どの工夫が必要 (後述) 出典・図Deduplication strategies、Parallel snapshot(clickhouse.com/docs)、Postgres CDC connector for ClickPipes is now GA(clickhouse.com/blog) 34 ©2026 ClickHouse, Inc.
35. 遅延・障害次の挙動 ClickPipes はバッファを持ち、読み取りと書き込み処理を分離 ClickPipes ClickHouse サービスとは別の計算資源 PostgreSQL スロット 宛先の停止で WAL を溜めない 書き込みが失敗しても、 スロットの消費は続ける 読み取り 内部のステージに置く 宛先の表 内部のステージ 書き込み 35 ©2026 ClickHouse, Inc. ClickPipes が 内部で反映 読んだ変更をいったん内部に置き、 そこから宛先の表へ書く スケーラビリティ CDC のパイプ間で共有。性能不足時は CPU、メモリリソースの増強、レプリカ追 加による分散処理で対応 Enhancing Postgres to ClickHouse replication using PeerDB: https://clickhouse.com/blog/enhancing-postgres-to-clickhouse-replication-using-peerdb ClickPipes for Postgres FAQ: https://clickhouse.com/docs/integrations/clickpipes/postgres/faq Scaling DB ClickPipes via OpenAPI: https://clickhouse.com/docs/integrations/clickpipes/postgres/scaling
36. フェイルオーバー時の挙動 元の DB のプライマリが切り替わっても、同期を継続 フェイルオーバースロットを活用 変更を読む ClickPipes プライマリPostgreSQL 17 以降) フェイルオーバー可能なスロット PostgreSQL 17 以降、設定を足して スロットをスタンバイへ同期 Amazon Aurora にも対応 sync_replication_slots 昇格したら こちらから読み続ける 36 ©2026 ClickHouse, Inc. 切断を検知し、新しいプライマリを 指すライターエンドポイントへ再接続 MySQL は GTID で再開 スタンバイ 同期されたスロット 切り替え後も、 GTID の位置から 自動で続きを読む ClickPipes for Postgres now supports failover replication slots: https://clickhouse.com/blog/clickpipes-postgres-failover-replication MySQL CDC connector for ClickPipes is now Generally Available: https://clickhouse.com/blog/mysql-cdc-connector-for-clickpipes-is-now-generally-available Aurora Postgres source setup guide: https://clickhouse.com/docs/integrations/clickpipes/postgres/source/aurora
37. モニタリングを標準で提供 レプリケーションラグやリソース使用状況を把握可能。異常検出時の通知にも対応 レプリケーションラグを取得可能 元、宛先、端から端までの レプリケーションの遅れを取得 アラート通知に対応 エラーを種類ごとに分類し、 メールや Slack で通知可能 スロットの監視も必要 停止中も WAL は溜まるため、 元の DB 側でスロットを監視 37 ©2026 ClickHouse, Inc. MySQL CDC connector for ClickPipes is now Generally Available: https://clickhouse.com/blog/mysql-cdc-connector-for-clickpipes-is-now-generally-available Postgres CDC in ClickHouse, A year in review: https://clickhouse.com/blog/postgres-cdc-year-in-review-2025 ClickPipes for Postgres FAQ: https://clickhouse.com/docs/integrations/clickpipes/postgres/faq
38. ClickPipes による CDC 導入事例 重い集計を ClickHouse に移し、タイムアウトしていた画面が数秒以内に返るようになった。 CDC をマネージドに ランキングの集計を移行 ClickHouse の 定期更新の MV 取引のデータ Goldsky から) ランキングの API PeerDB の CDC (今の ClickPipes) ClickHouse 約25ms 約2週間 数分→数秒 月数百億件 API の平均の応答 (毎秒数百件 ) 着想から本番まで 画面の表示時間 ClickHouse へ流す更新 PostgreSQL の資源は取引の処理に戻った 38 PostgreSQL ©2026 ClickHouse, Inc. JOIN していた表を、非正規化した表にまとめた How Polymarket scaled their data stack with Postgres and ClickHouse: https://clickhouse.com/blog/how-polymarket-scales-data-with-postgres-and-clickhouse How Seemplicity scaled real-time security analytics with Postgres CDC and…: https://clickhouse.com/blog/seemplicity-scaled-real-time-security-analytics-with-postgres-cdc-and-clickhouse
39. 03 OLTP も ClickHouse プラットフォームで
40. Managed Postgres by ClickHouse ClickHouse Cloud で動く PostgreSQLAWS で Beta 提供中)。高速、高可用性、ClickHouse と標準統合 高速 MVMe を搭載。EBS gp3 の9 倍以上の TPS。Direct I/O でバックアップ中の 性能低下を抑制 高可用性 別 AZ に最大2台のスタンバイを配置。障 害時は自動昇格。バックアップを S3 へ継 続送信 ClickHouse とのネイティブ統合 数クリックで ClickHouse と統合 フェイルオーバー後も CDC が自動継続 40 ©2026 ClickHouse, Inc. Fast, scalable, enterprise-grade Postgres natively integrated with ClickHouse: https://clickhouse.com/blog/postgres-managed-by-clickhouse
41. 最大の利点： ClickHouse とのシームレスな統合 pg_clickhouse による連携を標準サポート 書き込みは PostgreSQL トランザクション、 ACID、 1行の読み取りはそのまま CDC が変更を写し続ける 追加・更新・削除を ReplacingMergeTree に届ける 問い合わせは同じ接続で pg_clickhouse が集計を ClickHouse に渡す 41 ©2026 ClickHouse, Inc. Postgres on NVMe: performance and the convergence of transactions and analytics: https://clickhouse.com/blog/postgres-on-nvme
42. ローカル NVMe による高速なデータアクセス ディスクの待ち時間を改善 読み取りを待つセッションは EBS の 45% から NVMe で 14% に 通信オーバーヘッドなし 直結し、待ちは ミリ秒からマイクロ秒の桁に TPS は EBS gp3 の9.2倍 中央値で 16,030 と 1,734 TPS。 gp3 は 3,000 IOPS当社の計測 ) 42 ©2026 ClickHouse, Inc. POSETTE Talk Recap - Postgres Isn't Slow. Your Storage Is: https://clickhouse.com/blog/posette-talk-recap-postgres-isnt-slow-your-storage-is Postgres on NVMe: performance and the convergence of transactions and analytics: https://clickhouse.com/blog/postgres-on-nvme ClickHouse Managed Postgres: https://clickhouse.com/docs/products/managed-postgres/overview
43. バックアップ時の影響を Direct I/O で抑制 バックアップの読み取りはページキャッシュを通さず、問い合わせのデータを残す。 ページキャッシュを通さない仕組 O_DIRECT で読み、 カーネルのキャッシュに残さない バックアップ時の追い出しを抑制 従来のバックアップでは、ウォームアップ によるキャッシュがバックアップで全て追 い出されていた 所要時間は p99 で約3分の1に 0.18 ms → 0.06 ms。所要時間は ほぼ同じ(当社の検証機 ) 43 ©2026 ClickHouse, Inc. What is direct I/O, and why does ClickHouse Managed Postgres use it for backups?: https://clickhouse.com/blog/direct-io-managed-postgres-backups
44. 別 AZ にスタンバイを確保 問題発生時に素早くフェイルオーバー 別の AZ に最大2台 プライマリと同じ大きさで、 ノードや AZ の障害に備える 2台でもクォーラムを確保 どちらか1台の確認でコミットが 確定する。 1台なら非同期 自動でフェイルオーバー プライマリが落ちたら昇格。 読み取りには使わず待機に専念 44 ©2026 ClickHouse, Inc. High availability: https://clickhouse.com/docs/products/managed-postgres/high-availability
45. S3 への継続バックアップ ベースバックアップと WAL を WALG で送り続け、任意の時点に戻せる。 WALG で継続送信 毎日のフルバックアップに加え、 WAL を60秒か16 MB ごとに保管 任意の時点に戻す 保持期間内の時刻を選び、新しい インスタンスに復元 遅延時に書き込みを絞る 未送信の WAL が増えると段階的に 書き込み帯域を下げ、ディスクを守る 45 ©2026 ClickHouse, Inc. Building an enterprise Postgres service in ClickHouse Cloud: https://clickhouse.com/blog/enterprise-postgres-service-in-clickhouse-cloud What is WAL backpressure, and why does ClickHouse Managed Postgres need it?: https://clickhouse.com/blog/wal-backpressure-clickhouse-managed-postgres Backup and restore: https://clickhouse.com/docs/products/managed-postgres/backup-and-restore
46. リードレプリカ WAL をオブジェクトストレージから読み、プライマリに負荷をかけずに読み取りを分ける。 プライマリ オブジェクト ストレージ WAL を約60秒ごと、 またはセグメントが 満ちたら送る 読み取りレプリカ プライマリの負荷を抑制 プライマリには直接つながず、オブジェク トストレージから WAL を読む 読み取りレプリカ ストリーミングで 直接つなぐ 通常数十秒で同期される WAL は約60秒ごとに送られる。 集計や画面の読み取りに向く 読み取りレプリカ プライマリ昇格をサポート スタンバイ 46 ©2026 ClickHouse, Inc. レプリカごとに 別のエンドポイント Read replicas: https://clickhouse.com/docs/products/managed-postgres/read-replicas High availability: https://clickhouse.com/docs/products/managed-postgres/high-availability ClickHouse Managed Postgres pricing(2026年10月時点): https://clickhouse.com/docs/products/managed-postgres/pricing プライマリの障害時に、 レプリカをプライマリへ昇格
47. スケール時のダウンタイムは最小限 新しいインスタンスをスタンバイとして用意し、フェイルオーバーで切り替え 50 以上のインスタンスタイプ 新しい型の スタンバイを 用意 バックアップ から戻す WAL を 並列に適用 WALG プライマリに 追いつく 切り替え 約30秒 CPU、メモリ、NVMe の容量の 組み合わせから選ぶ 止まるのは切り替え時のみ 裏で進む(数分から数時間)。この間も読み書きできる 接続が切れ、 再接続する ストレージの使用率 ストレージは自動で拡張 85%通知 90%自動で拡張 47 ©2026 ClickHouse, Inc. 復元と追いつきは裏で進む。 接続文字列は変わらない Scaling: https://clickhouse.com/docs/products/managed-postgres/scaling ClickHouse Managed Postgres notifications: https://clickhouse.com/docs/products/managed-postgres/monitoring/notifications ClickHouse Managed Postgres pricing(2026年10月時点): https://clickhouse.com/docs/products/managed-postgres/pricing Scale 以上は使用率 90%で拡張。 切り替えは通常 1分未満
48. ネイティブ CDC の特徴 同じクラウドの ClickHouse へ、パイプラインを組まずに流す。 数クリックで同期 Sync to ClickHouse から表を選び、 初回の読み込みと CDC を始める 昇格しても止まらない レプリケーションスロットが フェイルオーバー後も残る 問い合わせも料金も込み pg_clickhouse が最初から入り、 Beta 中は CDC も追加料金なし 48 ©2026 ClickHouse, Inc. Open House 2026 Day 1 Real-time data without lock-in and what teams can build next: https://clickhouse.com/blog/open-house-2026-day-1 Postgres managed by ClickHouse is now in beta: https://clickhouse.com/blog/postgres-managed-by-clickhouse-beta ClickHouse Managed Postgres pricing(2026年10月時点): https://clickhouse.com/docs/products/managed-postgres/pricing
49. WalShadow Private Preview ClickHouse を PostgreSQL の分析用のスタンバイに WAL ファイルを直接活用 レプリカと同じ WAL の流れを PostgreSQL の外で解読する 約200ミリ秒で同期 毎秒約29万行の書き込みにも追従 スキーマの変更も反映 列の追加・改名・削除や 表の作成も反映する 49 ©2026 ClickHouse, Inc. Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL: https://clickhouse.com/blog/introducing-walshadow Postgres at Open House NYC: https://clickhouse.com/blog/postgres-at-open-house-nyc
50. 使い慣れた拡張を利用可能 PostGIS や pgvector など、90 を超える拡張を CREATE EXTENSION で導入可能 地理 postgis postgis_raster h3 pgrouting 90 を超える拡張を利用可能 earthdistance 地理、ベクトル検索、運用、 他の DB との連携まで ベクトルと全文検索 pgvector vchord vchord_bm25 pg_trgm pg_tokenizer ClickHouse 連携拡張を提供 運用と性能 pg_cron pg_partman pg_repack pg_stat_statements pgaudit pg_clickhouse は最初から入り、 pg_stat_ch で遅いクエリを見る 他の DB とつなぐ postgres_fdw mysql_fdw tds_fdw orafce 独自の PostgreSQL 拡張も pglogical pg_re2 は ClickHouse と同じ 構文と結果。最大 9倍速い ClickHouse とつなぐ pg_clickhouse pg_stat_ch pg_re2 chdb ほか多数 50 ©2026 ClickHouse, Inc. PostgreSQL extensions: https://clickhouse.com/docs/products/managed-postgres/extensions What's new in ClickHouse Managed Postgres: https://clickhouse.com/blog/managed-postgres-notifications-observability-backups
51. Query Insights クエリのパターンごとに、遅さとその理由をコンソールの画面で追える。 標準で利用可能 監視の画面と Query Insights は 作った時点から見られる 値は外に出さない リテラルを置き換えてから pg_stat_ch で送信 既存の監視基盤と連携可能 Prometheus 形式で取り出せる。 通知はメールと Slack へ 51 ©2026 ClickHouse, Inc. Introducing Postgres Query Insights in ClickHouse Cloud: https://clickhouse.com/blog/postgres-query-insights-clickhouse-cloud ClickHouse Managed Postgres monitoring: https://clickhouse.com/docs/products/managed-postgres/monitoring/overview
52. コネクションプール PgBouncer を標準提供 接続画面で「via PgBouncer」をオンにすると、PgBouncer を通る接続文字列が出る。 アプリ 短い接続が多い 独自にホストする必要なし PgBouncer 最初から同梱。アプリは PgBouncer エ ンドポイントに繋ぎかえるだけ トランザクション 単位でプール 大量の軽量処理に向く 移行、長い接続 セッションの機能 直接つなぐ PostgreSQL 頻繁にコネクションの接続を行う サーバーレスアプリケーション向け 場面に応じて使い分ける 直接つなぐPgBouncer 経由は不可) ClickPipes 52 ©2026 ClickHouse, Inc. Connecting to ClickHouse Managed Postgres: https://clickhouse.com/docs/products/managed-postgres/connection データ移行、長い接続を伴うバッチ処理 や ClickPipes による CDC では、 標準の接続方法を推奨
53. 通常の SQL はそのままに、集計を ClickHouse に任せる pg_clickhouse は PostgreSQL から ClickHouse の表を問い合わせる拡張。 書き換えずに使う ClickHouse の表が PostgreSQL の 外部テーブルとして見える 集計は ClickHouse で動く WHERE、JOIN、集計を ClickHouse の SQL に書き換えて渡す すべてが速くなるわけではない 公表の TPCHSF1では 22本中17本が速く、5本は遅い 53 ©2026 ClickHouse, Inc. Introducing pg_clickhouse: A Postgres extension for querying ClickHouse: https://clickhouse.com/blog/introducing-pg_clickhouse What's new in pg_clickhouse v0.10.0 Subqueries, TPCH Speedups, C Driver, and Aggregates: https://clickhouse.com/blog/pg_clickhouse-whats-new-july-2026 pg_clickhouse reference documentation: https://clickhouse.com/docs/products/managed-postgres/extensions/pg_clickhouse/introduction
54. ユーザ事例 : QuintoAndar ホット層とコールド層で分かれていたフローを ClickHouse + Managed Postgres へ集約 二経路を一つに統合 モバイルユーザーのトラッキングイベントと、 トランザクションデータベースからの CDC の 処理を ClickHouse に集約 Postgres を接続口に 顧客データ連携サービスの Hightouch を Managed Postgres につなぎ、集計と結 合を ClickHouse へプッシュダウン 1 秒未満の API 応答 "ClickHouse で目にした優れたパフォーマンスや 低レイテンシ、その素晴らしい点のすべてを、 ClickHouse Managed Postgres を通じて Hightouch でも活用できました" — Bruno Brito, Tech Lead Manager, QuintoAndar 54 ©2026 ClickHouse, Inc. 月約 9 億件を集約し、月 3 億件の API 要求へ 1 秒未満で応答 既存の顧客セグメントや配信施策も維持 https://clickhouse.com/ja/blog/quintoandar-managed-postgres-jp
55. 04 ベストプラクティス 始めどき、費用、つなぐ前の準備
56. 最初から ClickHouse を組み込む PostgreSQL をメイン DB として トランザクション処理は PostgreSQL に残す ClickHouse を組み込みの分析に 利用者やエージェントが画面や API から 使う分析基盤として活用する データの急増に対応 AI ネイティブな ClckHouse 顧客 10社 は、データ量が半年で 1,000%超に。 ClickHouse を活用することで規模拡大 に対応 56 ©2026 ClickHouse, Inc. PostgreSQL  ClickHouse as the Open Source unified data stack: https://clickhouse.com/blog/postgres-clickhouse-oss Postgres at Open House NYC: https://clickhouse.com/blog/postgres-at-open-house-nyc
57. 本番を大きくせず使う分だけ払う 計算の料金は読んだデータ量ではなく、計算資源の大きさと稼働時間で決まる。 1つの DB で集計まで 隣に置く 本番を大きくしない PostgreSQL は トランザクション処理に見合う大きさ 使う分だけ払う 計算は自動で休止。 Scale 以上は伸縮も 連携の料金を足さない Managed Postgres は Beta 中 CDC と pg_clickhouse 込み 57 ©2026 ClickHouse, Inc. clickhouse.build: An agentic CLI to accelerate Postgres apps with ClickHouse: https://clickhouse.com/blog/clickhouse-build-agentic-cli-accelerate-postgres-clickhouse-apps ClickHouse Managed Postgres pricing(2026年10月時点): https://clickhouse.com/docs/products/managed-postgres/pricing ClickHouse Cloud architecture: https://clickhouse.com/docs/products/cloud/reference/architecture
58. 過去のデータは ClickHouse に置く 書き込みと最新の行は PostgreSQL、それ以外は ClickHouse で安く持つ。 PostgreSQL 約60TB、 ClickHouse 約13TB Janitor AI の発表値。 PostgreSQL は 30日分、ClickHouse は全期間を持つ 列の圧縮で10〜30分の1 保存する大きさの目安。 集計の費用は約 100分の1 PostgreSQL は小さく速く 更新が来ない行のために 大きく持たなくてよい 58 ©2026 ClickHouse, Inc. OLTP is expensive, you can ClickHouse it.: https://clickhouse.com/blog/oltp-is-expensive-you-can-clickhouse-it
59. PostgreSQL 側には準備が必要 論理レプリケーションを有効にし、専用のユーザーと、要る表だけのpublication を作る。 1 2 3 論理レプリケーション (自前運用の例 ) 専用のユーザー 必要な表だけ ALTER SYSTEM SET wal_level = logical; -- 反映には再起動が要る CREATE USER clickpipes_user PASSWORD '…'; ALTER USER clickpipes_user WITH REPLICATION; GRANT SELECT ON ALL TABLES IN SCHEMA public TO clickpipes_user; CREATE PUBLICATION clickpipes FOR TABLE posts, users; 再起動を見込む wal_level の変更は、 再起動しないと効かない publication は絞る 要る表だけにする。余分な表は WAL の転送を増やす 主キーのない表に注意 4 59 スロットの WAL 保持 ©2026 ClickHouse, Inc. max_slot_wal_keep_size = 102400 -- 100 GB 以上を推奨 Generic Postgres source setup guide: https://clickhouse.com/docs/integrations/clickpipes/postgres/source/generic 主キーがない表は、 REPLICA IDENTITY FULL が要る
60. 初回ロードの並列度は元の DB の性能に合わせて設定 表を CTID の範囲で区切って並列に読む。区切り方と並列数は作成時に決まる。 posts(元の表 ) CTID で区切る CTID の範囲 10万行 読み取り 1 CTID の範囲 10万行 読み取り 2 件数を数えてから行の位置で 区切り、並列に読む ClickHouse CTID の範囲 10万行 作成後は変えられない 読み取り 3 範囲の行数と並列数は固定。 変えるならパイプを作り直す CTID の範囲 10万行 CTID の範囲 10万行 読み取り 4 元の DB の性能に合わせる 残りの範囲も、空いた読み取りが順に受け持つ 既定 1範囲 10万行、 4 並列、表は 1 つずつ 60 ©2026 ClickHouse, Inc. Parallel snapshot in the Postgres ClickPipe: https://clickhouse.com/docs/integrations/clickpipes/postgres/parallel-initial-load 並列を上げるほど、元の DB に 読み取りの負荷がかかる
61. データ更新と削除がどう処理されるかを知る 古いバージョンの行は非同期のマージでたたまれる。最新を確実に読むには少し工夫が必要 更新は新しい行扱い _peerdb_version の大きい行が 最新として残る 削除も新しい行扱い _peerdb_is_deleted = 1 の行が 削除を表す 削除タイミングは制御が難しい マージされるまでは古い行が残るため、 最新版だけを確実に取る場合は FINAL かビューを使う必要がある 61 ©2026 ClickHouse, Inc. Deduplication strategies (using CDC https://clickhouse.com/docs/integrations/clickpipes/postgres/deduplication Part merges: https://clickhouse.com/docs/concepts/core-concepts/merges
62. FINAL で最新の行を読む マージ前に残る古いバージョンの行を、問い合わせのときにたたんで返す。 FINAL とは 読むときにマージの処理を当て、 キーごとに最新のバージョンだけ返す FINAL の使いどころ 件数や合計を PostgreSQL と 合わせたい集計 重いのは重なる所だけ SELECT count(*) FROM posts FINAL WHERE _peerdb_is_deleted = 0; -- FINAL の代わりに SETTINGS final = 1 でもよい 62 ©2026 ClickHouse, Inc. ClickHouse Release 23.12: https://clickhouse.com/blog/clickhouse-release-2312 FROM FINAL modifier: https://clickhouse.com/docs/reference/statements/select/from#final-modifier Deduplication strategies (using CDC https://clickhouse.com/docs/integrations/clickpipes/postgres/deduplication 同じキーが複数のパーツにある範囲 だけをまとめ、ほかは普通に並列で読む
63. JOIN と削除行の扱い JOIN では両側の表に FINAL を付け、削除の印が付いた行も両側で外す。 posts FINAL LEFT JOIN _peerdb_is_deleted = 0 users FINAL _peerdb_is_deleted = 0 JOIN は両側に FINAL が必要 片側だけだと、もう片側の 古いバージョンの行も結合される 削除行は条件で外すとよい SELECT u.displayname, sum(p.viewcount) FROM posts AS p FINAL LEFT JOIN users AS u FINAL ON u.id = p.owneruserid AND u._peerdb_is_deleted = 0 WHERE p._peerdb_is_deleted = 0 GROUP BY u.displayname; 63 ©2026 ClickHouse, Inc. Deduplication strategies (using CDC https://clickhouse.com/docs/integrations/clickpipes/postgres/deduplication Sync to ClickHouse with ClickPipes: https://clickhouse.com/docs/products/managed-postgres/sync-to-clickhouse/clickpipes ON と WHERE の両方に _peerdb_is_deleted = 0 マージで消す設定もある 作成時に、マージで削除行を 物理削除する設定を選べる
64. データ型の違いを認識する 型は ClickPipes が対応表どおりに決める。特に差が出るのはNULL、numeric、JSON。 PostgreSQL ClickHouse(ClickPipes の既定) integer / bigint Int32 / Int64 numeric(p, s) Decimal(p, s) numeric(精度なし) Decimal(76, 38) 精度なし numeric は変換される timestamptz DateTime64(6) Decimal(76, 38) になり、整数部が 38桁を超える値は 0になる json / jsonb String NULL は既定値になる 既定では 0 や空文字に。残すなら 作成時に NULL を保つ設定を選ぶ JSON は String として格納される 64 integer[] Array(Int32) NULL 型の既定値 (0 や '') ©2026 ClickHouse, Inc. ClickPipes for Postgres FAQ: https://clickhouse.com/docs/integrations/clickpipes/postgres/faq Sync to ClickHouse with ClickPipes: https://clickhouse.com/docs/products/managed-postgres/sync-to-clickhouse/clickpipes PeerDB Datatype matrix: https://docs.peerdb.io/datatypes/datatype-matrix 関数や Materialized View を使って 後処理を行う
65. ORDER BY キーと REPLICA IDENTITY REPLICA IDENTITY は UPDATE と DELETE で WAL に書く変更前の列を決める設定。宛先のORDER BY とそろえる。 並び順キーは主キーのまま UPDATE posts SET title = … WAL body の値は送らない ClickHouse body が空になる body は TOAST に置かれた大きな列。UPDATE で変えていない -- 大きな列(TOAST)を持つ表: 全列を記録 ALTER TABLE posts REPLICA IDENTITY FULL; -- TOAST がなく並び順キーに列を足す表 CREATE UNIQUE INDEX orders_uid ON orders(tenant_id, id); ALTER TABLE orders REPLICA IDENTITY USING INDEX orders_uid; 65 ©2026 ClickHouse, Inc. Ordering Keys: https://clickhouse.com/docs/integrations/clickpipes/postgres/ordering-keys Handling TOAST columns: https://clickhouse.com/docs/integrations/clickpipes/postgres/toast PostgreSQL Documentation: ALTER TABLE: https://www.postgresql.org/docs/current/sql-altertable.html 変えるならまず定期更新の MV。 回らないときだけ不変の列を足す REPLICA IDENTITY にも足す 足した列を入れないと、削除の 行でその列が NULL になる 大きな列は FULL に UPDATE で変えていない TOAST 列は FULL でないと空で届く
66. Materialized View で分析用に最適化 ClickPipes が作る表は元の形のまま。MV で、分析に最適化されたテーブルを準備する ClickPipes が作る表 badges ORDER BY id name String _peerdb_ の管理列 分析向けの表 MV で 定期更新 badges_by_user ORDER BY (userid, date, id) name LowCardinality(String) 削除済みの行なし 並び順を問い合わせに合わせる 主キー順の表を、利用者や日付で 絞りやすい並びに入れ直す 型を分析向けにする LowCardinality などで小さく持つ。 そのままだと約 1.21倍(当社検証) CREATE MATERIALIZED VIEW badges_mv REFRESH EVERY 10 MINUTE TO badges_by_user AS SELECT * FROM badges FINAL WHERE _peerdb_is_deleted = 0; 66 ©2026 ClickHouse, Inc. Deduplication strategies (using CDC https://clickhouse.com/docs/integrations/clickpipes/postgres/deduplication 約1.21倍は当社の検証Stack Overflow の badges 5,129万行) 読む側は FINAL が不要 削除済みの行も除いておける。 鮮度は更新の間隔ぶん遅れる
67. 05 まとめ
68. PostgreSQL で始めて ClickHouse で伸ばす トランザクション処理は PostgreSQL、分析は ClickHouse、間は ClickPipes がつなぐ。 分析用の窓口は ClickHouse 多数の分析利用者やエージェントは ClickHouse に直接繋ぐ つなぐのは ClickPipes で フルマネージド CDC。Managed PostgreSQL と併用するなら高速な WalShadow で PostgreSQL 経由での接続も 最初から ClickHouse を組み込む 68 ©2026 ClickHouse, Inc. 今の PostgreSQL からでも始める PostgreSQL  ClickHouse as the Open Source unified data stack: https://clickhouse.com/blog/postgres-clickhouse-oss OLTP は PostgreSQL に残す。 pg_clickhouse を活用し、重たいクエリ はシームレスにオフロード
69. ClickHouse をぜひお試しください！ 試す 69 聞く 知る クラウド無料トライアル Ask AI Demo Applications アカウント作成で 30 日間の 無料トライアルが利用可能です ドキュメントサイトの Ask AI で 日本語でご質問が可能です ClickHouse を活用したデモ アプリケーションを体験できます clickhouse.cloud/signUp clickhouse.com/docs ©2026 ClickHouse, Inc. clickhouse.com/demos
70. Thank you! ご質問、ご相談は ClickHouse ブースまで！