Ce week-end a lieu à côté de Bonn l’OpenSQLCamp, en parallèle de la FrOSCon. Giuseppe Maxia nous parle aujourd’hui d’une technique utilisée dans certaines applications à fort trafic : le sharding. Mais à quoi sert le sharding ?
Quand on commence une application, un seul serveur SQL suffit généralement à absorber la charge. Si le trafic augmente et que les performances du serveur commencent à s’écrouler, on peut utiliser la réplication. Mais la réplication ne permet que d’augmenter le nombre de lectures possibles (read scaling) et pas le nombre d’écritures (write scaling). Cette limitation provient du fonctionnement même de la réplication car toutes les écritures doivent arriver sur le serveur maître. On peut alors imaginer de séparer les données selon certaines règles (dépendantes de l’application) de manière à avoir plusieurs masters sur lesquels on peut utiliser la réplication. Et voilà, nous venons d’inventer le sharding.
Giuseppe nous explique que le sharding est simple à mettre en place : il suffit de créer des règles permettant de dispatcher les données entre les différents masters. Malheureusement, le sharding est fragile : si, par exemple, vous changez les règles de dispatch, vous risquez de casser vos shards ! Pour simplifier le sharding, il existe un moteur de stockage récent, installable en tant que plugin pour MySQL 5.1 : Spider. Spider est basé sur le partitionnement et permet de créer des tables sur un serveur dont les données seront stockées sur des hosts distants. En gros, on utilise une pincée de partitionnement et une pincée de Federated…
Les démonstrations faites par Giuseppe montrent quand même que si Spider peut nous simplifier la tâche du sharding, la mise en place de tables avec Spider n’est pas si simple et demande un peu de doigté et de réflexion…
Mots-clefs : MySQL, OpenSQLCamp