Retour d’expérience sur le partitionnement des bases de données relationnelles de GitHub

• GitHub a démarré il y a plus de 10 ans avec RoR et une unique instance MySQL

• Le partitionnement a commencé en 2019, suivi de deux ans de travaux variés

→ En 2021, la charge sur la base de données avait diminué de 50 %

1. Partitionnement virtuel

• Séparation virtuelle au niveau de la couche applicative avant de déplacer les tables réelles

• Regroupement des tables en domaines de schéma, avec application stricte des frontières à l’aide d’un SQL Linter

→ Pour rendre le partitionnement ultérieur plus sûr

• Vérification des frontières virtuelles avec Query Linter et Transaction Linter

2. Déplacer les données sans interruption de service

• Utilisation de la fonctionnalité Vertical Sharding de Vitess

→ Déploiement de VTGate dans un cluster Kubernetes, puis changement du point de connexion

• Introduction d’un processus de write-cutover

→ Utilisation de la fonctionnalité de réplication de MySQL pour alimenter les données vers un autre cluster

→ Multiplexage des connexions clients MySQL avec ProxySQL

Résultat

• En 2019, mysql1, qui était alors un cluster unique, répondait en moyenne à 950 000 requêtes par seconde

• En 2021, la charge a été répartie sur plusieurs clusters, avec en moyenne 1,2 million de requêtes par seconde tout en divisant par deux la charge des hôtes