PgDog

PgDog : La Solution Ultime pour le Scaling Horizontal de PostgreSQL

Dans le paysage actuel des bases de données, la gestion de la croissance des données et du trafic est un défi majeur. PgDog émerge comme une solution de pointe pour permettre aux entreprises de multiplier par n la capacité de leurs bases de données PostgreSQL. En tant que proxy polyvalent, PgDog agit simultanément comme un pooler de connexions, un répartiteur de charge (load balancer) et un moteur de base de données distribuée.

L'entreprise a récemment franchi une étape importante en levant 5,5 millions de dollars lors d'un tour de table en amorçage (seed round), confirmant ainsi l'intérêt croissant pour sa technologie capable de gérer plus de 2 millions de requêtes par seconde en production sur des volumes dépassant les 20 To de données.

Qu'est-ce que PgDog ?

PgDog est un proxy PostgreSQL conçu pour être une solution "drop-in", ce qui signifie qu'il ne nécessite aucune modification du code de votre application. Il se présente sous la forme d'un exécutable unique, déployable n'importe où, que ce soit sur site ou dans le cloud via Docker ou Helm.

Contrairement aux solutions traditionnelles, PgDog offre une abstraction complète de la couche de données. Que vous ayez besoin d'un simple pooler pour gérer des milliers de clients ou d'une architecture complexe de sharding distribué, PgDog coordonne l'ensemble des interactions avec vos serveurs PostgreSQL de manière transparente.

Les Fonctionnalités Clés de PgDog

L'architecture de PgDog repose sur trois piliers technologiques majeurs qui transforment la manière dont PostgreSQL est exploité à grande échelle.

1. Un Pooler de Connexions à Haute Performance

PgDog révolutionne la gestion des connexions grâce à son mode de transaction réel. Il est capable de partager seulement quelques connexions Postgres entre plus de 100 000 clients, le tout sans casser les fonctionnalités natives du moteur de base de données.

• Gestion de l'état de session : Support complet des commandes SET, des verrous consultatifs (advisory locks) et des mécanismes LISTEN/NOTIFY sans épinglage de connexion (connection pinning).
• Asynchrone et Multi-thread : Capacité de traiter plus de 50 000 transactions par seconde par thread, sans limites de longueur de requête ou de nombre de connexions.
• Requêtes préparées (Prepared Statements) : Compatibilité totale avec tous les pilotes clients (asyncpg, pgx, libpq, ruby-pg) avec un surcoût nul.

2. Un Load Balancer Intelligent (ALB pour base de données)

En tant qu'équilibreur de charge, PgDog distribue les lectures entre les différents réplicas, assurant ainsi une utilisation optimale de vos ressources matérielles.

• Séparation Lecture/Écriture (Read/Write Split) : Le proxy utilise un analyseur SQL interne pour router automatiquement les requêtes SELECT vers les réplicas et toutes les autres opérations vers le nœud primaire.
• Détection de Failover et de Santé : PgDog effectue des tests de santé (health checks) pour bloquer les réplicas obsolètes ou défaillants. Il détecte automatiquement les basculements du primaire pour rediriger le trafic d'écriture sans changement de configuration.
• Gestion de la latence : Il surveille le retard de réplication pour garantir la fraîcheur des données lues.

3. Base de Données Distribuée et Sharding

Le sharding avec PgDog se fait sans changer une seule ligne de votre application. Le proxy extrait la clé de sharding directement des requêtes SQL et les dirige vers le bon shard.

• Performance OLTP et OLAP : Utilisez des bases de données shardées comme un simple Postgres. Pour les analyses lourdes, PgDog supporte nativement le scatter/gather pour les opérations GROUP BY, COUNT(), AVG(), ORDER BY, MIN(), MAX() et COPY.
• Flexibilité de distribution : Shardez vos données selon n'importe quel critère via une configuration simple, compatible avec les types de données standards de PostgreSQL.

Une Cohérence Relationnelle et Distribuée

PgDog ne sacrifie jamais la cohérence pour la vitesse. Il maintient une conformité ACID totale, même à grande échelle.

