J'ai fait BEAUCOUP de lecture sur les options disponibles. J'ai également mis la main sur High Performance MySQL 2nd edition, que je recommande vivement.
Voici ce que j'ai réussi à reconstituer :
Cluster
Le clustering au sens général consiste à répartir la charge sur de nombreux serveurs qui apparaissent à une application externe comme un seul serveur.
Cluster MySQL NDB
MySQL NDB Cluster est un moteur de stockage distribué, en mémoire et 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 mis là-bas). Il peut s'agir d'une solution haute performance pour certaines applications, mais les applications Web ne fonctionnent généralement pas bien dessus.
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'infiltrer et de ralentir considérablement le temps de réalisation des requêtes. Étant donné que l'application traite le cluster comme un seul ordinateur, elle ne peut pas lui dire à partir de quel nœud récupérer les données.
De plus, l'exigence en mémoire n'est pas réalisable pour de nombreuses bases de données volumineuses.
Séquoia continu
Il s'agit d'une autre solution de clustering pour MySQL, qui agit comme un middleware au-dessus du serveur MySQL. Il offre la réplication synchrone, l'équilibrage de charge et le basculement. Il garantit également que les requêtes obtiennent toujours les données de la dernière copie, en choisissant automatiquement un nœud contenant les nouvelles données.
J'ai lu quelques bonnes choses dessus, et dans l'ensemble, cela semble plutôt prometteur.
Fédération
La fédération est similaire au clustering, donc je l'ai également tiré ici. MySQL propose la fédération via le moteur de stockage fédéré. Semblable à la solution de cluster NDB, cela fonctionne bien avec des requêtes simples uniquement - mais pire encore, 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. Cela peut être utilisé pour de nombreuses choses - répartir la charge entre les serveurs, les sauvegardes à chaud, la création de serveurs de test et le 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 du master-master configuration, qui permet également de dimensionner les écritures en ayant plusieurs serveurs écrivant en même temps.
Chaque configuration a ses avantages et ses inconvénients, mais un problème qu'ils partagent tous est le décalage de réplication - puisque la réplication MySQL est asynchrone, tous les nœuds n'ont pas les données les plus récentes à tout moment. Cela nécessite que l'application soit consciente de la réplication et intègre des requêtes compatibles avec 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 deviennent un peu compliquées.
La réplication nécessite un certain équilibrage de charge pour répartir la charge entre les nœuds. Cela peut se résumer à quelques modifications du code de l'application ou à l'utilisation de solutions logicielles et matérielles dédiées.
Sharding et partitionnement
Le partage est une approche couramment utilisée pour mettre à l'échelle les solutions de base de données. Vous divisez les données en fragments plus petits et les répartissez sur différents nœuds de serveur. Cela nécessite que l'application soit consciente de la modification du stockage des données pour fonctionner efficacement, car elle doit savoir où trouver les informations dont elle a besoin.
Il existe des cadres d'abstraction disponibles pour aider à gérer le partage de données, tels que Hibernate Shards , 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 partitions.
Autres
Sphinx
Sphinx est un moteur de recherche en texte intégral, qui peut être utilisé pour bien plus que des recherches de test. 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 avec le sharding.
En général, sphinx doit ê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'encore une fois, vous avez besoin du code de l'application pour connaître le sphinx afin de 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 voie à suivre avec un équilibreur de charge répartissant la charge. Le partage de zones problématiques spécifiques (tables immenses) est également indispensable pour pouvoir évoluer horizontalement.
Je vais également essayer Continuent Sequoia et voir s'il peut vraiment faire ce qu'il promet puisqu'il impliquera le moins de changements au code de l'application.
