Démarrage rapide pour ClickHouse Managed Postgres

Beta

ClickHouse Managed Postgres est un Postgres de qualité entreprise reposant sur un stockage NVMe, offrant des performances jusqu’à 10 fois supérieures pour les charges de travail limitées par le disque par rapport au stockage en réseau comme EBS. Ce guide de démarrage rapide est divisé en deux parties :

Partie 1 : Prenez en main Postgres sur NVMe et découvrez ses performances
Partie 2 : Débloquez l’analytique en temps réel en l’intégrant à ClickHouse

ClickHouse Managed Postgres est actuellement disponible sur AWS dans plusieurs régions et en Public Beta.

Dans ce guide de démarrage rapide, vous allez :

Créez une instance Managed Postgres avec des performances optimisées par le NVMe
Chargez 1 million d’événements d’exemple et observez la vitesse du NVMe
Exécutez des requêtes et bénéficiez de performances à faible latence
Répliquez les données vers ClickHouse pour l’analytique en temps réel
Interrogez directement ClickHouse depuis Postgres à l’aide de pg_clickhouse

Partie 1 : Premiers pas avec NVMe Postgres

Créer une base de données

Pour créer un nouveau service ClickHouse Managed Postgres, cliquez sur le bouton New service dans la liste des services de la Cloud Console. Vous pourrez ensuite sélectionner Postgres comme type de base de données.

Créer un service ClickHouse Managed Postgres

Saisissez un nom pour votre instance de base de données et cliquez sur Create service. Vous serez redirigé vers la page Overview.

Présentation de ClickHouse Managed Postgres

Votre instance ClickHouse Managed Postgres sera provisionnée et prête à l'emploi dans 3 à 5 minutes.

Connectez-vous à votre base de données

Dans la barre latérale gauche, vous verrez un bouton Connect. Cliquez dessus pour afficher vos informations de connexion et vos chaînes de connexion dans plusieurs formats.

Boîte de dialogue Connect de ClickHouse Managed Postgres

Copiez la chaîne de connexion psql et connectez-vous à votre base de données. Vous pouvez également utiliser n'importe quel client compatible Postgres, comme DBeaver, ou n'importe quelle bibliothèque d'application.

Découvrez les performances du NVMe

Voyons concrètement les performances offertes par le NVMe. Commencez par activer le chronométrage dans psql pour mesurer le temps d'exécution des requêtes :

Créez deux tables d'exemple pour les événements et les utilisateurs :

CREATE TABLE events (
   event_id SERIAL PRIMARY KEY,
   event_name VARCHAR(255) NOT NULL,
   event_type VARCHAR(100),
   event_timestamp TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   event_data JSONB,
   user_id INT,
   user_ip INET,
   is_active BOOLEAN DEFAULT TRUE,
   created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
   user_id SERIAL PRIMARY KEY,
   name VARCHAR(100),
   country VARCHAR(50),
   platform VARCHAR(50)
);

Insérez maintenant 1 million d'événements et observez la vitesse du NVMe :

INSERT INTO events (event_name, event_type, event_timestamp, event_data, user_id, user_ip)
SELECT
   'Event ' || gs::text AS event_name,
   CASE
       WHEN random() < 0.5 THEN 'click'
       WHEN random() < 0.75 THEN 'view'
       WHEN random() < 0.9 THEN 'purchase'
       WHEN random() < 0.98 THEN 'signup'
       ELSE 'logout'
   END AS event_type,
   NOW() - INTERVAL '1 day' * (gs % 365) AS event_timestamp,
   jsonb_build_object('key', 'value' || gs::text, 'additional_info', 'info_' || (gs % 100)::text) AS event_data,
   GREATEST(1, LEAST(1000, FLOOR(POWER(random(), 2) * 1000) + 1)) AS user_id,
   ('192.168.1.' || ((gs % 254) + 1))::inet AS user_ip
FROM
   generate_series(1, 1000000) gs;

INSERT 0 1000000
Time: 3596.542 ms (00:03.597)

Insérez 1 000 utilisateurs :

