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

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

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

J'ai ce que je crois ê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 que je nettoie les données, ou suis-je sûr de lui permettre de continuer à évoluer pour quelques années de plus?

0

13 Réponses

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

Dans mon expérience, le plus gros problème que vous allez rencontrer n'est pas la taille, mais le nombre de requêtes que vous pouvez gérer à la fois. Très probablement, vous allez devoir passer à une configuration maître / esclave pour que les requêtes de lecture puissent s'exécuter contre les esclaves et que les requêtes d'écriture s'exécutent sur le maître. Toutefois, si vous n'êtes pas encore prêt pour cela, vous pouvez toujours modifier vos index pour les requêtes que vous exécutez afin d'accélérer les temps de réponse. De plus, il y a beaucoup de peaufinage que vous pouvez faire sur la pile réseau et le noyau sous Linux.

J'ai eu le mien obtenir jusqu'à 10GB, avec seulement un nombre modéré de connexions et il a traité les demandes très bien.

Je me concentrerais d'abord sur vos index, puis un administrateur de serveur regarderait votre système d'exploitation, et si tout cela ne vous aide pas, il pourrait être temps d'implémenter une configuration maître / esclave.

0
ajouté
Que faire si la taille de la base de données est supérieure à 7 Go. Dans ce fait, la limite de temps n'est pas affectée?
ajouté l'auteur Hacker, source

Surveillez également les jointures complexes. La complexité des transactions peut être un facteur important en plus du volume de transactions.

Le refactoring des requêtes lourdes offre parfois une grande amélioration des performances.

0
ajouté

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

2GB ne compte pas vraiment comme une "grande" base de données - c'est plus d'une taille moyenne.

0
ajouté

Je me concentrerais d'abord sur vos index, plutôt que d'avoir un administrateur de serveur qui regarde votre système d'exploitation, et si tout cela ne vous aide pas, il pourrait être temps pour une configuration maître / esclave.

C'est vrai. Une autre chose qui fonctionne habituellement est de simplement réduire la quantité de données qui a travaillé à plusieurs reprises avec. Si vous avez « anciennes données » et « nouvelles données » et 99% de vos requêtes travailler avec de nouvelles données, il suffit de déplacer toutes les anciennes données à une autre table - et ne regardez pas;)

-> Have a look at partitioning.

0
ajouté

En général, c'est une question très subtile et pas triviale que ce soit. Je vous encourage à lire mysqlperformanceblog.com et MySQL haute performance . Je pense vraiment qu'il n'y a pas de réponse générale à cela.

Je travaille sur un projet qui a 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 entrent 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 compte, selon l'apparence de vos tableaux. C'est une différence d'avoir beaucoup de champs de varchar ou seulement quelques ints 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 physiques db se développent, mais ne rétrécissent pas, par exemple avec innodb. Donc, supprimer beaucoup de lignes, n'aide pas à réduire vos fichiers physiques.

Il y a beaucoup de problèmes et, dans de nombreux cas, le diable est dans les détails.

0
ajouté

La taille de la base de données est importante . Si vous avez plus d'une table avec plus d'un million d'enregistrements, les performances commencent en effet à se dégrader. Le nombre d'enregistrements affecte évidemment la performance: MySQL peut être lent avec de grandes tables . Si vous atteignez un million d'enregistrements, vous obtiendrez 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 "ON conditions" dans les jointures). Si vous atteignez 10 millions d'enregistrements, vous commencerez à avoir des problèmes de performance, même si vous avez tous vos indices corrects. Les mises à niveau matérielles - en ajoutant plus de mémoire et plus de puissance de processeur, en particulier la mémoire - aident souvent à réduire les problèmes les plus graves en augmentant encore la performance, au moins jusqu'à un certain degré. 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.

0
ajouté

Un point à considérer est également le but du système et les données au jour le jour.

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

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

0
ajouté

Une fois, j'ai été appelé à regarder 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 était exactement de 2 Go sur le disque. Mais en ce qui concerne la courbe de performance, on me dit que ça fonctionnait comme un champion jusqu'à ce que ça ne marche pas du tout! Cette expérience me sert toujours de bon souvenir: il y a toujours des dimensions au-dessus et au-dessous de celle que vous soupçonnez naturellement.

0
ajouté
Même s'il est vrai que la question de la mise à l'échelle est mieux perçue de manière holistique, cela n'a aucun rapport avec la façon dont MySQL évolue lui-même.
ajouté l'auteur Lie Ryan, source

2 Go et environ 15M d'enregistrements est une très petite base de données - j'ai couru beaucoup plus gros sur un pentium III (!) Et tout fonctionne encore assez vite .. Si le vôtre est lent c'est un problème de base de données / application, pas un MySQL un.

0
ajouté

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 les moteurs appropriés (n'utilisez pas MyISAM où plusieurs DML sont attendus), utilisez le partitionnement, allouez la bonne mémoire en fonction de l'utilisation et bien sûr une bonne configuration du serveur, MySQL peut gérer les données même en téraoctets!

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

0
ajouté

It depends on your query and validation.

Par exemple, j'ai travaillé avec un tableau de 100 000 médicaments qui a un nom générique de colonne où il y a plus de 15 caractères pour chaque médicament dans ce tableau. J'ai mis une requête pour comparer le nom générique des médicaments entre deux tables. Plus de minutes à courir.Le même, si vous comparez les médicaments en utilisant l'index des médicaments, en utilisant une colonne id (comme indiqué ci-dessus), cela ne prend que quelques secondes.

0
ajouté

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

0
ajouté

Je gère actuellement une base de données MySQL sur l'infrastructure cloud d'Amazon qui a atteint 160 Go. La performance de la requête est correcte. Ce qui est devenu un cauchemar, ce sont les sauvegardes, les restaurations, l'ajout d'esclaves ou tout ce qui concerne l'ensemble de données, ou même le DDL sur les 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 devaient être faits pour prioriser la stabilité par rapport aux performances. Si jamais nous devions nous remettre d'une catastrophe en utilisant une sauvegarde SQL, nous serions en panne pendant des jours.

La mise à l'échelle horizontale de SQL est également très pénible et, dans la plupart des cas, conduit à l'utiliser d'une manière que vous n'entendiez probablement pas lorsque vous avez choisi de mettre vos données dans SQL en premier lieu. Des fragments, des esclaves lues, des multi-maîtres, etc., ce sont des solutions vraiment merdiques qui ajoutent de la complexité à tout ce que vous faites avec la BD, et aucun d'entre eux ne résout le problème; ne l'atténue que d'une certaine manière. Je vous suggérerais fortement de déplacer certaines de vos données hors de MySQL (ou de n'importe quel SQL) quand vous commencerez à approcher un ensemble de données d'une taille où ces types de choses deviennent un problème.

0
ajouté