Quelle taille une base de données MySQL peut-elle atteindre avant que les performances ne commencent à se dégrader

Question

À quel moment une base de données MySQL commence-t-elle à perdre en performances ?

• La taille physique de la base de données est-elle importante ?
• Le nombre d’enregistrements est-il important ?
• La dégradation des performances est-elle linéaire ou exponentielle ?

J'ai ce que je pense être une grande base de données, avec environ 15 millions d'enregistrements qui occupent près de 2 Go.Sur la base de ces chiffres, y a-t-il une incitation pour moi à nettoyer les données, ou suis-je en sécurité pour leur permettre de continuer à évoluer pendant encore quelques années ?

Answer 1

La taille physique de la base de données n'a pas d'importance.Le nombre d'enregistrements n'a pas d'importance.

D'après mon expérience, le plus gros problème que vous rencontrerez n'est pas la taille, mais le nombre de requêtes que vous pouvez gérer à la fois.Très probablement, vous devrez passer à une configuration maître/esclave afin que les requêtes de lecture puissent s'exécuter sur les esclaves et que les requêtes d'écriture soient exécutées sur le maître.Cependant, si vous n'êtes pas encore prêt, vous pouvez toujours modifier vos index pour les requêtes que vous exécutez afin d'accélérer les temps de réponse.Vous pouvez également apporter de nombreuses modifications à la pile réseau et au noyau sous Linux qui vous aideront.

Le mien a atteint 10 Go, avec seulement un nombre modéré de connexions et il a très bien géré les demandes.

Je me concentrerais d'abord sur vos index, puis demanderais à un administrateur de serveur d'examiner votre système d'exploitation, et si tout cela ne vous aide pas, il est peut-être temps de mettre en œuvre une configuration maître/esclave.

Answer 2

En général, c’est une question très subtile et pas du tout anodine.je vous encourage à lire mysqlperformanceblog.com et MySQL hautes performances.Je pense vraiment qu'il n'y a pas de réponse générale à cette question.

Je travaille sur un projet qui possède une base de données MySQL avec près de 1 To de données.Le facteur d’évolutivité le plus important est la RAM.Si les index de vos tables tiennent en mémoire et que vos requêtes sont hautement optimisées, vous pouvez traiter un nombre raisonnable de requêtes avec une machine moyenne.

Le nombre d'enregistrements est important, en fonction de l'apparence de vos tables.C'est une différence d'avoir beaucoup de champs varchar ou seulement quelques entiers ou longs.

La taille physique de la base de données est également importante :pensez aux sauvegardes, par exemple.En fonction de votre moteur, vos fichiers de base de données physiques augmentent, mais ne diminuent pas, par exemple avec innodb.Ainsi, la suppression d’un grand nombre de lignes n’aide pas à réduire vos fichiers physiques.

Il y a beaucoup de problèmes à résoudre et, comme dans de nombreux cas, le diable se cache dans les détails.

Answer 3

La taille de la base de données est-ce important.Si vous disposez de plusieurs tables contenant plus d’un million d’enregistrements, les performances commencent effectivement à se dégrader.Le nombre d’enregistrements affecte bien sûr les performances : MySQL peut être lent avec de grandes tables.Si vous atteignez un million d'enregistrements, vous rencontrerez des problèmes de performances si les index ne sont pas correctement définis (par exemple, aucun index pour les champs dans les "instructions WHERE" ou les "conditions ON" dans les jointures).Si vous atteignez 10 millions d'enregistrements, vous commencerez à avoir des problèmes de performances même si tous vos indices sont corrects.Les mises à niveau matérielles - en ajoutant plus de mémoire et plus de puissance de processeur, en particulier de mémoire - contribuent souvent à réduire les problèmes les plus graves en augmentant à nouveau les performances, au moins dans une certaine mesure.Par exemple 37 signaux sont passés de 32 Go de RAM à 128 Go de RAM pour le serveur de base de données Basecamp.

Answer 4

Je me concentrerais d'abord sur vos index, puis demanderais à un administrateur de serveur d'examiner votre système d'exploitation, et si tout cela ne vous aide pas, il est peut-être temps de procéder à une configuration maître/esclave.

C'est vrai.Une autre chose qui fonctionne généralement consiste simplement à réduire la quantité de données utilisées à plusieurs reprises.Si vous avez des "anciennes données" et des "nouvelles données" et que 99 % de vos requêtes fonctionnent avec de nouvelles données, déplacez simplement toutes les anciennes données vers une autre table - et ne la regardez pas ;)

-> Jetez un oeil à partitionnement.

Answer 5

2 Go et environ 15 millions d'enregistrements constituent une très petite base de données - j'en ai exécuté des bien plus grandes sur un pentium III (!) et tout a toujours fonctionné assez vite.Si le vôtre est lent, il s'agit d'un problème de conception de base de données/application, pas d'un problème MySQL.

