Comment la taille de la base de données affecte les performances: théorie vs réalité
Il y a beaucoup de choses qui disent que la taille de la base de données ne devrait pas affecter les performances dans une large mesure. Tant que les index des tables tiennent en mémoire, la base de données doit rester performante.
Mais quelle est la réalité? Si l'architecture de la base de données n'est pas la meilleure, les index ne tiennent pas en mémoire et il y a potentiellement beaucoup de données redondantes. Des gains importants doivent-ils être réalisés simplement en supprimant les données redondantes? J'estime que 60 à 80% des données de ma base de données pourraient être supprimées.
Je crois que la réduction de la taille de la base de données et l'augmentation du RAM afin que les index puissent tenir en mémoire donneraient une augmentation significative des performances qui donnerait une marge de manœuvre pendant quelques mois pour réarchitecturer le système.
Existe-t-il également d'autres facteurs tels que les E/S, la fragmentation, l'ensemble de données de travail, etc., qui affectent les performances en fonction de la taille de la base de données?
Cela dépend entièrement de ce que vous faites avec les données.
Pour les transactions d'insertion/mise à jour/suppression de base qui n'affectent que quelques lignes, la croissance de la taille des données n'est probablement pas un facteur important. La base de données utilisera des index en mémoire pour accéder à la page correcte. Vous obtenez plus d'échecs de cache lorsque les tables ne tiennent plus en mémoire. Cependant, la surcharge peut être légère - selon la base de données, les configurations de base de données et les configurations matérielles.
Si vous effectuez des requêtes qui nécessitent des analyses de table complètes, vos performances vont augmenter de façon linéaire ou pire avec la taille des données. Les index peuvent en fait aggraver la situation, en randomisant les accès aux pages, ce qui garantit à peu près les erreurs de cache.
Une alternative à plus de mémoire est une vitesse de disque améliorée - le disque à semi-conducteurs peut fournir une amélioration considérable.
Le simple fait de disposer de plus de données est peu susceptible d'affecter les performances, sauf si les tables sont utilisées dans les requêtes. Les données sont-elles redondantes dans une table ou entre les tables? Avoir de grandes tables qui ne sont jamais utilisées est compliqué, mais a un impact minimal sur les performances. Il est imaginable que si vous avez des millions de tables inutiles, alors la compilation des requêtes pourrait commencer à prendre plus de temps.
La règle de réglage numéro un AMM (Ajouter plus de mémoire) est simple. C'est aussi une solution très coûteuse et, au final, qui n'est pas efficace en cas de problème de sélectivité. Même si une base de données tient complètement en mémoire, les performances de l'application peuvent être mauvaises. Dans le pire des cas, en raison du verrouillage et du verrouillage lors d'exécutions SQL très sélectives. Ceux-ci devraient être corrigés en premier. Une raison est la simultanéité qui revient à frapper - et à maintenir - les pauses si chaque SQL accède à toutes les données d'une table à chaque fois.
Assurez-vous qu'aucun SQL n'accède à plus de lignes que nécessaire. C'est le moyen le plus efficace de maintenir de bonnes performances. Une base de données normale sait comment gérer io et effectue une certaine forme de mise en cache des données les plus utilisées.
Si votre application a déjà minimisé tous les accès possibles et que vous utilisez déjà les systèmes de disques les plus rapides, pensez à utiliser de véritables baies de mémoire flash. Ils peuvent augmenter les performances à un autre niveau.
Veuillez référer ces messages:
- Quelle taille une base de données MySQL peut-elle obtenir avant que les performances commencent à se dégrader
- Pourquoi MySQL pourrait être lent avec de grandes tables?
Conseils pour rendre vos données aussi petites que possible:
Concevez vos tables pour minimiser leur espace sur le disque. Cela peut entraîner d'énormes améliorations en réduisant la quantité de données écrites et lues sur le disque. Les tables plus petites nécessitent normalement moins de mémoire principale pendant que leur contenu est activement traité pendant l'exécution de la requête. Toute réduction d'espace pour les données de table entraîne également des index plus petits qui peuvent être traités plus rapidement.
MySQL prend en charge de nombreux moteurs de stockage différents (types de table) et formats de ligne. Pour chaque table, vous pouvez décider de la méthode de stockage et d'indexation à utiliser. Le choix du format de tableau approprié pour votre application peut vous apporter un gain de performances important.
Vous pouvez obtenir de meilleures performances pour une table et réduire l'espace de stockage en utilisant les techniques répertoriées ici: - Utilisez les types de données les plus efficaces (les plus petits) possibles. MySQL possède de nombreux types spécialisés qui économisent de l'espace disque et de la mémoire. Par exemple, utilisez les types d'entiers plus petits si possible pour obtenir des tables plus petites. MEDIUMINT est souvent un meilleur choix que INT car une colonne MEDIUMINT utilise 25% d'espace en moins.
Déclarez les colonnes comme NON NULES si possible. Cela accélère tout et vous économisez un bit par colonne. Si vous avez vraiment besoin de NULL dans votre application, vous devez absolument l'utiliser. Évitez simplement de l'avoir sur toutes les colonnes par défaut.
Pour les tables MyISAM, si vous ne disposez d'aucune colonne de longueur variable (colonnes VARCHAR, TEXT ou BLOB), un format de ligne de taille fixe est utilisé.
Les tables InnoDB utilisent un format de stockage compact. Dans les versions de MySQL antérieures à 5.0.3, les lignes InnoDB contiennent des informations redondantes, telles que le nombre de colonnes et la longueur de chaque colonne, même pour les colonnes de taille fixe. Par défaut, les tables sont créées au format compact (ROW_FORMAT = COMPACT). La présence du format de ligne compact diminue l'espace de stockage de ligne d'environ 20% au prix d'une utilisation accrue du processeur pour certaines opérations. Si votre charge de travail est typique et limitée par les taux d'accès au cache et la vitesse du disque, elle sera probablement plus rapide. S'il s'agit d'un cas rare limité par la vitesse du processeur, il peut être plus lent.
Le format compact InnoDB modifie également la façon dont les colonnes CHAR contenant des données UTF-8 sont stockées. Avec ROW_FORMAT = REDUNDANT, un UTF-8 CHAR (N) occupe 3 × N octets, étant donné que la longueur maximale d'un caractère codé UTF-8 est de trois octets. De nombreuses langues peuvent être écrites principalement à l'aide de caractères UTF-8 à un octet, donc une longueur de stockage fixe gaspille souvent de l'espace. Avec le format ROW_FORMAT = COMPACT, InnoDB alloue une quantité variable de stockage dans la plage de N à 3 × N octets pour ces colonnes en supprimant les espaces de fin si nécessaire. La longueur de stockage minimale est conservée en N octets pour faciliter les mises à jour sur place dans les cas typiques.
L'index primaire d'une table doit être aussi court que possible. Cela rend l'identification de chaque ligne facile et efficace
Créez uniquement les index dont vous avez vraiment besoin. Les index sont bons pour la récupération mais mauvais lorsque vous devez stocker des données rapidement. Si vous accédez à une table principalement en recherchant une combinaison de colonnes, créez un index sur celles-ci. La première partie de l'index doit être la colonne la plus utilisée. Si vous utilisez toujours de nombreuses colonnes lors de la sélection dans la table, la première colonne de l'index doit être celle avec le plus de doublons pour obtenir une meilleure compression de l'index.
Dans certaines circonstances, il peut être avantageux de diviser en deux une table qui est numérisée très souvent. Cela est particulièrement vrai s'il s'agit d'une table au format dynamique et qu'il est possible d'utiliser une table au format statique plus petite qui peut être utilisée pour trouver les lignes pertinentes lors de l'analyse de la table.