Quelle est la taille de la table MySQL?

Question

J'ai finalement été convaincu de mettre mes petites tables en une seule, mais quelle est la taille de la table MySQL?

J'ai une table avec 18 champs. Certains sont TEXT, certains sont courts VARCHAR(16), d'autres plus longs VARCHAR(100).

À l'heure actuelle, nous obtenons environ 200 000 lignes par jour, soit 6 millions + par mois. Quelle taille est trop grande? Est-ce que le nombre de champs que vous avez, ou seulement les rangs, est-il important?

Answer 1

Il n'y a pas une grande solution générale à la question « Quelle est la taille est trop grand » - ces préoccupations dépendent souvent de ce que vous faites avec vos données et ce vos considérations de performance sont.

Il existe des limites fondamentales sur les tailles de table. Vous ne pouvez pas avoir plus de 1000 colonnes. Vos enregistrements ne peuvent pas être plus grands que 8k chacun. Ces limites changent en fonction du moteur de base de données. (Ceux-ci sont pour InnoDB.)

Il semble que vous ayez fusionné plusieurs ensembles de données différents dans une table. Vous avez probablement des champs qui vous indiquent l'ensemble de données auquel appartient cet enregistrement, ainsi que certains champs de données et certaines informations d'horodatage. Ce n'est pas un enregistrement très large (sauf si vous consignez, disons, tous les paramètres d'entrée de chaque demande.) Votre problème principal sera avec sélectivité. L'indexation de cette table de manière significative sera un défi. Si vos champs communs peuvent être suffisamment sélectifs pour que vous puissiez les utiliser pour accéder aux disques que vous voulez sans consulter la table, ce sera un énorme plus. (Cf. scan de table)

Pour autant d'enregistrements par jour (en gros, deux par seconde toute la journée, et je présume que vous avez une période de pointe où c'est beaucoup plus élevé), vous voudrez aussi faire Assurez-vous que vous regardez spécifiquement les optimisations sur améliorant la vitesse d'insertion. En règle générale, plus d'index = insertions plus lentes. Si vous le pouvez, envisagez d'archiver entièrement les enregistrements périmés vers une autre table. Dans les lieux de travail précédents, nous avons utilisé une stratégie d'archivage du mois dernier, trois mois avant, six mois avant, chacun dans des tableaux distincts. Une autre idée consiste à supprimer les anciens enregistrements. De nombreux environnements n'ont tout simplement pas besoin d'informations au-delà d'une certaine date. Accrochez-vous aux registres d'enregistrement d'il y a trois mois est souvent trop cher.

