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.