SSD vs HDD pour bases de données

J'essaie d'acheter un nouveau serveur sur lequel exécuter MySQL. Ce nouveau serveur sera un esclave de ma machine principale. Toutefois, ce serveur sera dédié à la génération de rapports uniquement "Beaucoup de lectures et de requêtes complexes".

Maintenant, je cherche à investir dans des disques durs à l'état solide, mais je me demandais si cela en valait vraiment la peine. La différence entre un disque SSD et un disque dur SATA 7200 est d'environ 1 500 USD et le disque SSD dispose de moins d'espace disque. Si j'investis dans le SSD, la vitesse sera-t-elle perceptible?

Je peux acheter 4 (500 Go de SATA 7200) pour 1 500 dollars de moins que d'acheter 2 (SSD de 500 Go)

Pouvez-vous s'il vous plaît m'aider à prendre la décision de voir si cela vaut la mise à niveau ou non?

Une fois de plus, j'aimerais mentionner que je n'utilise pas, query_cacheil y aura donc beaucoup de lectures sur disque.

Ce serveur aura 32 Go de RAM et exécutera Ubuntu 12.04.

Oui, avec beaucoup de lectures et signaler un SSD fera une énorme différence. À partir de 7 200 tr / min, vous ne pouvez vous attendre à plus de ~ 100 IOPS, tandis que les SSD les moins chers peuvent être au minimum 5 fois plus rapides. Avec un bon SSD, vous pouvez atteindre 20000 IOPS ou même plus.

Les écritures aléatoires sur SSD sont également beaucoup plus rapides car le disque ne doit pas nécessairement se déplacer à chaque fois.

Il y a trois facteurs à prendre en compte ici:

1. La taille de votre base de données
2. La quantité de mémoire que vous avez sur le serveur
3. Votre configuration my.cnf, en particulier innodb_buffer_pool_size

Si la mémoire disponible est suffisante pour la taille de la base de données , votre serveur sera probablement en mesure de conserver toutes vos données en mémoire. Par conséquent, un disque SSD peut être un gaspillage d'argent. Le tampon InnoDB n'a rien à voir avec les query_cacheoptions.

Si la mémoire disponible <taille de la base de données , il est possible que les requêtes doivent extraire des données du disque. Pour les requêtes extrêmement complexes, ou si plusieurs utilisateurs les exécutent en même temps, cela peut commencer à stresser le disque.

En général, les bases de données gardent en mémoire les données les plus utilisées. Si 80% de vos données sont rarement / jamais utilisées, il vous suffira de garder 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 évidente immédiatement, mais à moins que votre base de données ne soit supérieure à 200 Go, je vous recommande vivement de suivre les conseils de Up_One et de dépenser de l'argent supplémentaire en mémoire plutôt qu'en disques SSD.

NB: Si votre base de données utilise MyISAM (vous pouvez le vérifier avec show table status;), envisagez de passer à InnoDB. MyISAM key_buffer_cachene stocke que des blocs d'index, tandis que le pool de mémoire tampon InnoDB stocke des blocs de données entiers. Dans la plupart des cas, InnoDB s’avérera un meilleur moteur.

Je ne pense pas que ce soit une si bonne idée!
Mon conseil:
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 consiste à avoir la mémoire de la taille de votre base de données
SSD - c'est génial, mais cela coûtera cher! et ce n'est bon que pour les travaux de lecture intensive.

Vérifiez ce lien pour un bel article de Vadim Tkachenko à ce sujet

Comme alternative, vous pouvez utiliser les deux, un disque dur de grande taille (idéalement, RAID1 avec trois disques) pour conserver les données et un disque 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 quand même atteindre les index
• le RAID1 vous donne la tolérance de panne
• le RAID1 vous donne l'équilibrage de charge pour les lectures aléatoires
• trois disques laisse la tolérance aux pannes en cas de défaillance d'un disque
• les index peuvent être reconstruits si le SSD échoue

Fais le.