INSERT INTO users (name, country, platform)
SELECT
    first_names[first_idx] || ' ' || last_names[last_idx] AS name,
    CASE
        WHEN random() < 0.25 THEN 'India'
        WHEN random() < 0.5 THEN 'USA'
        WHEN random() < 0.7 THEN 'Germany'
        WHEN random() < 0.85 THEN 'China'
        ELSE 'Other'
    END AS country,
    CASE
        WHEN random() < 0.2 THEN 'iOS'
        WHEN random() < 0.4 THEN 'Android'
        WHEN random() < 0.6 THEN 'Web'
        WHEN random() < 0.75 THEN 'Windows'
        WHEN random() < 0.9 THEN 'MacOS'
        ELSE 'Linux'
    END AS platform
FROM
    generate_series(1, 1000) AS seq
    CROSS JOIN LATERAL (
        SELECT
            array['Alice', 'Bob', 'Charlie', 'Diana', 'Eve', 'Frank', 'Grace', 'Hank', 'Ivy', 'Jack', 'Liam', 'Olivia', 'Noah', 'Emma', 'Sophia', 'Benjamin', 'Isabella', 'Lucas', 'Mia', 'Amelia', 'Aarav', 'Riya', 'Arjun', 'Ananya', 'Wei', 'Li', 'Huan', 'Mei', 'Hans', 'Klaus', 'Greta', 'Sofia'] AS first_names,
            array['Smith', 'Johnson', 'Williams', 'Brown', 'Jones', 'Garcia', 'Miller', 'Davis', 'Martinez', 'Taylor', 'Anderson', 'Thomas', 'Jackson', 'White', 'Harris', 'Martin', 'Thompson', 'Moore', 'Lee', 'Perez', 'Sharma', 'Patel', 'Gupta', 'Reddy', 'Zhang', 'Wang', 'Chen', 'Liu', 'Schmidt', 'Müller', 'Weber', 'Fischer'] AS last_names,
            1 + (seq % 32) AS first_idx,
            1 + ((seq / 32)::int % 32) AS last_idx
    ) AS names;

Exécuter des requêtes sur vos données

Exécutons maintenant quelques requêtes pour voir à quelle vitesse Postgres répond avec le stockage NVMe.

Agrégez 1 million d'événements par type :

SELECT event_type, COUNT(*) as count 
FROM events 
GROUP BY event_type 
ORDER BY count DESC;

 event_type | count  
------------+--------
 click      | 499523
 view       | 375644
 purchase   | 112473
 signup     |  12117
 logout     |    243
(5 rows)

Time: 114.883 ms

Requête avec filtrage JSONB et plage de dates :

SELECT COUNT(*) 
FROM events 
WHERE event_timestamp > NOW() - INTERVAL '30 days'
  AND event_data->>'additional_info' LIKE 'info_5%';

 count 
-------
  9042
(1 row)

Time: 109.294 ms

Jointure des événements avec les utilisateurs :

SELECT u.country, COUNT(*) as events, AVG(LENGTH(e.event_data::text))::int as avg_json_size
FROM events e
JOIN users u ON e.user_id = u.user_id
GROUP BY u.country
ORDER BY events DESC;

 country | events | avg_json_size 
---------+--------+---------------
 USA     | 383748 |            52
 India   | 255990 |            52
 Germany | 223781 |            52
 China   | 127754 |            52
 Other   |   8727 |            52
(5 rows)

Time: 224.670 ms

Partie 2 : Ajoutez des analyses en temps réel avec ClickHouse

Tandis que Postgres excelle dans les charges de travail transactionnelles (OLTP), ClickHouse est conçu spécifiquement pour les requêtes analytiques (OLAP) sur de grands ensembles de données. En intégrant les deux, vous bénéficiez du meilleur des deux mondes :

Postgres pour les données transactionnelles de votre application (insertions, mises à jour, recherches par clé)
ClickHouse pour des analyses sur des milliards de lignes en moins d’une seconde

Cette section vous explique comment répliquer vos données Postgres vers ClickHouse et les interroger de manière transparente.

Configurer l'intégration ClickHouse

Maintenant que nous disposons de tables et de données dans Postgres, répliquons ces tables vers ClickHouse à des fins d'analytics. Commencez par cliquer sur Sync to ClickHouse dans la barre latérale. Vous pouvez ensuite cliquer sur Replicate data in ClickHouse.