Enfin, ne négligez pas le stockage physique de votre table. Plus vos enregistrements sont minces, moins les E/S physiques ont besoin de lire (ou d'insérer) un enregistrement. Vous pouvez stocker vos index sur un disque dur physique distinct. S'il y a beaucoup de données redondantes dans vos enregistrements, stocker la table compressée peut en fait être une augmentation de la vitesse. Si vous avez un peu d'argent à dépenser, considérez la valeur d'une bonne matrice RAID pour le striping de vos données. Donc, pour répondre à votre question de base: il y a beaucoup d'enregistrements, mais avec un oeil attentif sur l'accord, ce ne sera pas un problème.

Answer 2

Je pense que cela dépend essentiellement. Quelle version de MySQL utilisez-vous, quel système d'exploitation utilisez-vous et utilisez-vous des tables MyISAM ou innoDB? C'est aussi different on 32-bit and 64-bit, et varie selon vos paramètres de journalisation. Le MySQL manual dit:

La taille maximale de la table efficace pour les bases de données MySQL est généralement déterminée par les contraintes du système d'exploitation sur la taille des fichiers, et non par MySQL internes limites

Il y a plus de détails sur ce que ces limites sont sur cette page aussi.

Answer 3

Le choix du nombre de colonnes à placer dans une table dépend également du type de données représentées et de la taille de la normalisation. Certaines relations peuvent facilement être représentées par une table; D'autres doivent être effectuées dans plusieurs tables plus petites, en particulier lorsque vous avez un mélange de relations de type un-à-un, un-à-plusieurs et plusieurs-à-plusieurs dans votre ensemble de données.

http://en.wikipedia.org/wiki/Database_normalization

Answer 4

Pas une réponse à la question exacte ...

Pourquoi avez-vous été convaincu de mettre vos petites tables en une seule grande? Ce que vous faisiez s'appelle «partitionnement vertical» et peut être très utile, selon votre situation. Avec beaucoup de grands champs TEXT ou BLOB, une partition verticale peut garder vos données plus demandées physiquement ensemble et plus rapidement à l'accès.

Voir: http://en.wikipedia.org/wiki/Partition_(database) Le partitionnement vertical

consiste à créer des tables avec moins de colonnes et en utilisant des tables supplémentaires pour stocker les colonnes restantes. La normalisation implique également cette division des colonnes entre les tables, mais le partitionnement vertical va au-delà de ces colonnes et des partitions, même lorsqu'elles sont déjà normalisées. Un stockage physique différent peut également être utilisé pour réaliser un partitionnement vertical; stocker des colonnes peu utilisées ou très larges sur un périphérique différent, par exemple, est une méthode de partitionnement vertical. Fait explicitement ou implicitement, ce type de partitionnement est appelé "division de ligne" (la ligne est divisée par ses colonnes). Une forme courante de partitionnement vertical consiste à fractionner (lentes à trouver) des données dynamiques à partir de données statiques (à trouver rapidement) dans une table où les données dynamiques ne sont pas utilisées aussi souvent que les données statiques. La création d'une vue sur les deux tables nouvellement créées restaure la table d'origine avec une pénalité de performance, mais les performances augmenteront lors de l'accès aux données statiques, par ex. pour l'analyse statistique

Voir aussi: http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

Answer 5

Considérez ce que vous devez faire avec la table. Si la table est purement pour l'achiving, vous n'auriez jamais besoin de changer sa structure ou quoi que ce soit. Si vous en avez besoin pour la datamining, vous vous attendez à changer sa structure. Essayez par exemple de faire une table alter sur une copie maintenant. Attendez-vous à ce que cette fonction baisse dans les performances une fois que vous atteignez un niveau où les tables temporaires deviennent trop volumineuses pour être stockées en mémoire.

J'ai été dans la même situation, où la quantité de données m'a rendu incapable de modifier la structure de la base de données. Ce que vous devez faire DONNER MAINTENANT consiste à demander à quelqu'un de créer une base de données sur une machine (c'est-à-dire une instance EC2) avec la quantité de données que vous prévoyez avoir dans deux ans. Il suffit de les faire créer des données bidon dans le même format de tableau. Essayez de travailler avec cette table et décidez si la performance est acceptable. Si ce n'est pas acceptable, vous devez changer les choses dès que possible.

Si j'étais vous, je envisagerais de tester Greenplum ou (GridSQL si vous n'avez pas l'argent pour dépenser). Les deux sont basés sur PostgreSQL et utilisent de nombreux ordinateurs pour fonctionner ensemble.

Answer 6

J'ai une table avec ~ 98M lignes et inserts/suppresses se produisent toute la journée. Nous gardons les enregistrements pendant 90 jours ... Je m'attends à ce que ce tableau soit à ~ 100M lignes ce mois-ci. Personnellement, j'aurais conçu le schéma de base de données différemment, mais il a été acheté et nous devons le garder intact pour ne pas annuler le support du fournisseur.

Nous utilisons la réplication mysql (MASTER-MASTER) et effectuons les insertions/suppressions sur un & effectuant les requêtes sur l'autre. Cela a vraiment aidé avec les performances car les suppressions verrouilleraient la table et bloqueraient les requêtes avant que nous passions à l'utilisation de la réplication.

Nous ne rencontrons aucun problème de performance en utilisant cette implémentation.

je joue également un optimize de table une fois par semaine ...