J'ai beaucoup lu sur les options disponibles. J'ai également mis la main sur High Performance MySQL 2nd edition, que je recommande vivement.
C'est ce que j'ai réussi à reconstituer :
Regroupement
Au sens général, la mise en grappe consiste à répartir la charge sur de nombreux serveurs qui, pour une application extérieure, apparaissent comme un seul serveur.
Cluster MySQL NDB
MySQL NDB Cluster est un moteur de stockage distribué, en mémoire, sans partage, avec réplication synchrone et partitionnement automatique des données (excusez-moi, j'emprunte littéralement au livre High Performance, mais ils l'ont très bien formulé). Il peut être une solution de haute performance pour certaines applications, mais les applications web ne fonctionnent généralement pas bien avec lui.
Le problème majeur est qu'au-delà des requêtes très simples (qui ne touchent qu'une seule table), le cluster devra généralement rechercher des données sur plusieurs nœuds, ce qui permet à la latence du réseau de s'immiscer et de ralentir considérablement le temps d'exécution des requêtes. Comme l'application traite le cluster comme un seul ordinateur, elle ne peut pas lui indiquer à partir de quel nœud il doit aller chercher les données.
En outre, l'exigence d'une utilisation en mémoire n'est pas réalisable pour de nombreuses grandes bases de données.
Séquoia continu
Il s'agit d'une autre solution de mise en grappe pour MySQL, qui agit comme un intergiciel au-dessus du serveur MySQL. Elle offre une réplication synchrone, un équilibrage de la charge et un basculement. Il garantit également que les requêtes obtiennent toujours les données de la dernière copie, en choisissant automatiquement un nœud qui possède les données les plus récentes.
J'ai lu quelques bonnes choses sur elle, et dans l'ensemble, elle semble assez prometteuse.
Fédération
La fédération est similaire à la mise en grappe, c'est pourquoi je l'ai également abordée ici. MySQL propose la fédération via le moteur de stockage fédéré. Comme la solution du cluster NDB, elle fonctionne bien pour les requêtes simples uniquement - mais encore moins bien que le cluster pour les requêtes compliquées (puisque la latence du réseau est beaucoup plus élevée).
Réplication et équilibrage de charge
MySQL a la capacité intégrée de créer des réplications d'une base de données sur différents serveurs. Cette fonction peut être utilisée pour de nombreuses raisons : répartition de la charge entre les serveurs, sauvegardes à chaud, création de serveurs de test et basculement.
La configuration de base de la réplication implique un serveur maître gérant principalement les écritures et un ou plusieurs esclaves gérant uniquement les lectures. Une variante plus avancée est celle de la maître-maître qui permet de faire évoluer les écritures également en ayant plusieurs serveurs qui écrivent en même temps.
Chaque configuration a ses avantages et ses inconvénients, mais le problème qu'elles partagent toutes est le décalage de la réplication. La réplication MySQL étant asynchrone, tous les nœuds ne disposent pas des données les plus récentes à tout moment. L'application doit donc être consciente de la réplication et intégrer des requêtes tenant compte de la réplication pour fonctionner comme prévu. Pour certaines applications, cela peut ne pas être un problème, mais si vous avez toujours besoin des données les plus récentes, les choses se compliquent quelque peu.
La réplication nécessite un certain équilibrage de la charge pour répartir la charge entre les nœuds. Il peut s'agir d'une simple modification du code de l'application ou de l'utilisation de solutions logicielles et matérielles dédiées.
Sharding et partionnement
Le sharding est une approche couramment utilisée pour faire évoluer les solutions de bases de données. Vous divisez les données en plus petits morceaux et les répartissez sur différents nœuds de serveur. Pour fonctionner efficacement, l'application doit être consciente de la modification du stockage des données, car elle doit savoir où trouver les informations dont elle a besoin.
Il existe des cadres d'abstraction qui permettent de gérer le partage des données, tels que Shards d'Hibernate Il s'agit d'une extension de l'ORM Hibernate (qui est malheureusement en Java. J'utilise PHP). HiveDB est une autre solution de ce type qui prend également en charge le rééquilibrage des shards.
Autres
Sphinx
Sphinx est un moteur de recherche en texte intégral, qui peut être utilisé pour bien plus que des recherches d'essai. Pour de nombreuses requêtes, il est beaucoup plus rapide que MySQL (en particulier pour le regroupement et le tri), et peut interroger des systèmes distants en parallèle et agréger les résultats - ce qui le rend très utile en cas d'utilisation de sharding.
En général, sphinx devrait être utilisé avec d'autres solutions de mise à l'échelle pour tirer le meilleur parti du matériel et de l'infrastructure disponibles. L'inconvénient est qu'une fois encore, le code de l'application doit connaître sphinx pour l'utiliser à bon escient.
Résumé
Les solutions de mise à l'échelle diffèrent en fonction des besoins de l'application qui en a besoin. Pour nous et pour la plupart des applications web, je pense que la réplication (probablement multi-maître) est la solution à adopter avec un équilibreur de charge distribuant la charge. Le sharding de zones problématiques spécifiques (tables énormes) est également indispensable pour pouvoir évoluer horizontalement.
Je vais aussi essayer Continuent Sequoia et voir s'il peut vraiment faire ce qu'il promet puisqu'il implique le moins de changements au code de l'application.
