Configurer SQL pour des performances optimales… SSD ou HDD?

Quelqu'un connaît-il des comparaisons qui montrent comment les SSD se comparent aux disques durs pour les performances dans un environnement SQL?

J'essaie de comprendre quel type d'avantage de performance pourrait être obtenu en passant au SSD.

Si vous effectuez un grand nombre de petites lectures, les SSD sont beaucoup plus rapides. Voici l'une des rares comparaisons qui flottent sur les performances de la base de données. Regardez le graphique du bas pour la réponse courte.

Pour les performances brutes, les SSD offrent de nombreux avantages, le principal étant que le temps de recherche est effectivement égal à 0, ce qui signifie que tous les petits hits HD d'une base de données sont traités beaucoup plus rapidement.

Il y a cependant quelques problèmes avec la génération actuelle sur la durée de vie en écriture, car après tant d'écritures, un bloc n'est plus utilisable. Ils peuvent écrire un peu, je pense que les informations de l'intelligence tournent autour d'un pétaoctet d'octets pour leurs disques de 32 Go avant de commencer à atteindre des niveaux dangereux d'articles ... cela ne fera que s'améliorer avec le temps.

Pour mieux comprendre pourquoi ils fonctionnent tellement mieux, lisez cet article d'Anandtech sur les SSD . Il explique en détail les disques, ce qui est bon, ce qui ne l'est pas, et les tenants et aboutissants de leur fonctionnement. En haut se trouve également un lien vers des articles de suivi qui couvrent la dernière série de disques.

Vous pouvez installer votre système d'exploitation et votre logiciel SQL sur un disque dur standard, puis ajouter un SSD pour simplement conserver vos fichiers de base de données. Cela devrait limiter le nombre d'écritures que subit le lecteur SSD et maximiser également la quantité d'espace disponible pour vos données sur le lecteur.

je vous recommande de lire le document suivant Migrer le stockage de serveur vers des disques SSD: Analyse des compromis , c'est une lecture assez agréable.

À mon avis, il n'y a pas encore assez d'avantages des SDD dans la zone des serveurs. Peut-être que dans quelques années, ils pourraient valoir la peine d'être achetés, le bot pour le moment est donc un meilleur choix.

La réponse de Nick Craver est bonne; Je veux juste ajouter deux mises en garde aux SSD dont je pense que les gens devraient être conscients:

a) Les problèmes de SSD avec l'usure en écriture ne disparaissent pas, ils sont fondamentaux pour les cellules flash utilisées. Les cellules SLC ont une endurance à l'écriture beaucoup plus élevée que MLC, donc l'OP devrait envisager d'obtenir un lecteur SLC sur MLC. Bien sûr, SLC est également beaucoup plus cher.

b) Les lecteurs actuels mettent en cache les données sur le lecteur avant de les écrire. Il y a donc un risque de perte de données si l'alimentation est coupée lors d'une opération d'écriture. C'est quelque chose que vous pouvez contourner, mais le cache est là à la fois pour les performances et pour réduire l'amplification d'écriture.

À mon humble avis, aucun des éléments ci-dessus n'est un facteur de rupture. Je serais prêt à déployer des SSD en production aujourd'hui, mais avec un peu de planification en premier.

1. Si un petit risque de perte de données est inacceptable, les disques durs SAS classiques avec la mise en cache des données désactivée peuvent être un meilleur choix.
2. Je pense que vous devriez mesurer la quantité de données écrites sur le disque SSD dans une journée normale. En fonction de cela et des spécifications d'usure du fabricant, calculez la durée de vie prévue du SSD avec votre modèle d'utilisation. Si la durée de vie attendue est inférieure à la durée de vie prévue des serveurs, définissez une date de remplacement préventive pour le SSD. Tout comme les pièces d'avion, échangez-le avant qu'il ne soit susceptible de tomber en panne.

Quelque chose à garder à l'esprit.

Si vous atteignez suffisamment la base de données pour ralentir vos lectures et que vous ayez besoin de disques SSD, vous devez corriger vos index ou envisager d'ajouter plus de RAM au serveur.

La plupart des serveurs de bases de données, une fois entièrement réglés, n'ont pas besoin de SSD pour fonctionner correctement.

Lisez cet article (assez ancien - 2009):

Résumé: remplacez les disques SAS 24 x 15 000 tr / min par 6 (oui six) SSD et obtenez encore 35% de performances supplémentaires. C'était avec les Intel X25M qui ne sont plus le top des SSD.

Pour les utilisateurs de bases de données, c'est fantastique car vous pouvez avoir des serveurs plus petits et plus rapides en utilisant moins d'énergie.

Une chose à considérer est d'avoir le journal de transatcion sur un disque dur et votre MDF sur un SSD. La durée de vie dépendra également grandement du type d'application. OLTP peut graver rapidement, alors que les données raisonnablement statiques ne devraient avoir aucun problème.

Ma propre expérience a été mélangée ici ...

Test sur Windows 7 avec SQL Server 2008 Express R2. Fonctionnant sur un bureau i7 avec un Sandy Bridge et un ram installé 12G (DDR3 je pense?). Excusez que la configuration soit de bureau, j'étais juste après avoir vu combien d'enregistrements je peux gérer sur la plate-forme i7 avant de créer un serveur.

J'ai d'abord exécuté ces tests sur le lecteur installé de 1,5 To à 7200 tr / min pour obtenir les horaires de base.

10 000 enregistrements avec mise à jour des procs, optimisé les tables pour stocker les données précédemment liées dans une table plate, ajouté des index jusqu'à ce que je descende à quelques secondes comme point de départ, puis j'ai dupliqué les enregistrements jusqu'à 1,2 million et obtenu un calendrier de 0: 3: 37 pour les mêmes mises à jour. 3 1/2 minutes n'est pas mauvais pour cette configuration non-raid.

