IdentifiantMot de passe
Loading...
Mot de passe oubli� ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

PostgreSQL aurait commenc� � travailler sur le support de la compression Zstandard


Sujet :

PostgreSQL

  1. #1
    Chroniqueur Actualit�s
    Avatar de Bruno
    Homme Profil pro
    R�dacteur technique
    Inscrit en
    Mai 2019
    Messages
    2 117
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activit� : R�dacteur technique
    Secteur : High Tech - Produits et services t�l�com et Internet

    Informations forums :
    Inscription : Mai 2019
    Messages : 2 117
    Par d�faut PostgreSQL aurait commenc� � travailler sur le support de la compression Zstandard
    PostgreSQL aurait commenc� � travailler sur le support de la compression Zstandard,
    pour compl�ter toutes les possibilit�s de LZ4 que l'on trouve actuellement dans PostgreSQL 14

    Alors que PostgreSQL a support� la compression avec son stockage TOAST et qu'au cours de l'ann�e derni�re, il a d�velopp� le support de la compression LZ4, ainsi que la compression du WAL, la compression des sauvegardes et d'autres utilisations, les d�veloppeurs de PostgreSQL se pr�parent � �tendre davantage leurs capacit�s de compression avec le support de Zstandard (ZSTD).

    Le codage ZSTD prend en charge les types de donn�es SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP et TIMESTAMPTZ et offre un taux de compression �lev� avec de tr�s bonnes performances sur divers ensembles de donn�es. Le ZSTD fonctionne particuli�rement bien avec les colonnes CHAR et VARCHAR qui stockent un large �ventail de cha�nes longues et courtes, comme les descriptions de produits, les commentaires des utilisateurs, les journaux et les cha�nes JSON.

    Nom : PostgreSQLB.jpg
Affichages : 130743
Taille : 17,7 Ko

    Alors que certains algorithmes, tels que l'encodage Delta ou l'encodage Mostly, peuvent potentiellement utiliser plus d'espace de stockage que l'absence de compression, ZSTD est tr�s peu susceptible d'augmenter l'utilisation du disque.

    Cette semaine, une discussion a �t� lanc�e entre les d�veloppeurs de PostgreSQL pour ajouter Zstd comme algorithme de compression support� par ce serveur de base de donn�es open source largement utilis�. Cette discussion s'est av�r�e favorable et d�j� avec PostgreSQL Git il y a maintenant un support pour construire PostgreSQL avec Zstd inclus.

    Bien que cela ajoute l'option --with-zstd build-time et permette de construire avec la biblioth�que de compression Zstd, pour le moment, cela ne permet aucune utilisation r�elle de Zstd dans PostgreSQL. Des commits de suivi sont attendus prochainement pour commencer � permettre � PostgreSQL de tirer parti des capacit�s de compression rapide de Zstandard.

    Nom : zstdB.png