Answer 6

Il est inutile de parler de « performances de la base de données », « performances des requêtes » est un meilleur terme ici.Et la réponse est :cela dépend de la requête, des données sur lesquelles elle opère, des index, du matériel, etc.Vous pouvez avoir une idée du nombre de lignes qui seront analysées et des index qui seront utilisés avec la syntaxe EXPLAIN.

2 Go ne comptent pas vraiment comme une « grande » base de données – c’est plutôt une taille moyenne.

Answer 7

Faites également attention aux jointures complexes.La complexité des transactions peut être un facteur important en plus du volume des transactions.

La refactorisation de requêtes lourdes offre parfois une amélioration considérable des performances.

Answer 8

Une fois, j'ai été invité à examiner un MySQL qui avait "cessé de fonctionner".J'ai découvert que les fichiers DB résidaient sur un filer Network Appliance monté avec NFS2 et avec une taille de fichier maximale de 2 Go.Et bien sûr, la table qui avait cessé d’accepter les transactions faisait exactement 2 Go sur le disque.Mais en ce qui concerne la courbe de performances, on m'a dit que ça fonctionnait comme un champion jusqu'à ce que ça ne marche plus du tout !Cette expérience me rappelle toujours qu'il existe toujours des dimensions au-dessus et en dessous de celle que l'on soupçonne naturellement.

Answer 9

Un point à considérer est également la finalité du système et des données au quotidien.

Par exemple, pour un système avec surveillance GPS des voitures, il n'est pas pertinent de demander des données sur les positions de la voiture au cours des mois précédents.

Ainsi, les données peuvent être transmises à d'autres tables historiques pour une éventuelle consultation et réduire les temps d'exécution des requêtes quotidiennes.

Answer 10

Je gère actuellement une base de données MySQL sur l'infrastructure cloud d'Amazon qui a atteint 160 Go.Les performances des requêtes sont bonnes.Ce qui est devenu un cauchemar, ce sont les sauvegardes, les restaurations, l'ajout d'esclaves ou tout ce qui concerne l'ensemble des données, ou même le DDL sur de grandes tables.Obtenir une importation propre d'un fichier de vidage est devenu problématique.Afin de rendre le processus suffisamment stable pour être automatisé, divers choix ont dû être faits pour donner la priorité à la stabilité plutôt qu'aux performances.Si jamais nous devions nous remettre d’un sinistre à l’aide d’une sauvegarde SQL, nous serions en panne pendant plusieurs jours.

La mise à l'échelle horizontale de SQL est également assez pénible et conduit dans la plupart des cas à l'utiliser d'une manière que vous n'aviez probablement pas l'intention lorsque vous avez choisi de mettre vos données dans SQL en premier lieu.Les fragments, les esclaves de lecture, le multi-maître, etc., ce sont toutes des solutions vraiment merdiques qui ajoutent de la complexité à tout ce que vous faites avec la base de données, et aucune d'entre elles ne résout le problème ;ne fait que l'atténuer à certains égards.Je suggère fortement d'envisager de déplacer certaines de vos données hors de MySQL (ou de n'importe quel SQL) lorsque vous commencez à approcher un ensemble de données d'une taille où ce type de choses devient un problème.

Answer 11

Les performances peuvent se dégrader en quelques milliers de lignes si la base de données n'est pas conçue correctement.

Si vous avez des index appropriés, utilisez des moteurs appropriés (n'utilisez pas MyISAM là où plusieurs DML sont attendus), utilisez le partitionnement, allouez la mémoire correcte en fonction de l'utilisation et bien sûr avez une bonne configuration du serveur, MySQL peut gérer des données même en téraoctets !

Il existe toujours des moyens d'améliorer les performances de la base de données.

Answer 12

Cela dépend de votre requête et de votre validation.

Par exemple, j'ai travaillé avec une table de 100 000 médicaments qui a une colonne de nom générique où il y a plus de 15 caractères pour chaque médicament dans cette table. J'ai posé une requête pour comparer le nom générique des médicaments entre deux tables. La requête prend plus de minutes à exécuter. De même, si vous comparez les médicaments à l'aide de l'index des médicaments, en utilisant une colonne d'identification (comme indiqué ci-dessus), cela ne prend que quelques secondes.

Answer 13

La taille de la base de données est importante en termes d'octets et de nombre de lignes de la table.Vous remarquerez une énorme différence de performances entre une base de données légère et une base de données remplie de blob.Une fois, mon application est restée bloquée parce que j'ai mis des images binaires dans des champs au lieu de conserver les images dans des fichiers sur le disque et de mettre uniquement les noms de fichiers dans la base de données.En revanche, itérer un grand nombre de lignes n’est pas gratuit.

Answer 14

Non, cela n'a pas vraiment d'importance.La vitesse de MySQL est d'environ 7 millions de lignes par seconde.Vous pouvez donc l'adapter un peu