Vous avez indiqué que votre charge de travail était lourde en lecture. Vous avez donc déjà évité le gros problème lié à l'utilisation de disques SSD sur des bases de données: l'usure. Pas d'écriture signifie pas d'usure, alors vous êtes en or.

Comme mentionné dans edvinas.me, votre IOPS est beaucoup plus rapide avec le SSD qu'avec les disques en rotation. Pour une base de données, IOPS se traduit pratiquement par des requêtes à la seconde. En ignorant le cache RAM, vous allez traiter environ 100 fois plus de demandes d'un disque SSD que d'un disque à 7 200 tr / min.

TRIM ne fera pas beaucoup de différence car il s’agit d’une charge de travail très chargée en lecture et il semblerait que vous envisagiez de remplir le disque de toute façon. Ne stresse pas à ce sujet.

Je ne sais pas d'où vient le montant de 1500 $. En vérifiant auprès de mon fournisseur australien, je peux obtenir un disque SSD de 960 Go de bonne réputation pour 750 USD ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adaptateur-ssd-read-500mb-s-write-400mb-s / ). Les disques en rotation sont plus ou moins gratuits, mais 750 $ sont toujours beaucoup plus acceptables que 1500 $.

(Oh, attendez - vous commandez probablement chez un fournisseur renommé, alors ils vous facturent par le nez pour le SSD? J'achète toujours le SSD séparément et je l'échange moi-même, mais je ne sais pas si c'est permis dans votre environnement.)

Vous obtiendrez probablement moins de RAM, mais sans connaître votre charge de travail exacte, il est difficile de savoir si vous pouvez réduire la RAM en toute sécurité sans nuire aux performances.

Si vous n'êtes toujours pas sûr, vous pouvez obtenir de gros disques durs à 10 000 tr / min, mais ils finiront par coûter presque autant que le SSD tout en étant beaucoup plus lents.

Si vous devez évoluer beaucoup au-delà de 1 To, les disques 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 meilleur retour sur investissement provient de l’augmentation de votre taille 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 aux différents blocs de disque. Je gère plusieurs bases de données assez volumineuses de plus de 200 Go, si bien que tout ranger dans la RAM n’est pas vraiment une option; c’est pour cette raison que nous avons récemment opté pour le stockage basé sur SSD. J'ai effectué de nombreuses recherches sur l'utilisation d'IOPS pour MySQL sur différentes baies RAID auxquelles j'ai accès. Voici les résultats:

1 253 IOPS - 4 x disques SCSI 15k (3.5 ")

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lire: io = 3071,7Mo, pc = 5012.8Ko / s, iops = 1253 , runt = 627475msec écriture: io = 1024.4Mo, pc = 1671.7Ko / s, iops = 417, runt = 627475msec unité centrale de traitement: usr = 0.63%, sys = 3.11%, ctx = 985926, majf = 0, minf = 22

2 558 IOPS - Disque SAS (2,5 ") 8 Go / min 10 000 tr / min

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lire: io = 3071,7Mo, pc = 10236KB / s, iops = 2558, runt = 307293msec écriture: io = 1024.4Mo, pc = 3413.5Ko / s, iops = 853, runt = 307293msec unité centrale de traitement: 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 lire: io = 3071,7MB, bw = 93708KB / s, iops = 23426, runt = 33566msec écriture: io = 1024.4Mo, pc = 31249Ko / s, iops = 7812, runt = 33566msec unité centrale de traitement: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35 484 IOPS - 2 x disques en miroir EDGE Boost 480 Go 2.5 "en miroir ( http://www.edgememory.com )

test: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 lire: io = 3068,4Mo, pw = 141934KB / s, iops = 35483, runt = 22137msec écriture: io = 1027,7 Mo, pc = 47537Ko / s, iops = 11884, runt = 22137msec unité de traitement: 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 d’excellents résultats. Deux disques SSD en miroir peuvent facilement surperformer le boîtier de stockage SAN à 16 disques, ce qui est une déclaration convaincante.

Si vous êtes intéressé par tous les détails, le reste de la rédaction se trouve sur mon blog:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html