Pour améliorer les performances SQL, pourquoi ne pas simplement mettre beaucoup de RAM plutôt que d'avoir des disques durs plus rapides?

Les gens continuent de me dire que pour améliorer les performances d'un serveur SQL, achetez les disques durs les plus rapides possibles avec RAID 5, etc.

Je pensais donc, au lieu de dépenser tout l'argent pour RAID 5 et les disques durs rapides super-duper (ce qui n'est pas bon marché d'ailleurs), pourquoi ne pas simplement obtenir des tonnes de RAM? Nous savons qu'un serveur SQL charge la base de données en mémoire. La mémoire est beaucoup plus rapide que n'importe quel disque dur.

Pourquoi ne pas bourrer comme 100 Go de RAM sur un serveur? Ensuite, utilisez simplement un disque dur SCSI ordinaire avec RAID 1. Ne serait-ce pas beaucoup moins cher et plus rapide?

Votre analyse est bonne - jusqu'à un certain point - en ce sens qu'elle accélérera absolument les choses. Vous devez toujours tenir compte de quelques autres problèmes:

1. Tout le monde ne peut pas se permettre assez de mémoire; lorsque vous avez plusieurs téraoctets de données, vous devez les mettre sur le disque un certain temps. Si vous n'avez pas beaucoup de données, tout est assez rapide.

2. Les performances d'écriture de votre base de données seront toujours limitées par les disques, afin que vous puissiez tenir la promesse que les données ont bien été stockées.

Si vous avez un petit ensemble de données ou si vous n'avez pas besoin de le conserver sur le disque, il n'y a rien de mal à votre idée. Des outils tels que VoltDB s'efforcent de réduire les frais généraux que les hypothèses plus anciennes dans les implémentations RDBMS ont fait, ce qui limite les performances en mémoire pure.

