L'avènement du SSD a-t-il une implication pour l'optimisation de la base de données?

Aujourd'hui, je parcourais un livre sur l'optimisation de SQL Server et il semblait qu'une certaine quantité d'idées était basée sur un modèle linéaire de stockage. Étant donné que les SSD ont un modèle de stockage complètement différent, modifient-ils le jeu de quelque manière que ce soit en ce qui concerne le réglage ou l'optimisation de la base de données?

Oui, ils changent le jeu. Les optimisations basées sur les caractéristiques des disques magnétiques en rotation (comme le temps de recherche et le délai de rotation ) peuvent ne pas être pertinentes sur les disques SSD. Un article récent ^* publié dans FITME 2010 présente un nouvel algorithme d'optimisation des requêtes basé sur les caractéristiques des SSD.

Cependant, ces changements seront probablement des changements de bas niveau (aux algorithmes de stockage et de récupération, par exemple) qui peuvent être mis en œuvre efficacement par les développeurs de bases de données. Ils n'affecteront probablement pas autant les utilisateurs de la base de données.

^* IEEE Xplore - Une optimisation de requête de stockage orientée colonne pour une base de données flash

Performance

Les SSD sont performants: ils n'ont pas à chercher et le débit est flamboyant. La plupart des logiciels traitant des disques, dans la mesure où ils sont optimisés, sont optimisés pour réduire le nombre de recherches synchrones. Ce faisant, ils introduisent des hôtes de complexités. Avec l'avènement d'écritures rapides et sans recherche sur le stockage persistant, les nouveaux systèmes de stockage de données n'auront plus besoin de telles complexités.

Durabilité

Les SSD ont actuellement des taux d'échec élevés. Votre SSD échouera. Vos SSD échoueront à un rythme beaucoup plus élevé que les disques magnétiques. Vous devez contourner cela avec la réplication, les sauvegardes, etc. Cela introduit son propre ensemble de complexités.

La baisse globale du prix du stockage a des effets beaucoup plus profonds.

Avant d'avoir SQL, nous avions des bases de données hiérarchiques et réseau super-optimisées où les administrateurs de bases de données devaient planifier soigneusement le placement des données sur les pistes et les cylindres.

Les bases de données SQL sont beaucoup moins efficaces. Mais maintenant que les disques sont bon marché, énormes et rapides, nous nous en soucions à peine.

Les bases de données NoSQL ("Document") peuvent être un peu moins efficaces que SQL car il n'y a pas la même capacité de mappage logique-physique entre le schéma logique SQL et le schéma physique sous-jacent de fichiers ou d'espaces de table ou autre. Et nous nous en soucions à peine.

Les améliorations des performances SSD sont susceptibles d'être perdues dans les changements causés par l'utilisation de bases de données NoSQL à la façon dont nous architecturons les systèmes dans leur ensemble.

Le principal problème avec l'optimisation de quoi que ce soit pour les SSD a à voir avec la façon dont ils écrivent les données. Un disque dur traditionnel stocke généralement des données dans de petits secteurs d'environ 512 octets et peut réellement manipuler des secteurs directement ou même en dessous de ce niveau.

Les disques SSD présentent certains inconvénients en ce qui concerne les écritures:

• Une taille d'écriture par bloc minimale d'environ 4 à 8 Ko.
• Les écritures ne peuvent être effectuées que sur une base pleine page, généralement de 256 Ko.
• Seuls les blocs vides peuvent être écrits.

Un scénario de cauchemar typique, appelé amplification d'écriture , consiste à écrire un seul octet dans un emplacement sur le disque qui contient déjà des blocs. Pour y écrire, vous devez d'abord copier la page entière de 256 Ko dans la mémoire, effacer le bloc entier, changer le seul octet de la page, puis réécrire la page entière de 256 Ko modifiée. Donc, pour écrire un seul octet, il y a eu environ un demi-mégaoctet de "trafic"!

Il existe de nombreuses optimisations pour ce problème implémentées au niveau du SSD, du contrôleur et même du système d'exploitation, mais les SGBD peuvent sans aucun doute bénéficier en adaptant ces optimisations à leur fonctionnement spécifique.

Ce n'est cependant pas quelque chose que les utilisateurs de base de données (comme dans l'utilisation d'une base de données dans leur application) doivent penser, car cela dépendra fortement des décisions de conception / mise en œuvre au niveau du SGBD.

D'après ce que j'ai recueilli sur le blog ServerFault , les serveurs de base de données doivent avoir un matériel robuste. Le serveur de base de données des sites d'échange de pile exécute des SSD (voir http://blog.serverfault.com/post/our-storage-decision/ ) et j'imagine que l'optimisation des requêtes est toujours très nécessaire. Le processeur et la mémoire sont affectés par les requêtes de base de données ainsi que par les E / S.

Cependant, les performances de la base de données dépendent beaucoup des E / S, donc les SSD seraient certainement utiles.

Oui, pour les raisons que tout le monde a mentionnées.

J'écoutais un podcast disant que de gros morceaux de SGBDR comme Oracle, SQL Server, etc. commenceraient à être "optionnés" s'ils pouvaient travailler correctement la séparation. Détectez s'il s'agit d'un disque SSD et optimisez-le en conséquence.

Il y a beaucoup de code supplémentaire intégré dans la mise en cache et l'écriture de données qui n'est tout simplement plus nécessaire.

Encore plus intéressant, le RAMSAN et ses variantes. Fondamentalement, un disque dur composé de puces RAM avec un onduleur X heures intégré et la possibilité d'écrire en arrière-plan sur un stockage HDD à plus long terme.