La compression de données SQL Server est-elle catégoriquement bonne pour les bases de données en lecture seule?

Certains documents sur la compression des données SQL Server que j'ai lus indiquent que le coût d'écriture augmente jusqu'à environ quatre fois ce qui serait normalement requis. Cela semble également impliquer qu'il s'agit du principal inconvénient de la compression des données, ce qui implique fortement que pour une base de données d'archives en lecture seule, les performances seront (à quelques exceptions près) améliorées par l'utilisation de la compression des données de pages remplies à 100%.

Les affirmations ci-dessus sont-elles vraies?
Quelles sont les principales "variations" entre la compression des données et autrement (pour la lecture)
- "CPU + x%"?
- "IO -y%"?
- occurrence de partage de page?
- utilisation de tempdb?
- Utilisation de la RAM?
Et pour écrire?

Aux fins de cette question, vous pouvez limiter le contexte à la compression de niveau PAGE d'une grande base de données (> 1 To) , mais des commentaires supplémentaires sont toujours les bienvenus.

Les références:

Blog du moteur de stockage SQL Server (le scénario DW montre que la compression est très avantageuse)
Compression des données: stratégie, planification de la capacité et meilleures pratiques

Une approche plus détaillée pour décider quoi compresser consiste à analyser les caractéristiques de la charge de travail pour chaque table et index. Il est basé sur les deux mesures suivantes:

U: pourcentage d'opérations de mise à jour sur une table, un index ou une partition spécifique, par rapport au nombre total d'opérations sur cet objet. Plus la valeur de U est faible (c'est-à-dire que la table, l'index ou la partition est rarement mis à jour), meilleur est le candidat pour la compression de page.
S: pourcentage d'opérations d'analyse sur une table, un index ou une partition, par rapport au nombre total d'opérations sur cet objet. Plus la valeur de S est élevée (c'est-à-dire que la table, l'index ou la partition est principalement analysée), meilleur est le candidat pour la compression de page.

Les deux éléments ci-dessus sont manifestement biaisés pour recommander la compression de page pour les bases de données de style DW (lecture intensive / exclusive, opérations de Big Data).

— 孔夫子
source

Quelle littérature en particulier? Il y aura toujours une surcharge du processeur pour les deux compresser / décompresser, mais, comme pour les lectures, vous écrivez sur un nombre de pages inférieur aussi. En fait, je pense que le côté écriture bénéficierait encore plus que le côté lecture car le côté lecture aura souvent les pages compressées stockées en mémoire (ce n'est pas toujours, mais un meilleur cas en fonction de la taille des données et de la mémoire allouée).

— Aaron Bertrand

Il sera très difficile de fournir l'une des mesures que vous demandez, car cela dépend entièrement de la nature des données et de la capacité de les compresser (et cela va être différent en fonction de la ligne par rapport à la page, ainsi ). Certaines personnes ont signalé un taux de compression allant jusqu'à 90%, ce qui aura un impact sur l'utilisation de la mémoire (de manière positive) et sur le processeur pour effectuer autant de compression. Ce surcoût papier CPU CPU à 10% pour la compression de ligne et plus élevé pour la page . Ce que vous observez peut être très différent.

— Aaron Bertrand

Pour une base de données d'archives en lecture seule, je suppose que la question serait de savoir si elle peut tenir en mémoire. S'il peut tout tenir en mémoire, une fois qu'il est chargé dans le pool de tampons, il n'y a aucun avantage réel à le compresser. Si, cependant, il ne peut pas tout tenir dans la mémoire, vous pouvez toujours voir un avantage à permuter moins de pages dans et hors du cache même si un travail sera effectué pour le décompresser.

— Aaron Bertrand

Aucun des liens que vous avez ajoutés ne semble faire mention de cette pénalité 4x pour l'écriture. Vous rappelez-vous où vous avez récupéré cela? Voudrait voir le contexte.

— Aaron Bertrand

Eh bien, si vous ne pouvez pas mettre les données en mémoire, ce scénario est un peu théorique, non? :-)

— Aaron Bertrand

Réponses:

Juste mes 2 cents de mes propres expériences sur du matériel vieux de 1 à 2 ans:

Opérations en lecture seule (analyses de style DW, tris, etc.) sur des tables compressées par page (~ 80 lignes / page) J'ai trouvé le seuil de rentabilité à une réduction de la compression de ~ 3x.

C'est-à-dire que si les tables tiennent en mémoire de toute façon, la compression de page ne profite aux performances que si la taille des données a diminué de plus de 3 fois. Vous numérisez moins de pages en mémoire, mais il faut plus de temps pour numériser chaque page.

Je suppose que votre kilométrage peut varier si vos plans sont en boucle imbriquée et lourds. Entre autres, cela dépendrait également du matériel (pénalités d'accès aux nœuds NUMA étrangers, vitesse de la mémoire, etc.).

Ce qui précède n'est qu'une règle de base approximative que je suis, basée sur mes propres tests en utilisant mes propres requêtes sur mon propre matériel (Dell Poweredge 910 et plus récent). Ce n'est pas du gospel hein!

Edit: Hier, l'excellente présentation SQLBits XI de Thomas Kejser a été mise à disposition sous forme de vidéo. Tout à fait pertinent pour cette discussion, il montre le visage «laid» du coût du processeur pour la compression des pages - les mises à jour ont été ralenties de 4x, les verrous maintenus un peu plus longtemps.

Cependant , Thomas utilise le stockage FusionIO et il a choisi une table qui n'est «juste» éligible pour la compression de page. Si le stockage était sur un SAN typique et que les données utilisées étaient compressées 3x-4x, l'image aurait pu être moins dramatique.

— John Alan
source

Cela peut-il être l'ancien matériel? Sur le nouveau matériel, SSD nu Pour le stockage, je trouve que les cœurs ne peuvent pas suivre facilement les disques. Je pense généralement que l'avantage commencerait beaucoup plus rapidement - une réduction de 50% des E / S en vaut la peine si vous n'effectuez pas autant de changements.

— TomTom

TomTom, Storage n'entre pas en jeu pour ces chiffres. La comparaison se fait entre les tables en mémoire non compressées et les tables en mémoire compressées.

— John Alan

Jamais vu un DWH qui était assez bon pour la mémoire. Sérieusement. Vous retomberez sur le disque.

— TomTom

Oui, bien sûr, vous retomberez parfois sur le disque - la lecture à partir du disque est où la compression de page a presque toujours un bord (en supposant que les données sont suffisamment compressibles!). Mais si votre charge de travail se charge à partir du disque une fois puis manipule tout ce qui est en mémoire pour le reste de la journée - combien de poids accorderiez-vous à la lecture du disque et combien aux opérations en mémoire?

— John Alan

Je viens de découvrir un diaporama de présentation pertinent de SQLBits 2013 par Thomas Kejser: slideshare.net/fusionio/…

— John Alan

Je peux ajouter quelques mots de mon environnement Data Warehouse.

L'implémentation de la compression (PAGE dans mon cas) sur une table de test avec 30 millions de lignes (18 Go) réduit la taille de la table de 18 Go à 3 Go! (efficacité de stockage à coup sûr) mais augmentez le temps de chargement (écriture) de 22 à 36 minutes.

Donc, pour lire ou lire et placer les données en mémoire, cela pourrait être une bonne solution, mais pour le chargement quotidien des données, cela pourrait entraîner une dégradation des performances.

— Tomasz Wieczorkowski
source