Intégration ClickHouse Managed Postgres vide

Dans le formulaire qui suit, vous pouvez saisir un nom pour votre intégration et sélectionner une instance ClickHouse existante vers laquelle répliquer les données. Si vous ne disposez pas encore d'une instance ClickHouse, vous pouvez en créer une directement depuis ce formulaire.

Formulaire d’intégration ClickHouse Managed Postgres

Cliquez sur Suivant pour accéder au sélecteur de tables. Vous n'avez qu'à :

Sélectionnez une base de données ClickHouse dans laquelle répliquer les données.
Développez le schéma public et sélectionnez les tables users et events que nous avons créées précédemment.
Cliquez sur Replicate data to ClickHouse.

Sélecteur de tables de ClickHouse Managed Postgres

Le processus de réplication va démarrer et vous serez redirigé vers la page d'aperçu de l'intégration. Étant la première intégration, la mise en place de l'infrastructure initiale peut prendre 2 à 3 minutes. En attendant, découvrons la nouvelle extension pg_clickhouse.

Interroger ClickHouse depuis Postgres

L'extension pg_clickhouse vous permet d'interroger les données ClickHouse directement depuis Postgres en utilisant le SQL standard. Cela signifie que votre application peut utiliser Postgres comme couche de requête unifiée pour les données transactionnelles et analytiques. Consultez la documentation complète pour plus de détails.

Activez l'extension :

CREATE EXTENSION pg_clickhouse;

Créez ensuite une connexion de serveur étranger vers ClickHouse. Utilisez le driver http avec le port 8443 pour les connexions sécurisées :

CREATE SERVER ch FOREIGN DATA WRAPPER clickhouse_fdw
       OPTIONS(driver 'http', host '<clickhouse_cloud_host>', dbname '<database_name>', port '8443');

Remplacez <clickhouse_cloud_host> par le nom d'hôte de votre ClickHouse et <database_name> par la base de données sélectionnée lors de la configuration de la réplication. Vous trouverez le nom d'hôte dans votre service ClickHouse en cliquant sur Connect dans la barre latérale.

Note

Si vous utilisez la console ClickHouse Cloud pour exécuter des requêtes SQL, accordez à l’utilisateur admin de la console l’accès au serveur étranger :

GRANT USAGE ON FOREIGN SERVER ch TO chpg_console_admin;

À présent, associons l'utilisateur Postgres aux credentials du service ClickHouse :

CREATE USER MAPPING FOR CURRENT_USER SERVER ch 
OPTIONS (user 'default', password '<clickhouse_password>');

Importez maintenant les tables ClickHouse dans un schéma Postgres :

CREATE SCHEMA organization;
IMPORT FOREIGN SCHEMA "<database_name>" FROM SERVER ch INTO organization;

Remplacez <database_name> par le même nom de base de données que celui utilisé lors de la création du serveur.

Vous pouvez désormais voir toutes les tables ClickHouse dans votre client Postgres :

Visualisez vos analyses en action

Revenez à la page d'intégration. Vous devriez constater que la réplication initiale est terminée. Cliquez sur le nom de l'intégration pour afficher les détails.

Liste des analyses de ClickHouse Managed Postgres

Cliquez sur le nom du service pour ouvrir la console ClickHouse et consulter vos tables répliquées.

Tables répliquées de ClickHouse Managed Postgres dans ClickHouse

Comparer les performances de Postgres et ClickHouse

Exécutons maintenant quelques requêtes analytiques et comparons les performances entre Postgres et ClickHouse. Notez que les tables répliquées utilisent la convention de nommage public_<table_name>.

Requête 1 : Utilisateurs les plus actifs

Cette requête identifie les utilisateurs les plus actifs à l'aide de plusieurs agrégations :

-- Via ClickHouse
SELECT 
    user_id,
    COUNT(*) as total_events,
    COUNT(DISTINCT event_type) as unique_event_types,
    SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) as purchases,
    MIN(event_timestamp) as first_event,
    MAX(event_timestamp) as last_event
FROM organization.public_events
GROUP BY user_id
ORDER BY total_events DESC
LIMIT 10;

 user_id | total_events | unique_event_types | purchases |        first_event         |         last_event         
