Solutions MySQL dans PostgreSQL : architecture Polar pour des performances élevées

# # Intégration de solutions MySQL dans PostgreSQL : Innovations architecturales pour des performances élevées

À la conférence PG BootCamp 2026, Alexey Kopytov (auteur de sysbench et ancien développeur chez MySQL AB/Percona) a présenté une conférence sur le portage d'optimisations de l'écosystème MySQL vers PostgreSQL. Le point clé : tirer parti de solutions éprouvées pour renforcer la tolérance aux pannes et les performances de PostgreSQL dans les systèmes à forte charge. D'intérêt particulier : la mise en œuvre de la technologie de séparation compute-stockage, adaptée par l'équipe Tantor à partir d'Alibaba PolarDB.

L'avantage principal de cette approche est de conserver une compatibilité totale avec PostgreSQL tout en augmentant significativement le débit. Contrairement au sharding ou aux solutions distribuées (Citus, Greenplum), l'architecture Tantor Polar gère les requêtes cross-shard sans sacrifier les garanties ACID, ce qui est crucial pour les systèmes OLTP.

Classification des solutions architecturales pour les SGBD

Alexey Kopytov a proposé une classification claire des approches existantes pour la séparation des nœuds compute et stockage :

• Sharding et systèmes MPP (Greenplum, Citus) : séparation au niveau de l'analyseur SQL. Problème : absence de cohérence au niveau d'un point unique dans le temps (xid/SCN)
• SGBD transactionnels distribués (Spanner, YugabyteDB) : traitement des transactions sur les nœuds stockage
• Architectures « LOG is DB » (Amazon Aurora, Neon) : primauté du journal des modifications, traitement WAL sur le stockage
• Architecture Polar (Tantor Polar) : séparation directement au-dessus de la couche stockage

La distinction clé de l'approche Polar est de minimiser les modifications au cœur de PostgreSQL. Toutes les optimisations sont implémentées au niveau du système de fichiers (PolarFS), ce qui permet :

• 100 % de compatibilité avec les applications existantes (y compris 1C)
• Évitement de modifications invasives au cœur de PostgreSQL
• Support des outils de sauvegarde existants

Architecture Tantor Polar : Mise en œuvre technique

Le système repose sur trois composants clés :

• PolarFS : système de fichiers haute performance sur RDMA/NVMe-oF
• Réseau RDMA : pour la communication entre nœuds compute et stockage
• PostgreSQL modifié : avec des changements minimaux au sous-système I/O

Une fonctionnalité remarquable est l'utilisation de Linux MD Cluster comme couche de base pour les périphériques de blocs. Cette solution offre :

• Des latences d'accès aux données comparables à un SSD local (5-10 μs)
• Une mise à l'échelle transparente des nœuds compute indépendante du stockage
• Support du mode Active-Active sur les nœuds RW

Important : PolarFS fonctionne via l'interface POSIX standard, éliminant le besoin de modifications au cœur de PostgreSQL. Tous les changements sont confinés au pilote du système de fichiers, simplifiant grandement l'intégration en amont et la maintenance.

Comparaison avec Oracle RAC et autres solutions

Bien que conceptuellement similaire à Oracle RAC, les différences sont significatives :

• Protocole de transfert de données : Polar utilise NVMe-oF sur RDMA, RAC un protocole propriétaire
• Niveau de séparation : Polar sépare au niveau du système de fichiers, RAC au niveau ASM
• Open source : PolarFS sera publié en open source, contrairement à ASM

L'implémentation RDMA mérite une mention spéciale. Les premières tentatives (dans PostgresPro 10-11) nécessitaient des modifications profondes au cœur de PostgreSQL. Tantor a adopté une approche non invasive via le pilote du système de fichiers, permettant :

• Élimination des problèmes de latence d'accès asymétrique
• Performances uniformes sur tous les nœuds compute
• Préservation du mécanisme standard de gestion WAL

Points clés à retenir

• Compatibilité sans compromis : Tantor Polar supporte toutes les fonctionnalités de PostgreSQL, y compris les JOIN complexes et les transactions
• Performances RDMA : latences équivalentes à un SSD local (5-10 μs) sur le réseau
• Évolutivité : compute et stockage évoluent indépendamment
• Ouverture : PolarFS sera disponible sous licence open source
• Prêt pour la production : la solution est déjà utilisée chez XData Gen.3 avec une configuration 3 stockage + N compute

Détails techniques de mise en œuvre

Composants clés de l'architecture :

// Exemple d'intégration RDMA dans le sous-système I/O
static int polarfs_submit_io(struct io_request *req) {
    if (use_rdma) {
        return rdma_send(req->buffer, req->length);
    }
    return posix_write(req->fd, req->buffer, req->length);
}

Les optimisations se concentrent sur trois domaines :

• Gestion des tampons : mise en cache des métadonnées sur les nœuds compute
• Gestion WAL : envois RDMA asynchrones avec accusés de réception
• Gestionnaire de verrous : implémentation distribuée sans point de défaillance unique

Une attention particulière a été portée aux cas limites :

• Récupération après chute de connexion RDMA
• Gestion des latences réseau asymétriques
• Garantie d'atomicité des opérations d'écriture

Les benchmarks avec PolarFS montrent :

• Augmentation du débit de 35-40 % sous forte charge
• Latences au 99e percentile réduites de 2,3x
• Transactions par seconde maximales en hausse de 28 %

Conclusion

L'approche de Tantor montre comment le portage de solutions entre écosystèmes SGBD peut générer des gains majeurs. La clé du succès : une invasivité minimale et un focus sur la compatibilité. L'architecture Polar ouvre de nouvelles possibilités d'évolutivité pour PostgreSQL dans des scénarios qui nécessitaient auparavant des changements radicaux d'applications ou un passage à NoSQL.

Notamment, l'implémentation ne requiert aucun matériel spécialisé : juste un support réseau RDMA et NVMe-oF. Cela la rend accessible à un large éventail d'organisations confrontées à des charges croissantes sur leurs clusters PostgreSQL existants.

— Editorial Team