このガイドでは、ClickHouse Cloud の機能面および運用面で想定される違いの概要を説明します。ClickHouse Cloud はオープンソース版の ClickHouse をベースにしていますが、アーキテクチャや実装にはいくつか違いがある場合があります。背景情報として、ClickHouse Cloud をどのように構築したかを紹介するこちらのブログも、興味深く参考になるでしょう。
ClickHouse Cloud は、運用負荷を大幅に軽減し、大規模な ClickHouse 運用にかかるコストを削減します。デプロイメントのサイジングを事前に行ったり、高可用性のためにレプリケーションを設定したり、データを手動で分片化したり、ワークロードの増加に応じてサーバーをスケールアップしたり、使用していないときにスケールダウンしたりする必要はありません。これらは ClickHouse Cloud が対応します。
こうした利点は、ClickHouse Cloud を支えるアーキテクチャ上の設計によって実現されています。
- コンピュートとストレージは分離されているため、それぞれを独立した軸で自動的にスケールできます。そのため、固定的なインスタンス構成でストレージやコンピュートを過剰にプロビジョニングする必要がありません。
- オブジェクトストア上の階層型ストレージと多段のキャッシュにより、実質的に無制限のスケーリングと優れたコストパフォーマンスを実現できます。そのため、ストレージ容量を事前に見積もったり、高額なストレージコストを心配したりする必要がありません。
- 高可用性はデフォルトで有効になっており、レプリケーションも透過的に管理されるため、アプリケーションの構築やデータ分析に集中できます。
- 変動のある継続的なワークロード向けの自動スケーリングはデフォルトで有効になっているため、サービスのサイジングを事前に行ったり、ワークロードの増加時にサーバーをスケールアップしたり、アクティビティが減ったときに手動でサーバーをスケールダウンしたりする必要がありません
- 断続的なワークロード向けのシームレスな休止機能もデフォルトで有効になっています。一定期間アクティビティがない場合、コンピュートリソースは自動的に一時停止され、新しいクエリが到着すると透過的に再開されるため、アイドル状態のリソースに料金を支払う必要がありません。
- 高度なスケーリング制御により、追加コストを抑えるために自動スケーリングの上限を設定したり、特別なパフォーマンス要件を持つアプリケーション向けにコンピュートリソースを確保するため自動スケーリングの下限を設定したりできます。
ClickHouse Cloud では、オープンソース版の ClickHouse で提供されている機能のうち、厳選された一部の機能を利用できます。以下の表では、現時点で ClickHouse Cloud で無効になっている機能の一部を示します。
ClickHouse Cloud では、デフォルトで高可用性のあるレプリケーション構成のサービスが提供されます。そのため、すべてのデータベースエンジンとテーブルエンジンは「Replicated」になります。つまり、ReplicatedMergeTree と MergeTree は ClickHouse Cloud では同じものとして扱われるため、「Replicated」を明示的に指定する必要はありません。
サポートされているテーブルエンジン
- ReplicatedMergeTree (未指定時のデフォルト)
- ReplicatedSummingMergeTree
- ReplicatedAggregatingMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedVersionedCollapsingMergeTree
- MergeTree (ReplicatedMergeTree に変換)
- SummingMergeTree (ReplicatedSummingMergeTree に変換)
- AggregatingMergeTree (ReplicatedAggregatingMergeTree に変換)
- ReplacingMergeTree (ReplicatedReplacingMergeTree に変換)
- CollapsingMergeTree (ReplicatedCollapsingMergeTree に変換)
- VersionedCollapsingMergeTree (ReplicatedVersionedCollapsingMergeTree に変換)
- URL
- View
- MaterializedView
- GenerateRandom
- Null
- Buffer
- Memory
- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
- Kafka
ClickHouse Cloud は、HTTPS、ネイティブインターフェイス、MySQL wire protocol をサポートしています。Postgres など、さらに多くのインターフェイスにも近日対応予定です。
Dictionaries は、ClickHouse におけるルックアップを高速化する一般的な方法です。ClickHouse Cloud は現在、PostgreSQL、MySQL、リモートおよびローカルの ClickHouse サーバー、Redis、MongoDB、HTTP ソースの Dictionaries をサポートしています。
クラウド内でのクラスター間通信、および外部のセルフマネージド ClickHouse クラスターとの通信向けに、フェデレーテッド ClickHouse クエリをサポートしています。現在、ClickHouse Cloud では、以下のインテグレーションエンジンを使用したフェデレーテッドクエリをサポートしています。
- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
SQLite、ODBC、JDBC、Redis、HDFS、Hive など、一部の外部データベースエンジンおよびテーブルエンジンを使用するフェデレーテッドクエリは、まだサポートされていません。
ClickHouse Cloud のユーザー定義関数は、パブリックベータです。
重要ClickHouse Cloud の UDFs は ユーザーレベル設定を継承しません。デフォルトのシステム設定で実行されます。
- セッションレベルの設定 (
SET ステートメントで設定) は、UDF の実行コンテキストに伝播されません
- ユーザープロファイル設定は UDFs に継承されません
- クエリレベルの設定は、UDF の実行中には適用されません
サービスのデプロイの安定性を確保するため、ClickHouse Cloud サービスでは実験的機能は無効化されています。
名前付きコレクション は現在、ClickHouse Cloud ではサポートされていません。
以下は ClickHouse Cloud サービスのデフォルト設定です。これらの設定には、サービスを正しく動作させるために固定されているものもあれば、調整可能なものもあります。
max_parts_in_total: 10,000
max_parts_in_total 設定のデフォルト値は、100,000 から 10,000 に引き下げられました。この変更の理由は、データパーツ数が多いと Cloud 上のサービスの起動時間が長くなりやすいことが確認されたためです。パーツ数が多い場合、通常はパーティションキーの粒度が細かすぎることを示しており、これは多くの場合意図せず設定されるものであるため、避けるべきです。デフォルト値を変更することで、このようなケースをより早い段階で検出できるようになります。
max_concurrent_queries: 1,000
100 から 1000 に引き上げています。
これにより、各ティアのサービスで実行できる同時クエリ数は レプリカ数 * 1,000 になります。
単一レプリカに制限される Basic tier のサービスでは同時クエリ数は 1000、Scale と Enterprise では、
設定したレプリカ数に応じて 1000+ になります。
max_table_size_to_drop: 1,000,000,000,000