---------+--------------+--------------------+-----------+----------------------------+----------------------------
       1 |        31439 |                  5 |      3551 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
       2 |        13235 |                  4 |      1492 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
...
(10 rows)

Time: 163.898 ms   -- ClickHouse
Time: 554.621 ms   -- Same query on Postgres

Requête 2 : Engagement des utilisateurs par pays et par plateforme

Cette requête joint les événements aux utilisateurs et calcule les métriques d'engagement :

-- Via ClickHouse
SELECT 
    u.country,
    u.platform,
    COUNT(DISTINCT e.user_id) as users,
    COUNT(*) as total_events,
    ROUND(COUNT(*)::numeric / COUNT(DISTINCT e.user_id), 2) as events_per_user,
    SUM(CASE WHEN e.event_type = 'purchase' THEN 1 ELSE 0 END) as purchases
FROM organization.public_events e
JOIN organization.public_users u ON e.user_id = u.user_id
GROUP BY u.country, u.platform
ORDER BY total_events DESC
LIMIT 10;

 country | platform | users | total_events | events_per_user | purchases 
---------+----------+-------+--------------+-----------------+-----------
 USA     | Android  |   115 |       109977 |             956 |     12388
 USA     | Web      |   108 |       105057 |             972 |     11847
 USA     | iOS      |    83 |        84594 |            1019 |      9565
 Germany | Android  |    85 |        77966 |             917 |      8852
 India   | Android  |    80 |        68095 |             851 |      7724
...
(10 rows)

Time: 170.353 ms   -- ClickHouse
Time: 1245.560 ms  -- Same query on Postgres

Comparaison des performances :

Requête	Postgres (NVMe)	ClickHouse (via pg_clickhouse)	Gain de vitesse
Top utilisateurs (5 agrégations)	555 ms	164 ms	3,4x
Engagement utilisateur (JOIN + agrégations)	1 246 ms	170 ms	7,3x

Nettoyage

Pour supprimer les ressources créées dans ce guide de démarrage rapide :

Commencez par supprimer l’intégration ClickPipe du service ClickHouse
Supprimez ensuite l’instance ClickHouse Managed Postgres dans la Cloud Console

Beta

Vous pouvez suivre ce chemin vous-même, l’automatiser avec un script ou le confier à un agent IA. Passez à la vue Cloud UI pour afficher la version console.

Cette page explique comment provisionner ClickHouse Managed Postgres, charger des données, les répliquer vers ClickHouse et exécuter des requêtes sur celles-ci, le tout depuis la ligne de commande avec le ClickHouse CLI (clickhousectl) et psql. Les commandes s’exécutent en mode non interactif ; clickhousectl renvoie du JSON avec --json.

Prérequis

Installez la ClickHouse CLI :

curl https://clickhouse.com/cli | sh

Vous avez également besoin de psql (outils du client PostgreSQL ; sous macOS, brew install libpq) et de jq.

Les opérations en écriture (create, delete) nécessitent une authentification par clé API ; la connexion OAuth est en lecture seule :

clickhousectl cloud auth login --api-key <YOUR_KEY> --api-secret <YOUR_SECRET>

Vous pouvez également définir les variables d’environnement CLICKHOUSE_CLOUD_API_KEY et CLICKHOUSE_CLOUD_API_SECRET. Vérifiez avec clickhousectl cloud auth status ; vous devriez voir une entrée avec la portée read/write.

Partie 1 : Créer Postgres et charger les données

Créer un service Postgres

Créez le service et enregistrez la réponse ; le mot de passe n’est affiché qu’une seule fois :

clickhousectl cloud postgres create \
  --name quickstart-pg \
  --region us-east-1 \
  --size m6gd.large \
  --pg-version 18 \
  --json > pg.json

La réponse inclut l’ID du service, le nom d’hôte et une chaîne de connexion prête à l’emploi :

