SSD vs HDD pour les bases de données
J'essaie d'acheter un nouveau serveur pour exécuter MySQL Server. Ce nouveau serveur sera l'esclave de ma machine principale. Cependant, ce serveur sera dédié à signaler uniquement "Beaucoup de lectures et de requêtes complexes."
Maintenant, je cherche à investir dans des disques durs à semi-conducteurs, mais je me demandais si cela valait vraiment le prix. La différence entre un SSD et un disque dur SATA 7200 est d'environ 1500 $ et le SSD a moins d'espace disque. Si j'investis dans le SSD, la vitesse sera-t-elle perceptible?
Je peux en acheter 4 (500 Go SATA 7200) pour 1500 $ de moins que 2 (500 Go SSD)
Pouvez-vous m'aider à prendre la décision de voir si la mise à niveau vaut la peine ou non?
Une fois de plus, je voudrais mentionner que je n'utilise pas query_cache donc il y aura beaucoup de lectures sur disque.
Ce serveur aura 32 Go de RAM et exécutera Ubuntu 12.04
Oui, avec beaucoup de lectures et le signalement d'un SSD fera une énorme différence. À partir de 7200 tr/min, vous ne pouvez pas attendre plus de 100 IOPS tandis que le SSD le moins cher peut être au moins 5 fois plus rapide que cela. Avec un bon SSD, vous pouvez atteindre 20000 IOPS ou plus.
Les écritures aléatoires sur SSD sont également beaucoup plus rapides car le disque n'a pas à se déplacer à chaque fois.
Il y a trois facteurs que vous devez considérer ici:
- La taille de votre base de données
- La quantité de mémoire dont vous disposez sur le serveur
- Votre configuration my.cnf, en particulier
innodb_buffer_pool_size
Si mémoire disponible> taille de la base de données , votre serveur sera probablement en mesure de conserver toutes vos données en mémoire, et donc un SSD pourrait être une perte d'argent . Le tampon InnoDB n'a rien à voir avec le query_cache options.
Si mémoire disponible <taille de la base de données , il est possible que les requêtes aient besoin de récupérer les données du disque. Pour les requêtes extrêmement complexes, ou si de nombreux utilisateurs exécutent des requêtes en même temps, cela peut commencer à exercer une pression sur le disque.
En général, les bases de données conservent les données les plus utilisées en mémoire - si 80% de vos données sont rarement/jamais utilisées, vous n'aurez qu'à conserver 20% de votre base de données en mémoire pour maintenir les performances.
La quantité exacte de mémoire dont vous avez besoin ne sera pas immédiatement évidente, mais à moins que votre base de données ne dépasse 200 Go, je recommanderais vivement de suivre les conseils d'Up_One et de dépenser de l'argent supplémentaire en mémoire au lieu des SSD.
NB: Si votre base de données utilise MyISAM (vous pouvez le vérifier avec show table status;), envisagez de passer à InnoDB. Le MyISAM key_buffer_cache ne stocke que des blocs d'index, alors que le pool de tampons InnoDB stocke des blocs de données entiers. Dans la plupart des cas, InnoDB s'avérera être un meilleur moteur avec lequel travailler.
Je ne pense pas que ce soit une si bonne idée!
Mes conseils
augmenter la taille de votre pool de mémoire tampon InnoDB est le meilleur moyen d'accélérer MySQL. Si vous pouvez ajouter plus de RAM, faites-le. Cela mettra la plupart de vos données chaudes en mémoire, alors imaginez! Disque vs mémoire!
Le scénario parfait est d'avoir votre mémoire de la taille de votre base de données
SSD - c'est bien mais ça va coûter cher! et c'est seulement bon pour les travaux intensifs en lecture.
Consultez ce lien pour bel article à ce sujet de Vadim Tkachenko
Pour donner une alternative: vous pouvez utiliser les deux, un grand disque dur (idéalement, RAID1 avec trois disques) pour conserver les données, et un SSD plus petit pour conserver les index.
Raisonnement:
- les index sont assez petits, vous pouvez donc utiliser un SSD plus petit
- les requêtes courantes devraient de toute façon toucher les index
- le RAID1 vous offre une tolérance aux pannes
- le RAID1 vous offre un équilibrage de charge pour les lectures aléatoires
- trois disques laisse la tolérance aux pannes si un disque tombe en panne
- les index peuvent être reconstruits en cas de défaillance du SSD
Fais le.
Vous avez mentionné que votre charge de travail était importante en lecture, vous avez donc déjà évité le gros problème lié à l'utilisation de disques SSD dans les bases de données: l'usure. Aucune écriture ne signifie aucune usure, vous êtes donc doré.
Comme edvinas.me l'a mentionné, votre IOPS est beaucoup plus rapide avec le SSD qu'avec les disques en rotation. Pour une base de données, IOPS se traduit à peu près en requêtes par seconde. En ignorant RAM cache, vous servirez environ 100 fois plus de requêtes depuis un SSD que depuis un disque à 7200 tr/min.
TRIM ne fera pas beaucoup de différence car c'est une charge de travail lourde en lecture et il semble que vous envisagiez de remplir le disque de toute façon. Ne vous en faites pas.
Je ne sais pas d'où vient la chose de 1 500 $. En vérifiant mon fournisseur local (australien), je peux obtenir un SSD de 960 Go de marque réputée pour 750 $ ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5- 7mm-with-9-5mm-adapter-ssd-read-500mb-s-write-400mb-s / ). Les disques en rotation sont plus ou moins gratuits, mais 750 $ sont encore beaucoup plus agréables que 1500 $.
(Oh, attendez - vous commandez probablement auprès d'un grand fournisseur, alors ils vous font payer par le nez pour le SSD? J'achète toujours le SSD séparément et je l'échange en moi-même, mais je ne sais pas si c'est autorisé dans votre environnement.)
Vous vous en sortirez probablement aussi avec moins de RAM, mais sans connaître votre charge de travail exacte, il est difficile de juger si vous pouvez réduire en toute sécurité RAM sans nuire aux performances.
Si vous n'êtes toujours pas sûr, vous pouvez obtenir de gros disques de 10 000 tr/min, mais ils finiront par coûter presque autant que le SSD de toute façon tout en étant beaucoup plus lent.
Si vous devez évoluer bien au-delà de 1 To, les SSD commencent à devenir trop chers, mais à 1 To, je dirais que le SSD est une victoire évidente.
Je suis tout à fait d'accord pour dire que le plus gros coup pour l'argent provient de l'augmentation de la taille de votre innodb_db_bufferpool mais malheureusement cela dépend complètement de la taille de votre ensemble de données et de la fréquence d'accès à différents blocs de disque. Je gère plusieurs bases de données assez volumineuses de 200 Go +, donc tout intégrer dans le RAM n'est pas vraiment une option et pour cette raison, nous sommes récemment passés au stockage sur SSD. J'ai fait une recherche assez importante en termes d'utilisation des IOPS pour MySQL sur différentes baies RAID auxquelles j'ai accès. Voici les résultats:
1253 IOPS - 4 disques SCSI 15k (3,5 ")
test: (g = 0): rw = randrw, bs = 4K-4K/4K-4K/4K-4K, ioengine = libaio, iodepth = 64 lu: io = 3071.7MB, bw = 5012.8KB/s, iops = 1253 , runt = 627475msec écriture: io = 1024,4MB, bw = 1671,7KB/s, iops = 417, runt = 627475msec cpu: usr = 0,63%, sys = 3,11%, ctx = 985926, majf = 0, minf = 22
2 558 IOPS - 8 disques 10 000 tr/min 900 Go SAS (2,5 ")
test: (g = 0): rw = randrw, bs = 4K-4K/4K-4K/4K-4K, ioengine = libaio, iodepth = 64 lu: io = 3071.7MB, bw = 10236KB/s, iops = 2558, runt = 307293msec écriture: io = 1024,4MB, bw = 3413,5KB/s, iops = 853, runt = 307293msec cpu: usr = 2,73%, sys = 8,72%, ctx = 904875, majf = 0, minf = 25
23 456 IOPS - Serveur SSD Rackspace Performance 2
test: (g = 0): rw = randrw, bs = 4K-4K/4K-4K/4K-4K, ioengine = libaio, iodepth = 64 lu: io = 3071.7MB, bw = 93708KB/s, iops = 23426, runt = 33566msec écriture: io = 1024.4MB, bw = 31249KB/s, iops = 7812, runt = 33566msec cpu: usr = 5.73%, sys = 35.83%, ctx = 181568, majf = 0, minf = 23
35 484 IOPS - 2 x Mirrored Edge Boost 480 Go 2,5 "MLC ( http://www.edgememory.com )
test: (g = 0): rw = randrw, bs = 4K-4K/4K-4K/4K-4K, ioengine = libaio, iodepth = 64 lu: io = 3068.4MB, bw = 141934KB/s, iops = 35483, runt = 22137msec écriture: io = 1027,7MB, bw = 47537KB/s, iops = 11884, runt = 22137msec cpu: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20
Il est donc clair que les SSD de haute qualité d'aujourd'hui sont des artistes incroyables. Deux disques SSD en miroir peuvent facilement surpasser 16 disques SAN et c'est une déclaration convaincante à elle seule.
Si vous êtes intéressé par tous les détails, le reste de l'écriture se trouve sur mon blog:
http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html