Configurer SQL pour des performances optimales… SSD ou HDD?


8

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.


1
Je suis sûr qu'une copie de la norme SQL fonctionnera aussi bien sur les SSD que sur les disques durs à plateau tournant. Ou peut-être vous êtes intéressé par une tentative d'implémentation particulière de la norme SQL?
womble

Réponses:


14

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.


2
En termes d'usure en raison de cycles d'écriture limités, les bons disques SSD approchent de la sécurité des disques en rotation ces jours-ci en raison d'une combinaison d'une plus grande capacité de cycle d'écriture de cellules individuelles, de fusions de fusion d'écriture pour réduire les cycles de bloc d'écriture requis et du niveau d'usure algorithmes. Même pour des applications à charge élevée d'E / S comme une base de données très active, un bon SSD n'est pas beaucoup plus susceptible de se produire avant un remplacement de routine qu'un disque tournant. Gardez simplement des sauvegardes régulières et régulièrement testées comme avec n'importe quelle solution de stockage.
David Spillett

Je suis d'accord, c'est pourquoi j'appelle cela une préoccupation et non un arrêt de spectacle ... un disque bon marché a un vrai problème avec cela en ce moment, et c'est plus un problème de firmware. Dans les 6 mois, je ne pense plus que le niveau d'usure augmentera, ça progresse très bien, très rapidement.
Nick Craver

1
Bonne réponse. Pour ajouter à cela, je pense que dans la plupart des cas, le journal doit rester sur un disque dur normal car il est écrit séquentiellement et les disques durs sont bon marché. Ayez juste la base de données réelle sur un SSD car c'est là que se trouve l'accès aléatoire.
PeteT

@PeteT - cela varie / dépend un peu, rappelez-vous qu'un journal particulier est séquentiel oui, mais sur un serveur hébergeant de nombreuses bases de données (comme Stack Exchange hébergeant de nombreux sites dans une base de données par), le comportement réel est beaucoup plus proche de l'accès aléatoire / écrit que séquentielle, cela dépend donc de ce que vous exécutez.
Nick Craver

Une belle chose est que lorsqu'un SSD arrive en fin de vie et ne peut plus être écrit, il est toujours lisible. Vous ne pouvez pas dire cela à propos d'un disque en rotation qui se casse.
djangofan

4

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.



2

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.

Pièces d'avion? Ce n'est pas la meilleure analogie si vous l'étendez aux navettes NASAs, qui fonctionnent sur des ordinateurs IBM AP101S avec 1 Go de RAM et pas de disque dur. Le besoin de prévisibilité et de fiabilité étant au-dessus de toutes les autres considérations.
CJM

1

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.


Mes lectures ne ralentissent pas vraiment. Nous essayons d'optimiser une requête "premier coup" où cela prend environ 120-130 ms la première fois que la requête est exécutée et 80 ms après cela. Ces délais excluent la création des plans de requête et la lecture des statistiques pertinentes. Nous pouvons voir que la différence de temps dans notre cas est passée à lire à partir du disque, donc j'essaie d'explorer comment je peux rapprocher ce premier coup des 80 ms.
spoon16

Donc, même après la première manche, cela prend encore 80 ms? S'agit-il principalement de lectures de données ou de beaucoup de CPU (agrégation ou tri)? Pensez toujours qu'il y a beaucoup de place pour une optimisation "traditionnelle" avant de passer aux technologies de stockage exotiques.
BradC

Si vous devez vous rendre sur le disque lors de la première exécution de la requête, SQL expulse les données du cache pour une raison quelconque. Vous voudrez peut-être d'abord regarder quelle est l'espérance de vie de votre page. S'il est faible, alors plus de RAM est en ordre. Quel est votre taux d'accès au cache avant, pendant et après la requête? S'il est inférieur à 99,8%, l'indexation et davantage de RAM sont en règle. Faites-vous des analyses? Si tel est le cas, une indexation plus poussée peut être nécessaire.
mrdenny

Sur une charge de travail lourde en écriture avec une mise en cache (c'est-à-dire des données physiquement engagées sur le disque avant le retour de l'appel), vous devriez obtenir des performances d'écriture sensiblement meilleures à partir d'un SSD, en supposant que votre application est vraiment liée aux E / S. Notez qu'il s'agit de la stratégie de mise en cache préférée pour SQL Server, en particulier sur les SAN, et MS nécessite des SAN pour garantir ce comportement afin d'obtenir la certification pour une utilisation avec SQL Server.
ConcernedOfTunbridgeWells

1

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.


1

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.


1

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.


0

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...


0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.