このガイドでは、ClickHouse Cloud の機能面および運用面で想定される違いの概要を説明します。ClickHouse Cloud はオープンソース版の ClickHouse をベースにしていますが、アーキテクチャや実装にはいくつか違いがある場合があります。背景情報として、ClickHouse Cloud をどのように構築したかを紹介するこちらのブログも、興味深く参考になるでしょう。
ClickHouse Cloud は、運用負荷を大幅に軽減し、大規模な ClickHouse 運用にかかるコストを削減します。デプロイメントのサイジングを事前に行ったり、高可用性のためにレプリケーションを設定したり、データを手動で分片化したり、ワークロードの増加に応じてサーバーをスケールアップしたり、使用していないときにスケールダウンしたりする必要はありません。これらは ClickHouse Cloud が対応します。
こうした利点は、ClickHouse Cloud を支えるアーキテクチャ上の設計によって実現されています。
- コンピュートとストレージは分離されているため、それぞれを独立した軸で自動的にスケールできます。そのため、固定的なインスタンス構成でストレージやコンピュートを過剰にプロビジョニングする必要がありません。
- オブジェクトストア上の階層型ストレージと多段のキャッシュにより、実質的に無制限のスケーリングと優れたコストパフォーマンスを実現できます。そのため、ストレージ容量を事前に見積もったり、高額なストレージコストを心配したりする必要がありません。
- 高可用性はデフォルトで有効になっており、レプリケーションも透過的に管理されるため、アプリケーションの構築やデータ分析に集中できます。
- 変動のある継続的なワークロード向けの自動スケーリングはデフォルトで有効になっているため、サービスのサイジングを事前に行ったり、ワークロードの増加時にサーバーをスケールアップしたり、アクティビティが減ったときに手動でサーバーをスケールダウンしたりする必要がありません
- 断続的なワークロード向けのシームレスな休止機能もデフォルトで有効になっています。一定期間アクティビティがない場合、コンピュートリソースは自動的に一時停止され、新しいクエリが到着すると透過的に再開されるため、アイドル状態のリソースに料金を支払う必要がありません。
- 高度なスケーリング制御により、追加コストを抑えるために自動スケーリングの上限を設定したり、特別なパフォーマンス要件を持つアプリケーション向けにコンピュートリソースを確保するため自動スケーリングの下限を設定したりできます。
ClickHouse Cloud では、オープンソース版の ClickHouse で提供されている機能のうち、厳選された一部の機能を利用できます。以下の表では、現時点で ClickHouse Cloud で無効になっている機能の一部を示します。
ClickHouse Cloud は、SharedMergeTree テーブルエンジンファミリーを基盤とする、高可用かつデフォルトでレプリケーション構成のサービスです。標準的な MergeTree ファミリーのエンジンでテーブルを作成すると、Cloud は対応する Shared* エンジンに自動的に置き換えます。Shared または Replicated のプレフィックスを自分で付ける必要はありません。
Replicated* エンジンも、同じ対応先の Shared* エンジンに変換されます。この置き換えは SHOW CREATE TABLE で確認でき、ステートメントで通常のバリアントを指定していても、Shared* エンジンとして表示されます。
以下のテーブルエンジンもサポートされており、そのまま使用されます。サポートされている MySQL テーブルエンジンは、サポートされていない MySQL データベースエンジンとは異なります。
- URL
- View
- MaterializedView
- GenerateRandom
- Null
- Buffer
- Memory
IcebergS3 および IcebergAzure- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
- Kafka
実験的な PaimonS3 および PaimonAzure テーブルエンジンは、一部の ClickHouse Cloud サービスで有効にできます。利用可否についてはサポートにお問い合わせください。
ClickHouse Cloud は、HTTPS、ネイティブインターフェイス、MySQL wire protocol をサポートしています。Postgres など、さらに多くのインターフェイスにも近日対応予定です。
Dictionaries は、ClickHouse におけるルックアップを高速化する一般的な方法です。ClickHouse Cloud は現在、PostgreSQL、MySQL、リモートおよびローカルの ClickHouse サーバー、Redis、MongoDB、HTTP ソースの Dictionaries をサポートしています。
クラウド内でのクラスター間通信、および外部のセルフマネージド ClickHouse クラスターとの通信向けに、フェデレーテッド ClickHouse クエリをサポートしています。現在、ClickHouse Cloud では、以下のインテグレーションエンジンを使用したフェデレーテッドクエリをサポートしています。
IcebergS3 および IcebergAzurePaimonS3 および PaimonAzure (実験的。利用可否についてはサポートにお問い合わせください)- 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 サービスでは実験的機能は無効化されています。
DDL で作成された名前付きコレクションは、一部の 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 になります。単一レプリカのサービスでは、ティアにかかわらず最大 1000 の同時クエリがサポートされます。Scale および Enterprise tier の複数レプリカのサービスでは、レプリカごとに最大 1000 の同時クエリがサポートされます。
max_table_size_to_drop: 1,000,000,000,000
サポートされていないデータベースおよびテーブルエンジン
