mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-14 02:12:21 +00:00
47 lines
3.1 KiB
Markdown
47 lines
3.1 KiB
Markdown
---
|
|
sidebar_label: アーキテクチャ
|
|
slug: /ja/cloud/reference/architecture
|
|
---
|
|
|
|
# ClickHouse Cloud アーキテクチャ
|
|
|
|
|
|
|
|
## オブジェクトストアに支えられたストレージ
|
|
- 事実上無制限のストレージ
|
|
- データを手動で共有する必要なし
|
|
- 特にあまり頻繁にアクセスされないデータを保存する際のコストが大幅に低減
|
|
|
|
## コンピュート
|
|
- 自動スケーリングとアイドリング：事前にサイズを決定する必要がなく、ピーク使用に合わせて過剰プロビジョンする必要もなし
|
|
- 自動アイドリングと再開：誰も使っていないときに未使用のコンピュートを走らせる必要がない
|
|
- デフォルトで安全で高可用性
|
|
|
|
## 管理
|
|
- セットアップ、監視、バックアップ、および請求は自動的に行われます。
|
|
- コストコントロールはデフォルトで有効であり、Cloud コンソールを通じて調整できます。
|
|
|
|
## サービスのアイソレーション
|
|
|
|
### ネットワークのアイソレーション
|
|
|
|
すべてのサービスはネットワーク層でアイソレーションされています。
|
|
|
|
### コンピュートのアイソレーション
|
|
|
|
`Production` および `Development` サービスは、それぞれの Kubernetes スペース内で別々のポッドにデプロイされ、ネットワークレベルでアイソレーションされています。`Dedicated` サービスは専用の VM 上で自身の Kubernetes オペレーターと共に実行されます。
|
|
|
|
### ストレージのアイソレーション
|
|
|
|
すべてのサービスは、共有バケット(AWS, GCP)またはストレージコンテナ(Azure)の別々のサブパスを使用します。
|
|
|
|
AWS では、ストレージへのアクセスは AWS IAM を介して制御され、各 IAM ロールはサービスごとにユニークです。**Production** および **Dedicated** サービスについては、[CMEK](/docs/ja/cloud/security/cmek)が有効化されて使用停止時の高度なデータアイソレーションを提供します。CMEK は現在、AWS サービスのみでサポートされています。
|
|
|
|
GCP および Azure では、サービスはオブジェクトストレージのアイソレーションが確保されており（すべてのサービスが自身のバケットまたはストレージコンテナを持っています）。
|
|
|
|
## 同時実行制限
|
|
|
|
ClickHouse Cloud サービスでは、秒あたりのクエリ数 (QPS) に制限はありません。ただし、1 レプリカあたり1000 の同時クエリ制限があります。QPS は最終的に、平均クエリ実行時間とサービス内のレプリカ数による関数となります。
|
|
|
|
セルフマネージドの ClickHouse インスタンスや他のデータベース/データウェアハウスと比較した ClickHouse Cloud の主な利点は、[レプリカを追加する（水平スケーリング）](/docs/ja/manage/scaling#self-serve-horizontal-scaling)ことで簡単に同時実行数を増やせることです。
|