{
  "id": "3b5a3112-bf02-82d0-bd02-fbe67d5caa7a",
  "name": "quickstart-pg",
  "provider": "aws",
  "region": "us-east-1",
  "postgresVersion": "18",
  "size": "m6gd.large",
  "storageSize": 118,
  "haType": "none",
  "state": "creating",
  "createdAt": "2026-07-22T13:21:22Z",
  "hostname": "quickstart-pg-c1406b50.pg7dd324nz0a1qm1fqskxbjn7m.c0.us-east-1.aws.pg.clickhouse.cloud",
  "username": "postgres",
  "password": "vV6cfEr2p_-TzkCDrZOx",
  "connectionString": "postgres://postgres:vV6cfEr2p_-TzkCDrZOx@quickstart-pg-c1406b50.pg7dd324nz0a1qm1fqskxbjn7m.c0.us-east-1.aws.pg.clickhouse.cloud:5432/postgres?channel_binding=require",
  "isPrimary": true,
  "tags": []
}

Extrayez les éléments nécessaires pour la suite de ce guide :

PG_ID=$(jq -r .id pg.json)
PG_URL=$(jq -r .connectionString pg.json)

Si le mot de passe est perdu, générez-en un nouveau avec clickhousectl cloud postgres reset-password $PG_ID --generate.

Attendez que le service soit provisionné

Le provisionnement prend quelques minutes. Vérifiez régulièrement jusqu’à ce que l’état soit running :

while [ "$(clickhousectl cloud postgres get "$PG_ID" --json | jq -r .state)" != "running" ]; do
  sleep 15
done

Charger des données d’exemple

Créez deux tables, puis insérez 1 million d’événements avec psql :

psql "$PG_URL" <<'SQL'
\timing
CREATE TABLE events (
   event_id SERIAL PRIMARY KEY,
   event_name VARCHAR(255) NOT NULL,
   event_type VARCHAR(100),
   event_timestamp TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   event_data JSONB,
   user_id INT,
   user_ip INET,
   is_active BOOLEAN DEFAULT TRUE,
   created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
   user_id SERIAL PRIMARY KEY,
   name VARCHAR(100),
   country VARCHAR(50),
   platform VARCHAR(50)
);

INSERT INTO events (event_name, event_type, event_timestamp, event_data, user_id, user_ip)
SELECT
   'Event ' || gs::text AS event_name,
   CASE
       WHEN random() < 0.5 THEN 'click'
       WHEN random() < 0.75 THEN 'view'
       WHEN random() < 0.9 THEN 'purchase'
       WHEN random() < 0.98 THEN 'signup'
       ELSE 'logout'
   END AS event_type,
   NOW() - INTERVAL '1 day' * (gs % 365) AS event_timestamp,
   jsonb_build_object('key', 'value' || gs::text, 'additional_info', 'info_' || (gs % 100)::text) AS event_data,
   GREATEST(1, LEAST(1000, FLOOR(POWER(random(), 2) * 1000) + 1)) AS user_id,
   ('192.168.1.' || ((gs % 254) + 1))::inet AS user_ip
FROM
   generate_series(1, 1000000) gs;

INSERT INTO users (name, country, platform)
SELECT
    first_names[first_idx] || ' ' || last_names[last_idx] AS name,
    CASE
        WHEN random() < 0.25 THEN 'India'
        WHEN random() < 0.5 THEN 'USA'
        WHEN random() < 0.7 THEN 'Germany'
        WHEN random() < 0.85 THEN 'China'
        ELSE 'Other'
    END AS country,
    CASE
        WHEN random() < 0.2 THEN 'iOS'
        WHEN random() < 0.4 THEN 'Android'
        WHEN random() < 0.6 THEN 'Web'
        WHEN random() < 0.75 THEN 'Windows'
        WHEN random() < 0.9 THEN 'MacOS'
        ELSE 'Linux'
    END AS platform
