Grandes tables MySQL

Question

Pour une application web que je développe, j'ai besoin de stocker un grand nombre d'enregistrements. Chaque enregistrement consistera en une clé primaire et une seule valeur de chaîne (short-ish). Je m'attends à avoir environ 100 Go de stockage disponible et j'aimerais pouvoir tout utiliser.

Les enregistrements seront insérés, supprimés et lus fréquemment et je dois utiliser une base de données MySQL. L'intégrité des données n'est pas cruciale, mais les performances le sont. Quels problèmes et pièges suis-je susceptible de rencontrer et quel moteur de stockage serait le mieux adapté à la tâche?

Un grand merci, J

Answer 1

Quelle que soit la solution que vous utilisez, puisque vous dites que votre base de données sera trop lourde en écriture besoin de s'assurer que toute la table ne se verrouille pas sur les écritures. Cela exclut MyISAM, ce que certains ont suggéré. MyISAM verrouille la table sur une mise à jour, supprimer ou insérer. Cela signifie que tout client qui veut lire à partir de la table devra attendre que l'écriture se termine. Ne sais pas ce que fait INSERT LOW PRIORITY, probablement un peu de blocage de table :-)

Si vous devez simplement utiliser MySQL, vous aurez besoin d'InnoDB, qui ne se verrouille pas en écriture. Je ne sais pas comment MySQL gère les tables InnoDB de VACUUM (InnoDB est MVCC comme PostgreSQL et doit donc être nettoyé) ... mais vous devrez en tenir compte si vous faites beaucoup de mises à jour ou de suppressions.

Answer 2

Si vous utilisez l'indexation (et même si vous n'êtes pas) vous pouvez rencontrer des problèmes d'échelle. Vous pouvez essayer de partitionner pour essayer de réduire ces effets.

Dans mon propre projet, l'intégrité n'est pas cruciale mais les performances aussi. Ce que nous avons fait a été de relâcher toutes les exigences transactionnelles, d'assouplir les exigences de synchronisation des disques et de valider les insertions par lots, et nous avons vraiment amélioré nos vitesses d'écriture.

De même, assurez-vous de faire vos propres tests pour régler la taille de votre mémoire. Je crois que MySQL a quelques types de caches différents dont vous pouvez configurer la taille.

Answer 3

Vous voulez absolument utiliser MyISAM pour le moteur de stockage. Mais vous dites que vous attendez 100 Go et il ne contiendra qu'une valeur de chaîne courte. Vous voulez certainement utiliser un int 64 bits pour votre identité/clé primaire.

Mais ma vraie question est. L'utilisez-vous pour stocker des informations de session sur le site Web? Si c'est le cas, vous voulez utiliser memcache au lieu de MySQL.

Answer 4

grandes requêtes MySQL font mon accident Ram Quad Core/8 Go DB serveur ...

solution

est d'utiliser PostgresSQL (SQL Server si vous pouvez vous le permettre)

Answer 5

Tout dépend du modèle de lecture/écriture votre application génère et le niveau de précision que vous voulez obtenir. Par exemple, si vous ne vous souciez pas vraiment d'avoir toutes les dernières lignes insérées immédiatement disponibles, pensez à utiliser INSERT LOW PRIORITY pour aider les SELECTs. Si la taille du texte est relativement petite, vous pouvez utiliser un type CHAR fixe qui aidera à indexer beaucoup et réduire le temps de SELECTs Si votre application génère beaucoup de mises à jour, vous préférerez le moteur de stockage InnoDB qui permet de verrouiller un seul ligne lors de la mise à jour (vs toute la table sur myISAM). D'autre part, il est plus gourmand en ressources processeur, donc si vous n'utilisez pas de transactions et que votre motif de mise à jour est relativement petit, envisagez d'utiliser myISAM

Answer 6

Vous êtes beaucoup mieux si la "chaîne courte" est dans une colonne de longueur fixe de sorte que la table a des rangées de longueur fixe. MySQL avec MyISAM fonctionnera assez efficacement pour vous alors. Allouer autant de mémoire que vous pouvez pour le tampon de clé afin qu'une grande partie de l'index en mémoire.Votre objectif devrait être un seul accès aléatoire au disque pour récupérer une ligne - vous ne pouvez pas faire mieux que celui donné 100 Go de données et 8 Go de mémoire. Vous ne devriez pas vous attendre à atteindre plus de quelques centaines de requêtes de ce type par seconde, car ce sont tous les accès aléatoires qu'un disque peut faire.

Vous pourriez être intéressé par mon moteur de stockage MySQL personnalisé (décrit here). Il gère la mémoire différemment de MyISAM, bien que le profil de votre application ne soit pas exactement celui pour lequel mon moteur a été optimisé.