Pourquoi la séparation lecture-écriture peut améliorer les performances de la base de données
Veuillez consulter le blog ci-dessus. Selon le bon sens des bases de données, la séparation lecture-écriture peut effectivement améliorer les performances des bases de données, mais vous ne savez pas si vous en comprenez les principes sous-jacents. Par exemple, une machine lit et une autre écrit, mais les données doivent toujours être synchronisées, sinon le système n'aura aucun sens. Eh bien, la synchronisation n'est-elle pas une opération d'écriture ? Ce n'est donc pas essentiellement la même chose ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Mais il n'est pas nécessaire de synchroniser lors de la lecture. On a des performances élevées en lecture et on a des performances élevées en écriture. La séparation de la lecture et de l'écriture convient aux scénarios où la lecture est bien supérieure à l'écriture.
MySQL utilise de nombreux moteurs de stockage de bases de données, chacun présentant des avantages et des inconvénients. Certains ne prennent pas en charge les choses, mais ont des performances et une vitesse élevées ; certains lisent rapidement, mais écrivent très lentement, et d'autres sont tout le contraire ;... La séparation maître-esclave en lecture et en écriture peut tirer pleinement parti des avantages de chaque moteur de base de données. .
Votre question : Mais les données doivent encore être synchronisées . En fait, cela n’est pas considéré comme une synchronisation, car toutes les données sont un seul élément. Les données de la couche application sont écrites directement dans la bibliothèque principale, mais les données de la bibliothèque esclave sont restaurées à partir du binlog. De plus, la différence la plus importante est que la bibliothèque principale envoie le binlog à la bibliothèque esclave de manière asynchrone, ainsi que les données. la récupération à partir de la bibliothèque esclave est également asynchrone.
Même s'il n'y a pas de base de données esclave, la base de données principale doit toujours écrire les données du binlog sur le disque dur ou sur d'autres ordinateurs pour éviter une panne de la base de données. Lorsqu'un problème survient dans la base de données, le DBA peut uniquement restaurer les données précédentes du binlog.
Dans votre description : "Un pour lire et un pour écrire." Je suppose que vous êtes peut-être un débutant ou que vous n’avez jamais participé à un vrai projet. Les vrais projets en ligne consistent uniquement à lire et à écrire sur N stations et à sauvegarder sur M stations. Après séparation de la lecture et de l'écriture, N stations peuvent lire, N stations peuvent écrire et M stations peuvent être sauvegardées ou 1 station peut lire, 1 station peut écrire et M stations peuvent être sauvegardées.
L'objectif principal de la séparation de lecture et d'écriture est de partager la pression du serveur. Elle convient aux entreprises ayant des exigences moins strictes en matière de données en temps réel. Différents paramètres système peuvent être configurés selon les besoins pour faire face aux différents besoins de lecture et d'écriture, améliorant ainsi la fonctionnalité. performance globale de l’ensemble du système d’entreprise !