Quelle est la taille d'une base de données MySQL avant que les performances 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?
• 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 raison pour moi de nettoyer les données, ou suis-je sûr de lui permettre de continuer à évoluer pendant quelques années de plus?

La taille de la base de données physique 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 allez rencontrer n'est pas la taille, mais le nombre de requêtes que vous pouvez gérer à la fois. Il est fort probable que vous deviez passer à une configuration maître / esclave afin que les requêtes de lecture puissent s'exécuter sur les esclaves et les requêtes d'écriture sur le maître. Cependant, si vous n'êtes pas encore prêt pour cela, vous pouvez toujours modifier vos index pour les requêtes que vous exécutez pour accélérer les temps de réponse. Il y a aussi beaucoup de réglages que vous pouvez faire sur la pile réseau et le noyau sous Linux qui vous aideront.

J'ai eu le mien jusqu'à 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 j'examinerais l'administrateur de votre système d'exploitation, et si tout cela ne vous aide pas, il serait peut-être temps d'implémenter une configuration maître / esclave.

En général, c'est une question très subtile et pas du tout triviale. Je vous encourage à lire mysqlperformanceblog.com et High Performance MySQL . 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. La RAM est le facteur d'évolutivité le plus important. 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 importe, selon 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 physiques de base de données 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 à ces problèmes et comme dans beaucoup de cas, le diable est dans les détails.

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 bien sûr les performances: 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 définis correctement (par exemple, aucun index pour les champs des "instructions WHERE" ou des "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 - aident souvent à réduire les problèmes les plus graves en augmentant à nouveau les performances, au moins dans une certaine mesure. Par exemple37 signaux sont passés de 32 Go de RAM à 128 Go de RAM pour le serveur de base de données Basecamp.

Je me concentrerais d'abord sur vos index, que de voir un administrateur de serveur sur votre système d'exploitation, et si tout cela n'aide pas, il serait peut-être temps pour une configuration maître / esclave.

C'est vrai. Une autre chose qui fonctionne généralement est de simplement réduire la quantité de données qui ont été 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 les regardez pas;)

-> Jetez un œil au partitionnement .

2 Go et environ 15 millions d'enregistrements est une très petite base de données - j'en ai exécuté beaucoup plus gros sur un pentium III (!) Et tout s'est encore déroulé assez rapidement. Si le vôtre est lent, c'est un problème de conception de base de données / application, pas un mysql une.

Il est un peu inutile de parler de «performances de base de données», «performances de requête» 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 à analyser et des index à utiliser avec la syntaxe EXPLAIN.

2 Go ne comptent pas vraiment comme une "grande" base de données - c'est plutôt une taille moyenne.

Je gère actuellement une base de données MySQL sur l'infrastructure cloud d'Amazon qui est passée à 160 Go. Les performances des requêtes sont correctes. 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 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 l'automatisation, divers choix devaient être faits pour prioriser la stabilité sur les performances. Si jamais nous devions nous remettre d'une catastrophe à l'aide d'une sauvegarde SQL, nous serions en panne pendant des 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 en SQL en premier lieu. Shards, read slaves, multi-master, et al, ce sont tous des solutions vraiment merdiques qui ajoutent de la complexité à tout ce que vous faites avec la base de données, et aucun d'eux ne résout le problème; l'atténue seulement à certains égards. Je suggérerais fortement d'envisager de déplacer certaines de vos données hors de MySQL (ou vraiment n'importe quel SQL) lorsque vous commencez à approcher un ensemble de données d'une taille où ces types de choses deviennent un problème.

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

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

J'ai été une fois 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 cela fonctionnait comme un champion jusqu'à ce qu'il ne fonctionne pas du tout! Cette expérience me sert toujours de bon rappel qu'il y a toujours des dimensions au-dessus et en dessous de celle que vous soupçonnez naturellement.

Un point à considérer est également l'objectif du système et des données au jour le jour.

Par exemple, pour un système avec surveillance GPS des voitures, les données de requête des positions de la voiture des mois précédents ne sont pas pertinentes.

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

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 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 de 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.

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

Par exemple, j'ai travaillé avec un tableau de 100000 médicaments qui a un nom générique de colonne où il 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 tableaux. Même si vous comparez les médicaments en utilisant l'indice des médicaments, en utilisant une colonne d'identification (comme indiqué ci-dessus), cela ne prend que quelques secondes.

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

Non, ça 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

Les performances des requêtes dépendent principalement du nombre d'enregistrements à analyser, les index y jouent un rôle important et la taille des données d'index est proportionnelle au nombre de lignes et au nombre d'index.

Les requêtes avec des conditions de champ indexées avec la valeur complète seraient retournées en 1 ms en général, mais démarre_avec, IN, entre, contient évidemment des conditions qui pourraient prendre plus de temps avec plus d'enregistrements à analyser.

De plus, vous rencontrerez de nombreux problèmes de maintenance avec DDL, comme ALTER, DROP sera lent et difficile avec plus de trafic en direct, même pour ajouter un index ou de nouvelles colonnes.

En règle générale, il est conseillé de regrouper la base de données en autant de clusters que nécessaire (500 Go serait une référence générale, comme l'ont dit d'autres, cela dépend de nombreux facteurs et peut varier en fonction des cas d'utilisation) de cette façon, il offre une meilleure isolation et une indépendance à l'échelle spécifique clusters (plus adaptés en cas de B2B)