Architecture de ClickHouse Cloud
ClickHouse Cloud réduit considérablement la complexité opérationnelle et le coût d’exploitation de ClickHouse à grande échelle. Inutile de dimensionner votre déploiement à l’avance, de configurer la réplication pour assurer la haute disponibilité, de répartir manuellement vos données en segments, d’augmenter la capacité de vos serveurs lorsque votre charge de travail augmente, ou de la réduire lorsque vous ne les utilisez pas — nous nous en chargeons pour vous. Ces avantages découlent des choix architecturaux à la base 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.
Fonctionnalités
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
ClickHouse Cloud est, par défaut, un service à haute disponibilité et répliqué, basé sur la famille de moteurs de table SharedMergeTree. Lorsque vous créez une table avec un moteur standard de la famille MergeTree, Cloud le remplace automatiquement par le moteurShared* correspondant. Vous n’avez pas à ajouter vous-même le préfixe Shared ou Replicated.
Les moteurs
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 de table suivants sont également pris en charge et utilisés tels quels. Le moteur de table MySQL pris en charge est distinct du moteur de base de données MySQL non pris en charge :
- URL
- View
- MaterializedView
- GenerateRandom
- Null
- Buffer
- Memory
IcebergS3etIcebergAzure- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
- Kafka
PaimonS3 et PaimonAzure peuvent être activés sur certains services ClickHouse Cloud. Contactez le Support pour confirmer leur disponibilité.
Interfaces
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.Dictionaries
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.Requêtes fédérées
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 :IcebergS3etIcebergAzurePaimonS3etPaimonAzure(expérimental ; contactez le Support pour connaître la disponibilité)- Deltalake
- Hudi
- MySQL
- MongoDB
- NATS
- RabbitMQ
- PostgreSQL
- S3
Fonctions définies par l’utilisateur
Les fonctions SQL et exécutables définies par l’utilisateur sont en disponibilité générale dans ClickHouse Cloud. Consultez Fonctions définies par l’utilisateur dans Cloud.Comportement des paramètres
Cela signifie :- 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
Les fonctionnalités expérimentales sont désactivées dans les services ClickHouse Cloud afin de garantir la stabilité des déploiements de services.Collections nommées
Les collections nommées créées avec DDL peuvent être activées sur certains services ClickHouse Cloud. Contactez le Support pour confirmer leur disponibilité. Les collections nommées définies dans des fichiers de configuration ne sont pas disponibles, car les utilisateurs ne peuvent pas modifier les fichiers de configuration du serveur dans ClickHouse Cloud.Valeurs par défaut et considérations opérationnelles
Voici les paramètres par défaut des services ClickHouse Cloud. Dans certains cas, ces paramètres sont définis de manière fixe afin de garantir le bon fonctionnement du service ; dans d’autres, ils peuvent être ajustés.Limites opérationnelles
max_parts_in_total: 10,000
La valeur par défaut du paramètre 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
Ce paramètre serveur a été augmenté de 100 à 1000 par rapport à la valeur par défaut afin de permettre davantage de requêtes concurrentes.
Cela se traduit par nombre de répliques * 1,000 requêtes concurrentes pour un service. Un service à réplique unique prend en charge jusqu’à 1000 requêtes concurrentes, quel que soit le niveau. Les services à plusieurs répliques des niveaux Scale et Enterprise prennent en charge jusqu’à 1000 requêtes concurrentes par réplique.