(En passant, les gens qui vous disent d'utiliser RAID-5 pour les performances de la base de données ne sont probablement pas des gens formidables à écouter sur le sujet, car ce n'est presque jamais le meilleur choix - il a de bonnes performances de lecture, mais de mauvaises performances d'écriture et écrit sont presque toujours la contrainte de production - car vous pouvez ajouter de la RAM à la mise en cache pour résoudre la plupart des problèmes de performances en lecture.)

Version courte: considérez la taille de l'ensemble de travail. Version longue: Quelle est la taille de vos données? S'il peut tenir dans la mémoire d'un serveur moderne, oui, vous avez absolument raison. Malheureusement, le plus grand Xeon peut gérer 2 To de RAM en ce moment, et ce n'est plus un gros ensemble de données. Si vous ne pouvez pas acheter une machine assez grande pour héberger votre ensemble de travail en RAM, vous êtes obligé de résoudre des problèmes avec votre cerveau, pas avec votre portefeuille.

Si vous voulez de la vitesse:

• Augmentez la RAM pour que les index au moins fréquemment utilisés puissent entièrement s'intégrer dans la RAM (par exemple, sur un système sur lequel je travaille, 32 Go de RAM suffisent pour une base de données de 350 Go, car les index sont ce dont vous avez besoin en RAM, pas les données brutes)
• Utilisez RAID10 avec tous les disques (les disques plus rapides sont meilleurs)
• Évitez RAID5
• Fractionner mdf, ldf et temp DB sur des ensembles de broches discrets (exemple: tempdb sur son propre ensemble RAID1, ldf sur son propre ensemble de broches RAID1 ou RAID10, mdf sur un ensemble RAID 10 avec au moins 4 disques au total)

Suivez ces étapes et SQL Server volera.

Ensuite, si vous le souhaitez, ajoutez plus de RAM ... mais faites d'abord ce qui précède, et vous pourriez bien trouver que vous avez terminé.

La RAM est le nouveau disque, le disque est la nouvelle bande.

Dans http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Notez que c'était il y a six ans. Oui, nous avons des systèmes de base de données qui essaient (et essaient fort) de conserver l'ensemble de données en RAM et plutôt de les partager sur plusieurs machines plutôt que d'utiliser le disque car le disque est de toute façon plus lent. Vous devez écrire l'ensemble de données sur le disque, mais comme dans la devise ci-dessus, cela s'apparente plus à une tâche de sauvegarde en arrière-plan qu'à une opération en ligne. La durabilité est obtenue en ajoutant uniquement des journaux à ces bases de données (je pense à MongoDB et Redis mais il y en a des tonnes de plus).

Cette question est similaire à une question de base qui a conduit à de nombreuses recherches et développements dans les architectures de bases de données au cours des 5 à 10 dernières années. Maintenant qu'il est possible de stocker une base de données entière dans la RAM pour de nombreux cas d'utilisation, la base de données doit être conçue pour fonctionner en RAM, plutôt que d'appliquer simplement des architectures héritées plus anciennes au stockage basé sur la RAM.

Tout comme de nombreuses langues plus petites et plus spécialisées ont été largement adoptées ces dernières années, nous entrons dans une ère où des bases de données spéciales seront nécessaires.

Pour une lecture plus approfondie sur ce sujet, je recommande le document académique La fin d'une époque architecturale (il est temps pour une réécriture complète) . Ce n'est pas une lecture difficile.

Il n'est pas clair si cette question concernait spécifiquement SQL Server. L'affiche originale devrait clarifier cela.

Daniel Pittman a écrit:

Si vous avez un petit ensemble de données ou si vous n'avez pas besoin de le conserver sur le disque, il n'y a rien de mal à votre idée. Des outils comme VoltDB s'efforcent de réduire les frais généraux que les anciennes hypothèses> dans les implémentations RDBMS ont fait, ce qui limite les performances en mémoire pure.

Réduire les frais généraux des hypothèses plus anciennes dans les implémentations du SGBDR était exactement l'objectif de conception de VoltDB , mais il évolue horizontalement sans limite architecturale sur la taille des données, et il peut persister sur le disque pour une durabilité complète en utilisant l'instantané et la journalisation des commandes.

Si vous pouvez obtenir un serveur avec suffisamment de RAM pour contenir, au moins, la partie chaude de votre ensemble de données, tout ira bien. En outre, RAID 1 et 5 ne sont pas le moyen le plus rapide d'organiser vos données - RAID 0 est plus rapide, mais vous devrez alors tenir compte des probabilités plus élevées d'une défaillance du système de fichiers qui efface votre base de données - ce n'est pas une bonne chose. . Vous pouvez RAID 1 ou RAID 5 votre matrice RAID 0, à condition d'avoir suffisamment de lecteurs et de contrôleurs.

Vous pouvez même jouer avec la réplication ici - effectuez vos écritures sur un serveur lourd en disques qui se réplique sur un ou plusieurs serveurs gourmands en mémoire où vous exécutez des requêtes compliquées.

Malheureusement, les SGBDR semblent appartenir au domaine du fer à repasser - ils ne sont pas si faciles à développer horizontalement.

C'est un cas de "cela dépend de ce que vous faites". Le "bon" conseil est peut-être d'éviter SQL complètement et d'utiliser memcache / redis / etc!

Je suis d'accord avec vous que la RAM supplémentaire aidera beaucoup, surtout si vous êtes capable de lire l'ensemble de travail en RAM. Oui, il devra toujours écrire des données, mais si vous avez principalement des lectures, les écritures n'auront aucun conflit pour les E / S disque.

Cependant, les performances du disque sont souvent un goulot d'étranglement sur les serveurs SQL et plus difficiles que d'autres choses comme la RAM à mettre à niveau plus tard (si vous avez un serveur qui n'est pas entièrement rempli de modules DIMM).

Il y a eu un certain nombre de commentaires à propos de la lenteur de RAID5, mais je dirais que ce n'est pas toujours le cas, alors soyez prudent avant de faire des déclarations générales. Les serveurs vraiment haut de gamme avec des cartes RAID rapides et beaucoup de BBWC vont parfois beaucoup plus vite en RAID5 (ou RAID50 avec> 4 disques) qu'en RAID10 ...

Au fil des ans, j'ai personnellement connu des matrices RAID5 lentes, mais après avoir comparé un DL360 G5 avec 4 disques SAS 146G en ~ 2009, nous avons dû revérifier nos tests. En effet, la baie est allée plus vite avec RAID5 que RAID10 dans presque tous les tests. BBWC et des calculs de parité rapides ont permis au serveur d'utiliser les 4 disques beaucoup plus efficacement en tant que matrice RAID5 que RAID10. Certains des tests ont montré un débit 50% supérieur avec RAID5, et presque aucun n'était plus lent. Les tests qui étaient plus lents n'étaient que de 5 à 10%.

Je voudrais avertir les gens qui font des déclarations générales que RAID5 est lent, tout le monde le dit en ligne, mais ce n'est tout simplement pas vrai dans tous les cas.

Vous avez un mélange de bonbons à choisir et dépend vraiment de la saveur que vous voulez.

1. Les bases de données auront une configuration pour mettre en cache les requêtes et où ce cache existe, la mémoire ou le disque dur.
2. RAID 5 n'est pas toujours le plus rapide mais RAID 0 (JBOD) est une bande et est rapide, car RAID 5 est également une bande, l'idée est à peu près la même.
3. RAID 1 n'améliorera pas votre vitesse, ce n'est qu'un miroir.
4. Les performances SQL sont basées sur l'indexation et sont la première chose à vérifier. Très important dans les bases de données relationnelles.
5. Ne pas tout indexer, une sur-indexation peut également réduire la vitesse car votre indexation est surchargée.
6. Parfois, avec SQL Joins, la base de données devient plus lente. L'utilisation de la programmation pour boucler un ensemble de résultats indexés minimaux améliore la vitesse.
7. Les serveurs virtuels sont un cauchemar sur la vitesse si vous ne payez pas les dollars.

Mettez simplement investir dans le savoir (gratuit) avant de gagner de l'argent. 1. Apprenez les configurations pour votre base de données et regardez votre configuration actuelle pour l'optimiser. 2. Regardez les instructions de programmation et sql, test unitaire avec des scripts simples qui imitent les opérations impliquées, ce n'est peut-être même pas ce que vous pensez être le problème. SI les scripts simples prennent du temps à l'aide de SQL Joins, divisez-le et faites la même chose avec une boucle programmée pour faire de même. C'est où la mémoire peut aider 3. Regardez le plan d'hébergement et le serveur. Utilisez ps aux dans une console linux et voyez s'il y a quelque chose qui aspire votre mémoire et votre processeur.

Le disque dur absolu améliore la vitesse mais ne dépend pas de vous dans un espace serveur virtuel. La mémoire n'améliore pas la vitesse, sauf si vous configurez les services pour elle, point final. RAID (0,5), RPM et lecture / écriture synchrone avec un bus rapide aident cela. Un processeur de base avec un bon cache l1, l2, l3 aidera à traiter le goulot d'étranglement. puis-je l'entendre pour Xeon!

Dans l'ensemble, vous devez garder à l'esprit la taille et l'évolutivité. Bien que vous puissiez sembler commencer par de petits besoins de stockage, vos données augmenteront très rapidement et de façon exponentielle. Les bases de données utilisent mieux les données atomiques, qui sont des données ventilées à la plus petite taille possible. En raison de sa petite taille, il se déplace plus rapidement dans l'entrepôt de données. Ensuite, vous tenez également compte de la structure de la base de données. À l'avenir, vous pourriez être lié à des bases de données externes, c'est pourquoi la structure est également cruciale. Dans ce scénario, cela ferait peu de différence pour votre requête si la moitié des données vivaient en dehors de votre magasin de données. Lorsque des données sont interrogées, il ne s'agit pas de conserver les données stockées sur la RAM; la requête doit plutôt être rapide pour accéder aux données et les renvoyer.

• Vous n'utilisez vraiment pas toujours RAID 5 pour les données. Cela dépend des données et de leur importance, à côté de ce qui a été mentionné précédemment à propos des sauvegardes. RAID 1 peut être utilisé et l'est.
• Vous devez mettre à niveau tous les serveurs de votre plage de requêtes pour améliorer la vitesse. Étant donné que la plupart des données échappent à votre contrôle, elles vont goulot d'étranglement quelque part en dehors de votre magasin de données. (Dans le cas où vous mettez à niveau le vôtre)