• Transactions Cross-Shard : Écrivez des données sur tous les shards de manière atomique. En cas d'erreur, un rollback automatique est déclenché via les transactions préparées natives et le commit à deux phases (2PC).
• Tables Répliquées : Pour optimiser les performances, les tables qui n'ont pas besoin d'être shardées peuvent être stockées sur tous les shards, permettant des jointures locales ultra-rapides.
• Clés Primaires Entières : Pas besoin de passer aux UUID. PgDog génère automatiquement des clés primaires de type big integer de manière monotone directement dans le proxy.
• Mutation de Clé de Sharding : Déplacez des lignes entre les shards en utilisant de simples instructions UPDATE.
• Schéma Cohérent : Le DDL est automatiquement propagé sur tous les shards. Vos outils de migration favoris comme Alembic ou ActiveRecord fonctionnent immédiatement.

Cas d'Utilisation

Les entreprises utilisent PgDog pour résoudre des problèmes complexes de montée en charge :

• Scaling Horizontal Massif : Comme le souligne Sam R. de chez Modal, l'exécution de milliers de pods nécessite une gestion de connexions que seul PgDog a pu stabiliser.
• Remplacement de RDS Proxy : Des entreprises comme Ramp ont constaté une amélioration majeure de la scalabilité des connexions par rapport à RDS Proxy, supprimant ainsi les goulots d'étranglement de leur système.
• Sharding Géospatial : Earth Genome a pu déplacer une logique complexe de sharding géospatial de la couche applicative vers une configuration simple dans PgDog, accélérant ainsi les requêtes sur près de 4 milliards de lignes.
• Disponibilité Maximale : Tripstack a maintenu un temps de fonctionnement de 100 % malgré une ingestion de données record depuis l'adoption de PgDog.

Comment utiliser PgDog ?

L'installation et la configuration de PgDog sont conçues pour être rapides et intuitives.

Installation via Helm

Pour les environnements Kubernetes, l'installation se fait en deux commandes simples :

helm repo add pgdogdev https://helm.pgdog.dev
helm install pgdog pgdogdev/pgdog

Configuration de base (pgdog.toml)

Voici un exemple de configuration pour définir un pooler et des rôles de base :

# pgdog.toml
[general]
default_pool_size = 100

[[databases]]
name = "prod"
host = "10.0.0.1"
role = "primary"

[[databases]]
name = "prod"
host = "10.0.0.2"
role = "replica"

Pour le sharding, la configuration reste tout aussi simple en désignant les colonnes de distribution :

[[sharded_tables]]
database = "prod"
column = "tenant_id"

FAQ (Foire Aux Questions)

Q : PgDog nécessite-t-il de modifier mon application ? R : Non, PgDog est un proxy "drop-in". Il fonctionne avec vos pilotes existants comme libpq, pgx ou asyncpg sans changement de code.

Q : Comment PgDog gère-t-il les transactions sur plusieurs shards ? R : Il utilise le commit à deux phases (2PC) et les transactions préparées natives de PostgreSQL pour garantir l'atomicité et la cohérence ACID.

Q : Est-ce que PgDog supporte les fonctions d'agrégation en mode distribué ? R : Oui, il supporte nativement des opérations comme COUNT(), SUM(), AVG(), ainsi que les clauses GROUP BY et ORDER BY à travers plusieurs shards.

Q : Puis-je utiliser des clés primaires entières avec le sharding ? R : Absolument. PgDog génère des clés primaires big integer de manière centralisée dans le proxy, évitant ainsi la complexité des UUID.

Q : Quel est l'impact sur les outils de migration comme Alembic ? R : Aucun impact négatif. Le DDL est automatiquement appliqué de manière transversale sur tous les shards, rendant les outils de migration compatibles dès le départ.

"PgDog a été incroyablement fiable pour nous. C'est le genre d'infrastructure qui fonctionne silencieusement, au point qu'on n'a plus à y penser." — Maher Beg, Staff Software Engineer chez Ramp.