FROM
    generate_series(1, 1000) AS seq
    CROSS JOIN LATERAL (
        SELECT
            array['Alice', 'Bob', 'Charlie', 'Diana', 'Eve', 'Frank', 'Grace', 'Hank', 'Ivy', 'Jack', 'Liam', 'Olivia', 'Noah', 'Emma', 'Sophia', 'Benjamin', 'Isabella', 'Lucas', 'Mia', 'Amelia', 'Aarav', 'Riya', 'Arjun', 'Ananya', 'Wei', 'Li', 'Huan', 'Mei', 'Hans', 'Klaus', 'Greta', 'Sofia'] AS first_names,
            array['Smith', 'Johnson', 'Williams', 'Brown', 'Jones', 'Garcia', 'Miller', 'Davis', 'Martinez', 'Taylor', 'Anderson', 'Thomas', 'Jackson', 'White', 'Harris', 'Martin', 'Thompson', 'Moore', 'Lee', 'Perez', 'Sharma', 'Patel', 'Gupta', 'Reddy', 'Zhang', 'Wang', 'Chen', 'Liu', 'Schmidt', 'Müller', 'Weber', 'Fischer'] AS last_names,
            1 + (seq % 32) AS first_idx,
            1 + ((seq / 32)::int % 32) AS last_idx
    ) AS names;
SQL

Timing is on.
CREATE TABLE
Time: 86.029 ms
CREATE TABLE
Time: 80.962 ms
INSERT 0 1000000
Time: 7120.357 ms (00:07.120)
INSERT 0 1000
Time: 84.807 ms

L’insertion de 1 M de lignes s’effectue en environ 7 secondes sur m6gd.large (la plus petite taille), grâce au stockage NVMe. Vérifiez-le avec une requête ; le nombre de lignes varie d’une exécution à l’autre, car les données sont générées avec random() :

psql "$PG_URL" -c "SELECT event_type, COUNT(*) FROM events GROUP BY event_type ORDER BY 2 DESC;"

Partie 2 : Répliquer dans ClickHouse

Créer un service ClickHouse

Créez un service dans la même région et enregistrez la réponse ; le mot de passe n’apparaît que dans la réponse de création :

clickhousectl cloud service create \
  --name quickstart-ch \
  --region us-east-1 \
  --json > ch.json

CH_ID=$(jq -r .service.id ch.json)
CH_PASSWORD=$(jq -r .password ch.json)

Attendez qu’il soit actif ; le ClickPipe nécessite une destination active :

while [ "$(clickhousectl cloud service get "$CH_ID" --json | jq -r .state)" != "running" ]; do
  sleep 15
done

Pour utiliser plutôt un service existant, définissez CH_ID à partir de clickhousectl cloud service list et CH_PASSWORD sur le mot de passe de l’utilisateur default, requis à l’étape pg_clickhouse.

Répliquer les tables vers ClickHouse

Créez un Postgres CDC ClickPipe sur le service ClickHouse, en pointant vers le nom d’hôte de ClickHouse Managed Postgres. Le pipe copie les lignes existantes, puis maintient ClickHouse synchronisé avec les changements ultérieurs :

PG_HOST=$(jq -r .hostname pg.json)
PG_PASSWORD=$(jq -r .password pg.json)

clickhousectl cloud clickpipe create postgres "$CH_ID" \
  --name quickstart-sync \
  --host "$PG_HOST" \
  --pg-database postgres \
  --username postgres \
  --password "$PG_PASSWORD" \
  --table-mapping public.events:public_events \
  --table-mapping public.users:public_users \
  --json > pipe.json

PIPE_ID=$(jq -r .id pipe.json)

Remarques :

Les tables répliquées sont créées dans la base de données default du service ClickHouse, selon les cibles de --table-mapping
La publication et le slot de réplication sont créés automatiquement, la publication étant limitée aux tables mappées ; passez --publication-name pour utiliser celle que vous gérez vous-même
Utilisez directement le nom d’hôte de Postgres ; la réplication n'est pas prise en charge via PgBouncer

Attendez que le pipe passe à l’état `Running`

Le pipe passe par Provisioning, Setup et (pour les tables plus volumineuses) Snapshot avant de passer à l’état Running, ce qui prend environ 4 minutes pour le premier pipe sur un service. Failed et InternalError sont des états terminaux :

while :; do
  STATE=$(clickhousectl cloud clickpipe get "$CH_ID" "$PIPE_ID" --json | jq -r .state)
  case "$STATE" in
    Running) break ;;
    Failed|InternalError) echo "ClickPipe entered terminal state: $STATE" >&2; exit 1 ;;
  esac
  sleep 15
done

Interroger les données répliquées dans ClickHouse