Duper les records jusqu'à 2,56 millions m'a donné un timing de 0:15:57 - presque une augmentation de 5x. Probablement dû principalement à la pagination devant la mémoire 12G installée.

Installé le disque SSD et déplacé les bases de données, le timing est en fait passé à un peu plus de 20 minutes. Je suppose que c'est parce que les fichiers d'échange sont par disque dur et qu'il n'y en avait pas par défaut sur le lecteur SSD car il n'était pas installé comme lecteur OS (écrans bleus à gogo quand j'ai essayé).

Ajout d'un fichier d'échange au lecteur SSD et relancez le test, 0: 5: 52 -m donc le fichier d'échange semble avoir fait l'affaire, mais je ne suis pas sûr qu'un fichier d'échange convienne à un lecteur SSD pour toutes les raisons ci-dessus, ils sont fortement écrasés et peuvent ajouter une usure excessive sur le lecteur.

Une mise en garde, j'ai également activé Smartboost sur ce lecteur et qui peut également avoir influencé les timings, sera réexécuté sans lui.

Mon meilleur sentiment est qu'il est plus facile d'ajouter de la mémoire ces jours-ci, et pour le coût, un raid 0 + 1 de disques hybrides ferait presque aussi bien un travail sans les problèmes.

edit: désactivé le fichier de pagination sur le SSD et laissez Smart Boost faire son travail, le timing est passé de 5:52 min à 4:55 min pour 2,56 millions d'enregistrements avec une série de 3 mises à jour chacune. J'essaierai ensuite le cache SSD 8G sur le disque hybride Seagate 750G. alors si ce n'est pas mal je vais les essayer en raid 0 + 1.

dernière mise à jour à ce sujet car il s'agit d'un ancien fil de discussion - mais je voulais mettre les résultats que j'ai obtenus afin que quelqu'un puisse les trouver.

Déplacement de la base de données vers le Seagate 750G Hybrid avec un cache SSD 8G J'ai exécuté le test plusieurs fois afin que le cache SSD puisse apprendre. Cela me donne 5:15 m: s pour le même test, mettant à jour 2,56 millions d'enregistrements - c'est assez proche des performances SSD (4:55 m: s avec Intel Smartboost) pour que je puisse considérer le coût.

À environ 50 $ de plus (239 $ contre 189 $ en ce moment), l'hybride fournit plus de 6 fois le stockage et presque les mêmes performances, sans exécuter de logiciel supplémentaire pour l'optimisation. Dans un raid 0 + 1, je m'attends à ce que les horaires soient beaucoup améliorés et ce lecteur a une garantie de 5 ans, espérant que je n'en aurai pas besoin.

Personnellement, je n'utiliserais pas de SSD pour les raisons déjà mentionnées; ils ralentiront progressivement avant d'échouer finalement. Nous ne savons pas encore vraiment quand ce sera - les estimations actuelles ne sont que cela - des estimations. Rappelez-vous quand nous avons tous acheté ces CD «indestructibles» au début / milieu des années 80? Quelques années plus tard, nous considérions le stockage à terme de données sur CD autant de folie que l'utilisation de disquettes.

Si votre matériel, votre système d'exploitation et votre base de données sont tous configurés correctement, vous n'aurez pas besoin de jouer sur les SSD.

Dans quelques années, lorsque les produits auront un peu mûri, ce sera un scénario différent. Mais en attendant...

L'article de Microsoft Research se préoccupe du coût par Go plutôt que du gain de performances. Il ne s'adapte pas et ne teste pas réellement les lecteurs, mais utilise un algorithme de rétro-diffusion basé sur des fichiers journaux provenant de serveurs réels.

Certaines choses qui me viennent à l'esprit avec SSD et SQL:

1 / Si vous négligez d'ajouter les bons index, le SSD sera beaucoup plus indulgent car les temps de recherche aléatoires sont si bas.

2 / Les coûts sont bien en deçà du moment où cette étude a été effectuée et pour les petites applications Web, par exemple pour exécuter le back-end d'une application téléphonique, pas les serveurs Exchange d'entreprise, les performances pourraient réduire les dépenses liées à l'embauche d'un consultant pour régler SQL Server.

3 / Un seul disque SSD avec cliché instantané est sûrement devenu moins cher qu'un tas de broches dans une armoire RAID et le contrôleur et les connexions. Sans parler de la puissance et du chauffage et de l'espace rack.

4 / Les broches sont connues pour être la partie qui meurt le plus souvent sur un ordinateur. Le SSD n'a pas de pièces mobiles et une heure de panne peut coûter le prix d'un SSD en une seule fois.

5 / L'usure est un problème mais ils ont des moyens de le gérer (impliquant des blocs de diffusion) qui sont possibles car les données fragmentées de manière aléatoire ne ralentiront pas un SSD. De plus, une petite base de données sur un grand disque ne s'usera probablement pas à temps pour en acheter une nouvelle moins chère à l'avenir.

6 / Il y a une tendance vers des bases de données non relationnelles et des jointures au niveau intermédiaire. Cela pourrait vraiment changer les choses: les E / S vers de simples tables non indexées sur des disques SSD sur des fragments sans perte de performances et avec une proposition de mise à l'échelle beaucoup plus simple. Épargne également sur les licences SQL Server par partition.

7 / Tout cela est théorique. Si quelqu'un a des tests de performances dans le monde réel contre les broches, j'aimerais voir.

Luc