Ce guide donne un aperçu de ce à quoi vous attendre, sur les plans fonctionnel et opérationnel, dans ClickHouse Cloud. Bien que ClickHouse Cloud repose sur la distribution ClickHouse open-source, il peut y avoir certaines différences d’architecture et d’implémentation. Vous pourriez trouver intéressant et utile, pour le contexte, ce billet de blog sur la manière dont nous avons conçu ClickHouse Cloud.
Architecture de ClickHouse Cloud
- La capacité de calcul et le stockage sont dissociés et peuvent donc être mis à l’échelle automatiquement de manière indépendante, ce qui vous évite de surprovisionner le stockage ou la capacité de calcul dans des configurations d’instance statiques.
- Le stockage hiérarchisé sur stockage objet et la mise en cache multiniveau offrent une évolutivité pratiquement illimitée et un bon rapport prix-performances, ce qui vous évite de dimensionner votre capacité de stockage à l’avance et de vous soucier de coûts de stockage élevés.
- La haute disponibilité est activée par défaut et la réplication est gérée de manière transparente, ce qui vous permet de vous concentrer sur le développement de vos applications ou l’analyse de vos données.
- La mise à l’échelle automatique pour les charges de travail continues et variables est activée par défaut, ce qui vous évite de dimensionner votre service à l’avance, d’augmenter la capacité de vos serveurs lorsque votre charge de travail augmente, ou de réduire manuellement leur capacité lorsque l’activité diminue
- La mise en veille transparente pour les charges de travail intermittentes est activée par défaut. Nous mettons automatiquement en pause vos ressources de calcul après une période d’inactivité et les redémarrons de manière transparente lorsqu’une nouvelle requête arrive, ce qui vous évite de payer pour des ressources inactives.
- Les contrôles avancés de mise à l’échelle permettent de définir un maximum d’auto-scaling pour mieux maîtriser les coûts, ou un minimum d’auto-scaling afin de réserver des ressources de calcul pour les applications ayant des exigences de performance spécifiques.
ClickHouse Cloud donne accès à un ensemble sélectionné de fonctionnalités de la version open source de ClickHouse. Les tableaux ci-dessous décrivent certaines fonctionnalités actuellement désactivées dans ClickHouse Cloud.
Moteurs de base de données et moteurs de table
Shared* correspondant. Vous n’avez pas à ajouter vous-même le préfixe Shared ou Replicated.
| Vous indiquez | Cloud utilise |
|---|
MergeTree (ou aucun moteur) | SharedMergeTree |
ReplacingMergeTree | SharedReplacingMergeTree |
SummingMergeTree | SharedSummingMergeTree |
AggregatingMergeTree | SharedAggregatingMergeTree |
CollapsingMergeTree | SharedCollapsingMergeTree |
VersionedCollapsingMergeTree | SharedVersionedCollapsingMergeTree |
GraphiteMergeTree | SharedGraphiteMergeTree |
Replicated* sont convertis en leurs équivalents Shared*. Cette substitution est visible dans SHOW CREATE TABLE, qui affiche le moteur Shared* même si votre instruction spécifiait la variante non préfixée.
Les moteurs suivants sont également pris en charge et utilisés tels quels :
- URL
- View
- MaterializedView
- GenerateRandom
- Null
- Buffer
- Memory
- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
- Kafka
ClickHouse Cloud prend en charge HTTPS, les interfaces natives et le MySQL wire protocol. D’autres interfaces, comme Postgres, seront bientôt prises en charge.
Les dictionnaires sont un moyen courant d’accélérer les recherches dans ClickHouse. ClickHouse Cloud prend actuellement en charge les dictionnaires issus de PostgreSQL, MySQL, de serveurs ClickHouse distants et locaux, de Redis, de MongoDB et de sources HTTP.
Nous prenons en charge les requêtes fédérées ClickHouse pour la communication entre clusters dans le cloud, ainsi que pour la communication avec des clusters ClickHouse externes autogérés. ClickHouse Cloud prend actuellement en charge les requêtes fédérées à l’aide des moteurs d’intégration suivants :
- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
Les requêtes fédérées avec certains moteurs de base de données et moteurs de table externes, comme SQLite, ODBC, JDBC, Redis, HDFS et Hive, ne sont pas encore prises en charge.
Fonctions définies par l’utilisateur
Comportement des paramètres
ImportantLes UDFs dans ClickHouse Cloud n’héritent pas des paramètres définis au niveau utilisateur. Elles s’exécutent avec les paramètres système par défaut.
- Les paramètres de session (définis via l’instruction
SET) ne sont pas transmis au contexte d’exécution des UDFs
- Les paramètres du profil utilisateur ne sont pas hérités par les UDFs
- Les paramètres définis au niveau de la requête ne s’appliquent pas lors de l’exécution des UDFs
Fonctionnalités expérimentales
Valeurs par défaut et considérations opérationnelles
max_parts_in_total: 10,000
max_parts_in_total pour les tables MergeTree a été abaissée de 100 000 à 10 000. Cette modification s’explique par le fait que nous avons observé qu’un grand nombre de data parts peut entraîner un démarrage lent des services dans le cloud. Un grand nombre de parts indique généralement une clé de partitionnement trop granulaire, généralement choisie par inadvertance et à éviter. Cette nouvelle valeur par défaut permettra de détecter ces cas plus tôt.
max_concurrent_queries: 1,000
100 à 1000 par rapport à la valeur par défaut afin de permettre davantage de requêtes concurrentes.
Cela se traduira par nombre de répliques * 1,000 requêtes concurrentes pour les services des niveaux d’offre proposés.
1000 requêtes concurrentes pour le service du niveau Basic, limité à une seule réplique, et 1000+ pour Scale et Enterprise,
selon le nombre de répliques configurées.
max_table_size_to_drop: 1,000,000,000,000
Administration avancée de la sécurité