Affichages : 3333
Taille : 40,2 Ko

    � ZStandard est un algorithme de compression d�velopp� par Facebook qui est compl�tement et totalement g�nial. Une fois, j'ai �valu� plusieurs algorithmes de compression pour compresser environ 10 Go de donn�es. La compression la plus �lev�e que j'ai obtenue �tait de l'ordre de 750 Mo avec LZMA, mais la d�compression prenait environ 1,25 minute et la compression prenait environ une demi-heure. Avec ZStd (multiple threads) au niveau 9 de compression, j'ai atteint 1GB avec 3 minutes de compression et 24 secondes de d�compression �, d�clare un Internaute. � LZ4 �tait un peu plus rapide au moins pour la compression, mais les fichiers r�sultants faisaient presque 2GB �, ajoute-t-il.

    C'est formidable de voir toute l'adoption autour de Zstd gr�ce � son bon taux de compression tout en offrant une d�compression (et une compression) tr�s rapide pour ce projet sous double licence (BSD et GPLv2) et centr� sur Facebook. Au moment o� PostgreSQL 15 sortira, il semble que le support de Zstd sera disponible pour compl�ter toutes les possibilit�s de LZ4 que l'on trouve actuellement dans PostgreSQL 14.

    Compression LZ4 TOAST dans PostgreSQL 14

    PostgreSQL 14 fournit l'option de compression LZ4 pour les colonnes. Elle permet une compression plus rapide par rapport � la m�thode PGLZ existante dans TOAST.
    Rappelons que, dans PostgreSQL, une page est l'unit� de base pour stocker des donn�es, et la taille de chaque page est de 8 kB par d�faut. Fondamentalement, les donn�es d'une ligne ne sont pas autoris�es � �tre stock�es sur plusieurs pages. Cependant, certains types de donn�es ont une longueur variable et peuvent d�passer la taille d'une page. Pour surmonter cette limitation, les valeurs des champs de grande taille sont comprim�es et/ou r�parties sur plusieurs lignes physiques. Cette technique est connue sous le nom de TOAST (The Oversized-Attribute Storage Technique).

    Par d�faut, TOAST n'est d�clench� que si une table comporte des colonnes de longueur variable et que la taille des donn�es de la ligne d�passe TOAST_TUPLE_THRESHOLD (normalement 2 ko). Dans un premier temps, les donn�es sont compress�es. Ensuite, si les donn�es sont encore trop volumineuses, elles seront stock�es hors ligne.

    Avant PostgreSQL 14, TOAST ne supportait qu'un seul algorithme de compression : le PGLZ, un algorithme int�gr� � PostgreSQL. Mais d'autres algorithmes de compression peuvent �tre plus rapides ou avoir des taux de compression plus �lev�s que PGLZ.

    Mais � partir de PostgreSQL 14, le SGBD propose une autre option : la compression LZ4 est un algorithme de compression sans perte connu pour sa rapidit�. Afin d'utiliser la nouvelle fonctionnalit� de compression LZ4 dans PostgreSQL14, vous devrez installer les biblioth�ques li�es � LZ4 dans le syst�me d'exploitation, et sp�cifier l'option --with-lz4 lors de la compilation et du packaging de PostgreSQL.

    Les taux de compression de PGLZ et LZ4 sont li�s aux donn�es dupliqu�es, plus il y a d'�l�ments dupliqu�s, plus le taux de compression est �lev�. Cependant, la compression ne sera pas effectu�e dans les cas o� PostgreSQL �value que le ratio r�sultant ne serait pas bon, m�me si la taille des donn�es atteint le seuil. En effet, la compression ne permettrait pas d'�conomiser efficacement de l'espace disque, et entra�nerait au contraire un temps et des ressources suppl�mentaires pour la d�compression.

    Selon le code source actuel de PostgreSQL14, PGLZ exige un taux de compression d'au moins 25 %, tandis que LZ4 exige seulement que les donn�es compress�es ne soient pas plus grandes que les donn�es non compress�es.

    Source : PostgreSQL

    Et vous ?

    Selon vous, pourquoi PostgreSQL doit-il prendre en charge la compression lui-m�me ?

    N'est-il pas plus logique de fournir la compression � partir du syst�me de fichiers ?

    Y a-t-il un avantage particulier � ce que PostgreSQL r�implante sa propre compression ?

    Voir aussi :

    PostgreSQL 10 est disponible en t�l�chargement : quelles sont les nouveaut�s de la derni�re version du SGBD libre ?

    Disponibilit� g�n�rale de PostgreSQL 11 : un aper�u des principales fonctionnalit�s du SGBDRO libre

    OpenZFS 2.0 est disponible avec la prise en charge de Linux et FreeBSD et apporte de nouvelles fonctionnalit�s comme la compression ZStandard

    Ubuntu 18.10 est disponible, embarque GNOME 3.30 pour une nouvelle apparence et s'installe plus vite gr�ce � l'algorithme de compression Zstandard
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et R�digez des actualit�s

  2. #2
    R�dacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par d�faut
    Ils sont quand m�me � cent mille lieux des algorithmes de compressions en �uvre dans Oracle, DB2 ou SQL Server qui ne n�cessitent aucune d�compression pour lire les donn�es !!!

    Affligeant !
    Fr�d�ric Brouard - SQLpro - ARCHITECTE DE DONN�ES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : mod�lisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre Expert Avatar de gabriel21
    Homme Profil pro
    Administrateur syst�mes et r�seaux
    Inscrit en
    F�vrier 2007
    Messages
    548
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activit� : Administrateur syst�mes et r�seaux
    Secteur : A�ronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : F�vrier 2007
    Messages : 548
    Par d�faut
    Question : tu fais comment pour lire une donn�e compress�e sans la d�compresser auparavant. A ma connaissance, il n'existe aucun algorithme qui le permette. Si c'�tait le cas la totalit� des OS l'aurait impl�ment� pour le stockage ainsi que les protocoles r�seaux. D�s que tu fais de la compression, tu doit d�compress� pour acc�der � la donn�e. Il existe de nombreuses astuce pour donner l'illusion � l'utilisateur du temps r�el, ou bien les syst�mes utilisent des composants d�di� qui g�rent l�algorithme de compression et de d�compression en temps r�el. C'est souvent le cas pour les �quipement r�seaux, les cartes graphiques, les coprocesseurs vid�o qui impl�mentent directement certains CODEC vid�o. Et encore en r�seau, pour ne pas surcharger les syst�mes, seule la charge utile est compress�e, les en t�te ne le sont pas pour permettre un acheminement plus simple, bien que certains syst�mes fasse une compression compl�te avec chiffrement et qui dans ce cas l� n�cessite en bout de liaison le m�me �quipement. C'est utilis� sur des syst�me point � point avec ligne d�di�e (aucun �quipement de routage entre les deux, seulement des r�p�teurs) ou des liaisons satellite quand il y a une forte contrainte de s�curit� et de bande passante.

  4. #4
    R�dacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par d�faut
    Citation Envoy� par gabriel21 Voir le message
    ...A ma connaissance, il n'existe aucun algorithme qui le permette.
    La R&D des grands �diteurs de SGBDR (Oracle, IBM DB2, Microsoft Research) ont travaill� depuis le d�but des ann�es 90 sur ce sujet avec les universit�s...

    Les principales techniques mises en jeu sont les suivantes :

    1) �limination des octets de stockage pour les donn�es NULL
    2) r�duction de la taille de certains types de donn�es (en particulier FLOAT et DECIMAL) en fonction de la valeur stock�e
    Ceci existe depuis 2005 dans SQL Server (sparce columns, vardecimal).
    PostGreSQL a donc au moins 19 ans de retard sur ces techniques

    3) compression par dictionnaire (�limination des redondances) int�ressant pour la BI et pr�sent de mani�re automatique dans Oracle BI et SQL Server Analysis Services
    PostGreSQL n'utilise m�me pas ce principe alors que cela existe dans SQL Server 2000 soit depuis 22 ans.... (SSAS)

    4) conversion automatique des donn�es de taille fixe en taille variable
    5) compression de type racine avec m�thode du dictionnaire partiel + compl�ment (pour les chaines de caract�res)
    Ceci existe depuis la version 2008 de SQL Server sous le nom de DATA_COMPRESSION = ROW et DATA_COMPRESSION = PAGE
    PostGreSQL a donc l� aussi au moins 14 ans de retard et cet article ne parle pas du tout de ce genre de technique de compression !

    Un exemple de compression de table :
    Nom : SQL-Server-data-compression-effects.jpg
