Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déchargement

L'amélioration des temps de réponse et l'augmentation des ressources disponibles pour les flux de travail critiques peuvent nécessiter de se débarrasser de la charge superflue. La plupart des solutions abordées dans cette section sont des décisions de compromis. Elles ont des conséquences sur l'application et doivent être soigneusement évaluées. Vous pouvez envisager ces solutions dans les cas suivants :

Les modifications immédiates sont les suivantes :

Avant d'entreprendre ces actions, évaluez-les dans le contexte des objectifs et des risques métier à long terme.

Charges de travail de lecture et d'écriture distinctes

Une technique fréquemment utilisée lors de l'exécution d'applications à technologie MySQL consiste à décharger les opérations de lecture de l'instance de base de données (principale) d'enregistreur vers un ou plusieurs réplicas de base de données en lecture seule. En déchargeant les lectures, vous pouvez réduire la charge globale sur l'instance de base de données principale et libérer de la place pour les écritures. Veillez à ne cibler que les lectures qui ne dépendent pas de la read-after-writecohérence immédiate des répliques. Une approche plus efficace consiste à déplacer tout le trafic de lecture vers la réplique et à prévoir une nouvelle tentative read-after-write en cas de retard de réplication. Certaines charges de travail de lecture indépendantes peuvent être déchargées, telles que les services de génération de rapports. D'autres lectures nécessiteront des modifications au niveau de l'application, où le contexte dans lequel la lecture a été émise est bien connu.

Une autre approche consiste à implémenter une solution de proxy de base de données en tant qu'intermédiaire entre l'application et la base de données, qui peut fournir la fonction de répartition de lecture/écriture et de routage des requêtes, sans que l'application en soit consciente. ProxySQL, MariaDB MaxScale, ScaleArc et Heimdall Data font partie des solutions de proxy compatibles MySQL disponibles. Ces produits offrent de nombreuses fonctionnalités supplémentaires, telles que la mise en cache ou le multiplexage des connexions. Lorsque vous êtes confronté à une augmentation soudaine du trafic et que vous implémentez une nouvelle technologie dans votre stack d'applications, nous vous recommandons de commencer par les fonctionnalités de base permettant de fractionner les read/write requêtes et de tester le comportement et les performances avant d'utiliser des fonctionnalités supplémentaires susceptibles d'avoir des effets secondaires imprévus.

Archiver ou purger les anciennes données

Une autre technique visant à améliorer les performances de la base de données est de décharger des données historiques sur une autre table, une autre base de données ou Amazon Simple Storage Service (Amazon S3). De nombreuses bases de données conservent toutes les données en ligne pendant tout l'historique de l'application. Dans des circonstances normales, dans une application standard destinée aux utilisateurs, cela permet aux utilisateurs de consulter l'historique de toutes leurs commandes. Lorsque la demande augmente soudainement, de nombreux utilisateurs actifs sur l'application sont probablement nouveaux ou sont en train de passer une nouvelle commande. Si les données historiques se trouvent en ligne, dans une seule table contenant des milliards de lignes, cela se complique. La table comporte probablement également des index volumineux. Les données de table et les index sont stockés dans une structure arborescente. La présence d'un plus grand nombre d'entrées dans une table nécessite un plus grand nombre de niveaux dans l'arborescence, ce qui nécessite davantage d' I/O opérations pour accéder aux lignes. Cela augmente le temps d'accès requis pour trouver des enregistrements individuels. Plus important encore, de grandes parties inutiles de l'index résident alors dans le cache des pages de la base de données (groupe de mémoires tampons InnoDB).

L'archivage des anciennes données dans une table séparée, une base de données distincte ou Amazon S3 peut réduire les temps d'accès pour les utilisateurs finaux, libérer un précieux cache et améliorer les performances globales des applications. L'archivage des anciennes données, avant l'événement (par exemple, en ne les conservant que 30 ou 90 jours), limite la taille des tables et des index des tables critiques. Cette modification nécessite que l'application soit modifiée pour interroger les anciennes données à partir d'un emplacement secondaire uniquement pour le petit sous-ensemble d'utilisateurs qui demandent explicitement à consulter les données historiques.

Différer les processus ETL non critiques

Les extractions du système de base de données principal pour les processus ETL peuvent présenter un risque de stabilité pour les charges de travail hautement transactionnelles et simultanées dans des conditions d'hyperéchelle. Les processus ETL sont connus pour les caractéristiques suivantes :

Processus ETL variables ou imprévisibles (par exemple, les requêtes telles que INSERT INTO ... SELECT FROM ...;) s'ajoutent à la variabilité globale en matière de charge et de conflit, augmentant ainsi le risque de stabilité).

Dans la mesure du possible, différez ou réduisez la fréquence d'exécution des processus ETL, en particulier s'ils ne fournissent pas de fonctions critiques. Pour les processus ETL critiques, modifiez-les de manière à ce qu'ils puissent fonctionner dans des unités de travail limitées, comme le traitement de lots d'un nombre fixe de lignes (par exemple, en utilisant des clauses LIMIT), l'utilisation de transactions distinctes ou l'extraction de plus petites quantités de données sur une période prolongée afin de réduire les pics de demande de ressources de l'instance de base de données.

Désactiver les fonctionnalités moins critiques des applications

La dégradation normale de l'expérience utilisateur ou la suppression des fonctionnalités secondaires lors de la gestion d'un afflux de demandes permet de préserver les ressources de la base de données pour les fonctions critiques. Cela peut nécessiter une légère modification de l'expérience client, mais un flux différent est préférable à une interruption du site. Peut-être que la personnalisation sur la page d'accueil du site qui adresse toujours un appel à la base de données peut être temporairement désactivée. Vous pouvez également arrêter de présenter des offres personnalisées aux clients qui reviennent lorsqu'ils sélectionnent des produits. La désactivation temporaire des fonctionnalités peut permettre la mise en cache ou la diffusion de la page sans nécessiter l'accès à la base de données.

D'autres exemples incluent un frontend doté d'un mécanisme d'interrogation qui vérifie les modifications des données nécessitant un appel de base de données. La réduction de la fréquence d'interrogation se traduira immédiatement par une diminution du nombre d'appels de base de données. Les interfaces utilisateur qui nécessitent une pagination ou qui offrent aux utilisateurs la possibilité de récupérer des ensembles de résultats triés plus éloignés du premier résultat nécessitent des appels de base de données de plus en plus coûteux. Limitez le nombre de pages d'un ensemble de résultats afin de protéger la base de données contre les appels de base de données les plus coûteux. Utilisez des indicateurs de fonctionnalités dans la couche d'application pour permettre à l'équipe des opérations de désactiver ou de dégrader des fonctionnalités à mesure que la charge de l'application ou de la base de données augmente.