Exécutez des requêtes SQL sur le service ClickHouse directement depuis la CLI. Le premier appel crée automatiquement un endpoint Query API et une clé API limitée à ce service :

clickhousectl cloud service query --id "$CH_ID" \
  --query "SELECT count() FROM public_events"

Provisioning Query API endpoint + key for service 'quickstart-ch'...
1000000

Les nouvelles écritures dans Postgres sont répliquées en continu. Insérez une ligne, puis interrogez régulièrement jusqu’à ce que le nombre atteigne 1 000 001 (généralement en moins d’une minute) :

psql "$PG_URL" -c "INSERT INTO events (event_name, event_type, user_id, user_ip) VALUES ('cdc-test', 'click', 42, '10.0.0.1');"

while [ "$(clickhousectl cloud service query --id "$CH_ID" \
  --query "SELECT count() FROM public_events")" != "1000001" ]; do
  sleep 10
done

Interroger ClickHouse depuis Postgres

L’extension pg_clickhouse permet à Postgres de servir de couche de requête unifiée pour les données transactionnelles et analytiques. Récupérez le nom d’hôte HTTPS de ClickHouse, puis configurez l’extension via psql :

CH_HOST=$(clickhousectl cloud service get "$CH_ID" --json \
  | jq -r '.endpoints[] | select(.protocol=="https") | .host')

psql "$PG_URL" <<SQL
CREATE EXTENSION pg_clickhouse;
CREATE SERVER ch FOREIGN DATA WRAPPER clickhouse_fdw
       OPTIONS(driver 'http', host '$CH_HOST', dbname 'default', port '8443');
CREATE USER MAPPING FOR CURRENT_USER SERVER ch
       OPTIONS (user 'default', password '$CH_PASSWORD');
CREATE SCHEMA organization;
IMPORT FOREIGN SCHEMA "default" FROM SERVER ch INTO organization;
SQL

Le heredoc est volontairement non guillemeté, afin que le shell substitue $CH_HOST et $CH_PASSWORD avant que le SQL n'arrive à Postgres. Les tables répliquées sont désormais visibles comme des tables étrangères dans le schéma organization ; les requêtes qui les ciblent s'exécutent dans ClickHouse.

Mesurées sur m6gd.large avec ce jeu de données, les requêtes analytiques s'exécutent 6 à 9 fois plus vite via les tables étrangères (par exemple, un GROUP BY avec 5 agrégations : 176 ms via ClickHouse contre 1 133 ms en local ; un JOIN avec agrégations : 298 ms contre 2 764 ms).

Nettoyage

Supprimez d’abord le ClickPipe, puis le service Postgres. La suppression d’un service entraîne la suppression définitive de toutes ses données :

clickhousectl cloud clickpipe delete "$CH_ID" "$PIPE_ID"
clickhousectl cloud postgres delete "$PG_ID"

Un service ClickHouse en cours d’exécution ne peut pas être supprimé directement. Arrêtez-le, attendez qu’il soit stopped, puis supprimez-le :

clickhousectl cloud service stop "$CH_ID"

while [ "$(clickhousectl cloud service get "$CH_ID" --json | jq -r .state)" != "stopped" ]; do
  sleep 10
done

clickhousectl cloud service delete "$CH_ID"

Démarrage rapide pour ClickHouse Managed Postgres

Partie 1 : Premiers pas avec NVMe Postgres

Créer une base de données

Connectez-vous à votre base de données

Découvrez les performances du NVMe

Exécuter des requêtes sur vos données

Partie 2 : Ajoutez des analyses en temps réel avec ClickHouse

Configurer l'intégration ClickHouse

Interroger ClickHouse depuis Postgres

Visualisez vos analyses en action

Comparer les performances de Postgres et ClickHouse

Nettoyage

Prérequis

Partie 1 : Créer Postgres et charger les données

Créer un service Postgres

Attendez que le service soit provisionné

Charger des données d’exemple

Partie 2 : Répliquer dans ClickHouse

Créer un service ClickHouse

Répliquer les tables vers ClickHouse

Attendez que le pipe passe à l’état Running

Interroger les données répliquées dans ClickHouse

Interroger ClickHouse depuis Postgres

Nettoyage

Attendez que le pipe passe à l’état `Running`