Single Drive vs plusieurs unités

Question

En général goulot d'étranglement SGBDR (Je suis un utilisateur de MySQL) la performance est l'accès au disque. SSD offre d'excellentes performances par rapport aux entraînements de broche conventionnels.

Question: Est-il possible d'améliorer les performances en attachant plusieurs disques d'espace réduit, car de cette façon plus de têtes seront disponibles pour lire les données

?

Comme le remplacement de disque 2To 7.2K RPM avec 4 disques 500Go 7.2K RPM?

Answer 1

Cela pourrait dépendre beaucoup sur le moteur de stockage.

Pour MyISAM, je pense que ce serait une bonne idée parce que vous pouvez faire des données comme contigus comme vous voulez. Cela profiterait des requêtes impliquant des opérations en vrac et de grandes analyses de gamme. Le jeu d'outils pour la compression et la réparation MyISAM pour améliorer le format de table peut également accéder à un peu mieux. INSERTs simultanées IMHO pourraient se développer dans un environnement de disque.

InnoDB est une histoire complètement différente.

Si vous avez innodb_file_per_table personnes handicapées , les données peuvent être dispersées dans ibdata1 et donc dispersés parmi les multiples disques. Vous pouvez exécuter OPTIMIZE TABLE sur une table InnoDB et rendre les pages de données et d'index contigus, mais cela pourrait causer deux problèmes:

1. Permet de GROW ibdata1
2. performances au fil du temps Détériorer

Ne pas oublier les quatre types de données qui se trouvent dans ibdata1:

• Tableau MetaData
• Tableau de données Pages
• Index pages de données
• MVCC données

Il est écrit constante de MVCC données pour protéger l'intégrité des données. Il y a aussi une interaction constante avec ib_logfile0 et ib_logfile1 (redo logs). Il y a des données constantes de rinçage toutes les 10 secondes de l'arrière InnoDB tampon Piscine à la. Dans l'ensemble, il est sûr de dire que la diffusion des données sur plusieurs disques et les performances d'E / S peut montrer une amélioration de la performance marginale à modeste jusqu'à ce qu'il y est assez fragmentation au sein ibdata1.

Maintenant, si innodb_file_per_table est activé, les choses pourraient être un peu messier. Voici pourquoi:

Une fois que vous le nettoyage ibdata1 et séparer toutes les tables InnoDB de ibdata1 , vous aurez un ibdata1 plus petit. Cependant, chaque accès à une table InnoDB nécessite naviguer son utilisation par ibdata1 tout le temps via le tableau des métadonnées. Vous ne pouvez pas séparer littéralement sémantiquement les métadonnées de table (ibdata1) de la table (.ibd). Partout où vit ibdata1, E / S disque doit toujours passer par ibdata1.

Effet global: Tableau fragmentation se limite aux fichiers .ibd et peut être réduite et réorganisée avec OPTIMIZE TABLE, mais aucune amélioration de la performance E / S est vraiment atteint

.

Qu'en est-il de mettre tous les fichiers .ibd dans un jeu de disques en dehors de différents ibdata1 et utilisant des liens symboliques? Selon à Percona, qui crée plus Mayhem .

Conclusion

En ce qui concerne l'utilisation de plusieurs disques sur un seul disque, je suis en faveur très MyISAM sur InnoDB.

Answer 2

Oui, plusieurs lecteurs fournira un meilleur débit grâce à la technologie merveilleuse que nous appelons RAID. Pour une base de données, vous voulez RAID 10 (miroirs segmentés).

Avec 4 (N) lecteurs vous double (N / 2) votre vitesse d'écriture et quadruple (N) de lecture séquentielle débit. Les temps de recherche restent à peu près la même que, et vous perdrez la moitié de l'espace pour la mise en miroir.