Associer la workload à un point de départ
Consultez la documentation produit liée pour connaître la disponibilité, les régions et les limitations actuelles. ClickHouse Managed Postgres est actuellement en public beta ; voir son quickstart.
Pour un self-managed ClickHouse server ou d’autres options locales, consultez les deployment modes.
Exemple : résultats de rapports et historique des exécutions
Supposons qu’une application traite des fichiers téléversés, produise des rapports et doive conserver des résultats interrogeables ainsi qu’un historique des exécutions. Avant de choisir une base de données, distinguez les lignes de résultats des enregistrements d’exécution :- Résultats : les requêtes récupèrent-elles quelques lignes pour un seul rapport, ou agrègent-elles des données provenant de nombreux rapports, jeux de données et intervalles de temps ? Quelle table est susceptible d’atteindre des centaines de millions de lignes ?
- Enregistrements d’exécution : un unique enregistrement immuable est-il écrit à la fin d’une exécution, ou l’application doit-elle coordonner l’attribution des jobs en cours et les transitions de statut ?
- Exactitude : plusieurs enregistrements doivent-ils être modifiés au sein d’une même transaction ? La base de données doit-elle garantir l’unicité ou empêcher deux workers de revendiquer le même job ?
- Fraîcheur : au bout de combien de temps une écriture réussie doit-elle être visible, et les requêtes peuvent-elles tolérer une copie analytique incomplète ou différée ?
Exécutions terminées et résultats analytiques
Un service ClickHouse dans ClickHouse Cloud est un bon candidat lorsque le workload dominant consiste à analyser des lignes de résultat et que les enregistrements d’exécution peuvent être ajoutés une fois l’exécution terminée. Une petite table de metadata ne justifie pas à elle seule une seconde database. Concevez et testez la manière dont les lecteurs distinguent une exécution complète d’une exécution partiellement ingérée. Définissez des identifiants d’exécution stables, le comportement de retry, ainsi que le traitement des lignes de résultat en double. Des inserts distincts dans une table de résultats et dans une table d’historique d’exécutions ne doivent pas être traités comme une unique transaction portant sur plusieurs tables. Si vous stockez plusieurs versions d’un enregistrement d’exécution, définissez comment les requêtes sélectionnent la version courante. ReplacingMergeTree prend en charge la deduplication au moment de la query avecFINAL ; l’exactitude ne doit pas dépendre du fait que les background merges ont déjà eu lieu. La référence update décrit un autre mécanisme de mise à jour et ses limites. Il ne faut supposer d’aucun de ces deux patterns qu’il offre des garanties transactionnelles de type PostgreSQL.
État transactionnel des jobs
Envisagez ClickHouse Managed Postgres lorsque la table des exécutions fait aussi office de file d’attente de travail transactionnelle ou de système de référence : par exemple, lorsqu’un worker doit s’attribuer un job de manière atomique alors que d’autres workers se le disputent, ou lorsque plusieurs enregistrements applicatifs doivent être modifiés conjointement, avec application de contraintes. Postgres peut également répondre aux requêtes de reporting. N’ajoutez un service analytique que si les exigences réelles de performance des requêtes, de concurrence ou d’isolation le justifient, plutôt que de partir du principe que toute application de reporting nécessite deux bases de données.Transactions et analytics ensemble
Lorsque les deux workloads justifient des services distincts, conservez l’état transactionnel dans Postgres et répliquez les tables nécessaires vers ClickHouse à l’aide de ClickPipes ou WalShadow. Tenez compte du décalage de réplication et continuez à utiliser la source transactionnelle pour les décisions qui exigent l’état actuel de l’application. La réplication n’inscrit pas une écriture Postgres et une lecture ClickHouse dans une même transaction. L’extension pg_clickhouse permet d’accéder à ClickHouse via Postgres. Un point d’entrée de requête partagé ne transforme pas pour autant les deux services en un seul database engine et ne dispense pas de prendre en compte la fraîcheur des données.Vérifier l’adéquation avant le provisionnement
Notez un petit ensemble de requêtes représentatives et testez-les sur des volumes de données réalistes. Incluez à la fois des recherches ciblées et des agrégats portant sur l’ensemble de l’historique, la charge concurrente que vous prévoyez, ainsi que les cas d’exactitude qui importent pour votre application. Communiquez le schéma, la forme des requêtes, la taille du matériel ou du service et le comportement d’ingestion en même temps que tout résultat de benchmark. Pour un déploiement managé, vérifiez également :- Les exigences en matière de Region, de réseau, de contrôle d’accès et de récupération.
- La durée d’activité attendue, les données stockées, les sauvegardes et les frais de transfert, dans le guide de facturation de ClickHouse Cloud ou le guide tarifaire de Managed Postgres.
- La capacité d’un workload analytique intermittent à tolérer le délai de connexion associé à la mise en veille automatique.
- La responsabilité de l’équipe concernant la conception du schéma, les tentatives de reprise applicatives, l’optimisation des requêtes et la maîtrise des coûts, même lorsque le service gère l’infrastructure.