Affichages : 2766
Taille : 42,7 Ko
    Ou la compression, non seulement est de 6,5 pour la table, mais am�liore grandement les temps de r�ponse...

    Et comment �a marche :
    https://docs.microsoft.com/en-us/sql...ql-server-2017
    Cela utilise plus de CPU mais moins d'acc�s. Sur de grande tables, cela est plus rapide pour les requ�tes. Sur de petite table, aucun int�r�t !


    6) le stockage vertical des donn�es des tables appel� COLUMSTORE (en lieu et place du stockage horizontal par ligne appel� ROWSTORE)
    Disponible dans SQL Server depuis la version 2012
    N'existe pas dans le libre, mais certains �diteurs le font payer 500 $ par mois ! (swarm64, Citus...) pour PostGreSQL alors que cela existe, m�me pour la version gratuite, dans SQL Server !!!
    PostGreSQL a donc l� aussi au moins beaucoup de retard et aucune vision de le faire :
    https://wiki.postgresql.org/wiki/ColumnOrientedSTorage

    Le probl�me des tenants du libre c'est qu'ils se focalisent sur le libre croyant que c'est le Graal alors que les entreprise priv�e font de la R&D... La seule chose que fait le libre c'est de copier en plus mal et avec beaucoup de peine et de retard ce que font les autres... Par exemple PostGreSQL copie toute ce que fait Oracle en pire au lieu de prendre le meilleur de la techno de chaque SGBDR ! Un exemple flagrant dans PostGreSQL est la m�thode inepte de partitionnement pomp�e d'Oracle mais en pire !

    Voici quelques uns des papiers de recherche sur le sujet :
    Data Compression in Database Systems (1998)
    Query Optimization In Compressed Database Systems (2001)
    Data Compression in Oracle
    Integrating Compression and Execution in ColumnOriented Database Systems (2006)
    Compression Aware Physical Database Design (2011)

    Le probl�me c'est que le design d'un SGBDR comme Oracle ou SQL Server c'est environ 10 000 ann�es homme en R&D... Le libre n'en a ni les moyens ni l�organisation.

    Rappelons que pour information, PostGreSQL � corrompu des milliers de bases de donn�es sous Linux � cause de sa mauvaise impl�mentation de FSync sans jamais s'en apercevoir... !

    A +
    Fr�d�ric Brouard - SQLpro - ARCHITECTE DE DONN�ES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : mod�lisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre Expert Avatar de gabriel21
    Homme Profil pro
    Administrateur syst�mes et r�seaux
    Inscrit en
    F�vrier 2007
    Messages
    548
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activit� : Administrateur syst�mes et r�seaux
    Secteur : A�ronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : F�vrier 2007
    Messages : 548
    Par d�faut
    Merci pour ces informations.
    Certaines des techniques ne sont pas � proprement parler de la compression, mais des optimisations de la m�moire. Je ne connaissais pas d'ailleurs certaines d'entre elle.
    Mais je comprends maintenant le sens de ta phrase. Nous ne parlions tout simplement pas de la m�me chose. Mais il est vrai que l'utilisation du mot compression dans la documentation Microsoft pour les deux, peut laisser un doute.

  6. #6
    R�dacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par d�faut
    � moins que je ne soit d�bile, il s'agit tout � fait de compression. Je pense que tu n'a lu aucun des papiers de recherche que j'ai mis en r�f�rence...
    Voici une d�finition tir�e du dictionnaire ROBERT du terme compression, avec une entr�e sp�ciale pour l'informatique :
    Traitement math�matique permettant de r�duire la taille d'un ensemble de donn�es, pour en faciliter le stockage, la transmission�
    https://dictionnaire.lerobert.com/de...on/compression

    Or toutes les techniques que je viens de te montrer r�duisent bien la taille des donn�es. Par cons�quent, toutes sont de la compression, et dans la litt�rature professionnelle, on parle syst�matiquement de compression pour tous les sujets que je viens de t'�voquer... Lis donc les papiers dont j'ai donn� les URL !

    A +
    Fr�d�ric Brouard - SQLpro - ARCHITECTE DE DONN�ES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : mod�lisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Membre Expert Avatar de gabriel21
    Homme Profil pro
    Administrateur syst�mes et r�seaux
    Inscrit en
    F�vrier 2007
    Messages
    548
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    �ge : 43
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activit� : Administrateur syst�mes et r�seaux
    Secteur : A�ronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : F�vrier 2007
    Messages : 548
    Par d�faut
    Or toutes les techniques que je viens de te montrer r�duisent bien la taille des donn�es. Par cons�quent, toutes sont de la compression, et dans la litt�rature professionnelle, on parle syst�matiquement de compression pour tous les sujets que je viens de t'�voquer... Lis donc les papiers dont j'ai donn� les URL !
    Je les ai lu. La plupart �tant en anglais, je peux avoir fait des contre sens.
    Oui et non. Lorsque tu compresses (destructif ou non) tu r�duis la taille des donn�es. Quand tu optimises, tu r�duis les espaces perdu du fait du fonctionnement des m�moires (volatile ou non) donc tu augmentes le nombre de donn�es que tu peux stocker ou tu r�duis le nombre de pages m�moire demand�e (consommation de RAM inf�rieure pour un m�me volume de donn�e) et quand tu commences � travailler avec des bases de plusieurs t�raoctets en RAM et sur les disques, ces optimisations deviennent tr�s vite indispensable. Effectivement certains utilisent le mot compactage de m�moire en lieu et place d'optimisation. Et on peut traduire le compression anglais en compactage. Nous touchons l� un probl�me de langue.
    Je reconnais que je n'ai vu passer ce type de diff�renciation que dans des cours d'architecture syst�mes ou de d�veloppement C ou C++. Les langages de haut niveau tel que java ou python ne sont pas impact� du fait que ces probl�mes sont g�r�s par la machine virtuelle ou l�interpr�teur. Il n'est pas effectivement n�cessaire de conna�tre le fonctionnement intime des ordinateurs pour utiliser un SGBD. Par contre pour le d�velopper oui, et cela confirme que les d�veloppeur de Microsoft connaissent leur sujet.

    La compression par dictionnaire est bel et bien un compression qui n�cessite une op�ration de d�compression pour �tre lu. M�me si certaines optimisations du dictionnaire � base de pointeur ou de r�f�rence permette de r�duire le temps de traitement. Et c'�tait l� tout mon propos, m�me si la d�compression est faite en temps r�elle, elle est quand m�me l�. Je reconnais que Microsoft utilise le verbe "to retrieve" pour signaler la d�compression, ce qui peut laisser un doute.

    Le fait de r�duire le nombre d'octet que prends l'information dans une page m�moire, en n'utilisant que les octets significatif est quand � lui bien une optimisation de la m�moire. Ce type de technique demande plus de ressource en terme de puissance de calcul puisque l'on casse les alignements et qu'il faut le signaler au processeur. Ces alignements sont des contraintes techniques des processeurs et des m�moires volatile ou non. Contrainte que l'on peux d�passer sous certaines conditions, mais qui n�cessite une tr�s bonne connaissances des architectures techniques et des noyaux. Cette probl�matique se retrouve aussi dans les syst�mes de fichiers. Sur Windows, dans les propri�t�s d'un fichier, tu as la taille du fichier et la taille r�elle sur le disque. Pour les gros fichiers, la diff�rence est minime, pour les petits fichiers elle peut �tre importante (ratio) du fait du fonctionnement de NTFS (https://docs.microsoft.com/fr-fr/win.../ntfs-overview). Raison pour laquelle, la majorit� des SGBD demandent g�n�ralement des acc�s en donn�e brute (RAW) aux stockages non volatile. Le syst�me exploitation n'a alors aucune id�e de comment sont organis� les donn�es dans les fichiers de la base de donn�e. Ce ne sont que des suites de 0 et 1. Tout comme il n'a aucune id�e de comment sont organis� les donn�es en RAM, il sait seulement que les pages m�moire X appartiennent au programme A et les pages m�moires Y au programme B. La seule chose qui lui importe est de savoir si le programme a le droit d'acc�der ou pas d'acc�der � cette page m�moire et qu'il ne d�passe pas sur une page voisine. Ce type de probl�matique est extr�mement important dans les d�veloppements en C et C++ (tr�s probablement en C#, mais je n'en ai pas fait) qui sont de t�te les langages utilis� par Microsoft pour d�velopper MS-SQL ainsi que leur OS.

  8. #8
    R�dacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    D�tails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes C�te d'Azur)

    Informations professionnelles :
    Activit� : Expert bases de donn�es / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par d�faut
    Citation Envoy� par gabriel21 Voir le message
    ...je peux avoir fait des contre sens.
    Oui
    Lorsque tu compresses (destructif ou non) tu r�duis la taille des donn�es.
    Oui

    Quand tu optimises, tu r�duis les espaces perdu du fait du fonctionnement des m�moires (volatile ou non) donc tu augmentes le nombre de donn�es que tu peux stocker ou tu r�duis le nombre de pages m�moire demand�e (consommation de RAM inf�rieure pour un m�me volume de donn�e) et quand tu commences � travailler avec des bases de plusieurs t�raoctets en RAM et sur les disques, ces optimisations deviennent tr�s vite indispensable. Effectivement certains utilisent le mot compactage de m�moire en lieu et place d'optimisation. Et on peut traduire le compression anglais en compactage.
    Non. L'optimisation dans un SGBDR n'a rien � voir avec la compression. En r�gle g�n�rale, la compression, qu'elle quelle soit fait perdre des performances. Soit au moment de stocker la donn�es, soit au moment de l'exploiter. Elle peut aussi en faire gagner, mais tr�s peu, par le simple fait de la r�duction du volume � parcourir... Mais l'optimisation ce sont par exemple :
    • l'emploi d'un index en mode recherche (seek) en lieu et place d'un balayage de toutes les lignes de la table (scan)
    • le fait que l'optimiseur d�cide d'utiliser tel ou tel algorithme de jointure en fonction des cardinalit�s en jeu
    • La r�crite des requ�tes par factorisation, simplification, modification de l'enchainement des diff�rentes t�ches en jeu dans la requ�te.

    Tout cela �tant le fait de l'optimiseur

    La compression par dictionnaire est bel et bien un compression qui n�cessite une op�ration de d�compression pour �tre lu.
    Non.
    Un simple exemple. Si je cherche quel est l'age d'une personne nomm� DUPONT Alain, l'information se trouve bien telle qu'elle dans la base et ne n�cessite pas de d�compression. M�me si les donn�es sont r�parties � diff�rents endroit, c'est une seule lecture que l'on effectue. Dans tous les cas l'information d'un ensemble de ligne, sans aucune m�thode de compression, r�parti � diff�rents endroit qu'il faut recoller pour apporter l'information au dataset. Mieux encore, l'utilisation d'un index impose souvent une double lecture (index + table) qui est bien plus p�nalisante que de recoller diff�rents �l�ments d'une m�me ligne de donn�es situ� dans la m�me page et dans le m�me "slot" de ligne. Pour information, je te montre comment les lignes des tables sont structur�es dans MS SQL Server

    Nom : Figure 10-013 - Structure ligne -C LEROY.png
Affichages : 2660
Taille : 147,3 Ko
    Etrait de mon livre "SQL Server 2014" - Eyrolles �ditions

    Tu verras que toutes les colonnes de type fixe (CHAR, DATE, INT...) sont stock�s en premier et toutes les donn�es de taille variable (VARCHAR notamment) sont stock�es en dernier pour des raisons d'efficacit� d'acc�s. Doit on parler de compression dans ce cas ? �videmment non. Pourtant il faut bien aller chercher les colonnes que l'on souhaite voir figurer dans le dataset � diff�rents endroits.

    ... Je reconnais que Microsoft utilise le verbe "to retrieve" pour signaler la d�compression, ce qui peut laisser un doute.
    C'est pour cela qu'il n'y a pas d�compression de l'information pour la lire...

    Le fait de r�duire le nombre d'octet que prends l'information dans une page m�moire, en n'utilisant que les octets significatif est quand � lui bien une optimisation de la m�moire. Ce type de technique demande plus de ressource en terme de puissance de calcul puisque l'on casse les alignements et qu'il faut le signaler au processeur.
    Ce que l'on ne fait jamais pour les SGBDR car sinon, certains algorithmes ne fonctionnerait plus (tris, groupage, d�doublonnement avec distinct en particulier qui n�cessite un alignement pour des raisons d'efficacit� !

    ... Raison pour laquelle, la majorit� des SGBD demandent g�n�ralement des acc�s en donn�e brute (RAW) aux stockages non volatile.
    Oui.

    A +
    Fr�d�ric Brouard - SQLpro - ARCHITECTE DE DONN�ES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : mod�lisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. R�ponses: 0
    Dernier message: 24/04/2020, 11h27
  2. R�ponses: 2
    Dernier message: 11/07/2018, 13h51
  3. R�ponses: 4
    Dernier message: 06/01/2016, 17h09
  4. [AC-2003] Acc�der et travailler sur une base de donn�es POSTGRESQL
    Par flet le kid dans le forum Mod�lisation
    R�ponses: 3
    Dernier message: 01/05/2009, 19h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo