L'auteur de cet article est Feng Ke, architecte en chef de Huawei Cloud Database GaussDB
présentation de fond
La combinaison de la compression de données et des bases de données relationnelles n'est plus un sujet nouveau, nous avons vu divers produits et solutions de compression de bases de données. Pour GaussDB, l'introduction de la compression de données aujourd'hui, quelle valeur différente peut-elle apporter aux clients, est une question à laquelle nous réfléchissons depuis un certain temps dans le passé.
Pour répondre à cette question, nous avons d'abord effectué des tests approfondis sur divers algorithmes de compression courants, de LZ4/Snappy avec les meilleures performances, à Zstd/Zlib avec des performances et un taux de compression équilibrés, à LZMA/BZip avec un accent sur le taux de compression. Nous avons constaté que même les meilleurs algorithmes de compression ne peuvent le faire sans affecter de manière significative les performances d'une base de données en ligne. Nous avons également étudié diverses méthodes de codage dans le domaine des bases de données, y compris certaines méthodes de codage basées sur la prédiction et l'ajustement linéaire publiées par la communauté universitaire ces dernières années. À partir des résultats des tests et des mesures réelles publiées par la recherche, le codage de la base de données est utilisé pour résoudre des problèmes spécifiques. Par rapport à la maturité de l'algorithme de compression, il n'existe actuellement aucune méthode générale de codage de base de données qui puisse fournir un taux de compression stable dans la plupart des scénarios dans des ensembles de données réels.
C'est notre jugement technique de base dans le domaine de la compression de bases de données. La pratique passée des produits a également vérifié ce point. Nous avons vu que de nombreuses bases de données commerciales et de bases de données open source prennent en charge la compression. La plupart du temps, le choix laissé aux clients est de décider d'activer ou non la compression sur une table spécifique. Activer la compression, c'est économiser de l'espace, mais en même temps dégrader les performances.Ce choix apparemment simple est précisément le plus difficile à faire pour les clients. C'est pourquoi il existe tant de produits de compression de bases de données, mais nous voyons rarement la raison fondamentale pour laquelle la compression de données est vraiment largement utilisée dans les affaires en ligne de bases de données.
Cela nous donne plus d'inspiration. Nous pensons que la technologie de compression de base de données réellement applicable, qui peut équilibrer le taux de compression et l'impact commercial, doit être sélective. Autrement dit, nous pouvons déterminer la température des données sur la base de la technologie, et sur la base de cette détermination, nous pouvons compresser de manière sélective des données relativement froides dans l'entreprise sans toucher à ces données relativement chaudes.
Un tel choix technique signifie que nous ne pouvons pas satisfaire tous les scénarios d'entreprise.Nous exigeons que la distribution de la température des données de l'entreprise respecte la règle de distribution 80-20. Autrement dit, nous compressons les données froides qui occupent 80 % des besoins de stockage mais seulement 20 % des besoins informatiques, et nous ne touchons pas aux données chaudes qui n'occupent que 20 % des besoins de stockage mais occupent 80 % des besoins informatiques. Heureusement, nous avons constaté que la plupart des entreprises nécessitant un contrôle de la capacité présentent de telles caractéristiques.
Sélection du scénario et de la cible
Grâce à l'analyse d'un grand nombre de scénarios d'entreprise, nous avons constaté que les besoins de l'entreprise en matière de technologie de compression de base de données sont diversifiés. Il existe des scénarios de compression de stockage de transaction en ligne (OLTP), des scénarios de compression de stockage d'entreprise d'analyse (OLAP) et une compression de stockage d'entreprise historique. Il existe également des scénarios dans lesquels la transmission commerciale de reprise après sinistre est compressée. Dans différents scénarios, les exigences de la technologie de compression sont complètement différentes en termes d'indicateurs tridimensionnels de performances de compression, de taux de compression et de performances de décompression, et en termes de tolérance à l'intrusion commerciale.
Cela signifie que si nous voulons créer une fonctionnalité de compression avancée GaussDB à scénario complet, il doit s'agir d'une combinaison de plusieurs technologies, y compris différents algorithmes de compression, différents modèles et méthodes de jugement à chaud et à froid, différentes organisations de stockage de données, etc., via différentes Combinaison de technologies et d'applications pour répondre aux besoins de différents scénarios.
Cela signifie également que nous devons avoir un compromis prioritaire dans la prise en charge de différents scénarios d'application de compression. Notre réponse est de choisir de donner la priorité à la prise en charge des scénarios de compression de stockage OLTP.C'est le domaine d'activité où nous pensons que la technologie de compression de base de données est la plus précieuse, et bien sûr c'est aussi le domaine qui présente les plus grands défis techniques.
Après avoir déterminé le scénario, l'étape suivante consiste à déterminer l'objectif technique. Le type de compétitivité de base que nous voulons construire pour ce scénario dépend de notre analyse des scénarios clients typiques. Nous avons identifié deux scénarios clients typiques :
Scénario A : L'activité du client provient d'un mini-ordinateur IBM avec une capacité de base de données unique de 50 To. Après avoir migré vers la plate-forme ouverte, il est confronté aux problèmes de capacité excessive et de longues fenêtres d'exploitation et de maintenance. Choisir de désassembler la base de données signifie une transformation distribuée.Pour une entreprise clé existante qui fonctionne de manière stable depuis de nombreuses années, le risque de choisir cette technologie est trop élevé. Le choix de la compression peut réduire considérablement les risques de capacité, mais la conception initiale de l'entreprise n'a pas pris en compte la séparation du chaud et du froid (comme l'établissement de partitions basées sur la dimension temporelle). Une prise en charge de la technologie de compression zéro intrusive est nécessaire, et l'impact sur la performance de l'entreprise est suffisamment faible.
Scénario B : l'activité du client est déployée sur la base de clusters distribués. La capacité d'un seul cluster a dépassé 1 Po et continue de croître rapidement, nécessitant une extension régulière. Le choix de la compression peut réduire la fréquence d'extension de la capacité, réduire considérablement les coûts des logiciels et du matériel d'entreprise et réduire le risque de changement. Cependant, la conception de la distribution de données de l'entreprise est orientée vers l'évolutivité (telle que la création de partitions basées sur la dimension utilisateur), sans tenir compte de la séparation du chaud et du froid. Par conséquent, l'entreprise a également besoin d'un support de technologie de compression zéro intrusif avec un suffisamment faible impact sur les performances.
En triant les exigences des scénarios clients typiques, nous avons déterminé les objectifs de conception de base de la compression de stockage OLTP GaussDB :
-
Le jugement à chaud et à froid ne doit être aucunement intrusif pour l'entreprise et ne doit pas dépendre de la distribution de données existante et du modèle logique de l'entreprise ;
-
L'impact sur le business doit être suffisamment faible, nous définissons l'objectif à moins de 10%, et challengeons 5% ;
-
Pour fournir un taux de compression raisonnable, nous définissons la cible comme n'étant pas inférieure à 2:1.
La définition des objectifs de conception de base nous permet de transformer la sélection technologique ultérieure dans chaque scénario spécifique en un problème déterministe.
Jugement chaud et froid
Après avoir déterminé les objectifs de conception, nous avons commencé à mettre en œuvre le projet. Il y a trois problèmes à résoudre : 1) Comment réaliser la détermination des données chaudes et froides ; 2) Comment réaliser l'organisation du stockage des données compressées ; 3) Comment réaliser un algorithme de compression compétitif.
Pour les jugements chauds et froids, la granularité du jugement doit d'abord être déterminée. Le jugement à chaud et à froid des données peut être mis en œuvre en fonction de différentes granularités, telles que le niveau ligne, le niveau bloc ou le niveau table/partition. Plus la granularité est grossière, plus la complexité de la mise en œuvre est faible, mais plus l'intrusion sur l'entreprise est importante. Sur la base des objectifs de conception, il est naturel que nous choisissions le jugement chaud et froid au niveau de la ligne, qui est la solution la moins dépendante de la distribution des données d'entreprise. Ce que nous devons résoudre, c'est comment contrôler le coût d'introduction du chaud et du froid jugement.
Nous avons astucieusement résolu ce problème en utilisant le mécanisme existant du moteur de stockage GaussDB. Plus précisément, le moteur de stockage GaussDB enregistre l'ID de transaction (XID) de la dernière modification de la ligne dans les métadonnées Meta de chaque ligne de données. Cette information est utilisée pour prendre en charge le jugement de visibilité de la transaction, implémentant ainsi le contrôle de la concurrence multi-versions. (MVCC). Pour une ligne spécifique, si son XID est suffisamment "ancien" pour être visible par toutes les transactions actuellement actives, nous ne nous soucions pas réellement de la valeur spécifique du XID pour le moment. Nous pouvons introduire un indicateur spécifique (FLG) pour l'enregistrer, et la valeur renseignée dans le XID d'origine peut être remplacée par une heure physique, qui représente la borne supérieure de l'heure de dernière modification (LMT, Last Modified Time) de la ligne à laquelle il appartient. De toute évidence, LMT peut être utilisé pour prendre en charge les jugements à chaud et à froid (voir la figure 1 pour plus de détails) :
Figure 1 : Détermination du chaud et du froid au niveau de la ligne
APRÈS 3 MOIS SANS MODIFICATION
À ce moment, le système analyse la table cible et compresse toutes les lignes qui satisfont l'heure actuelle moins le LMT pendant plus de 3 mois.
Notez que dans le schéma ci-dessus, nous n'avons en fait identifié que les points chauds d'écriture des lignes, mais pas les points chauds de lecture des lignes. Nous savons seulement que les lignes qui remplissent les conditions n'ont pas été mises à jour dans les 3 mois, mais nous ne pouvons pas confirmez que ces lignes sont dans les mois 3. Si elles sont lues fréquemment dans un mois. Actuellement, il n'existe pas de solution technique à faible coût pour maintenir les hotspots de lecture des lignes. Pour les services de pipeline tels que les détails des commandes, cette solution fonctionne bien, car la lecture et l'écriture des données présentent les mêmes caractéristiques de température, et sa fréquence d'accès continue de diminuer à mesure que le temps non modifié augmente. Mais pour les services de collecte comme les albums photo sur téléphone portable, il peut ne pas suffire de s'identifier et d'écrire uniquement, car une relation de collecte établie très tôt peut encore être fréquemment consultée.
Cela signifie que même si le système fait des jugements à chaud et à froid, nous devons toujours optimiser les scénarios dans lesquels l'entreprise peut accéder aux données compressées. Nous laissons ce problème à l'organisation du stockage et à l'algorithme de compression. Pour l'algorithme de compression, nous accordons plus d'attention à ses performances de décompression.
Un autre problème est que dans certains scénarios, l'utilisation du jugement chaud et froid par défaut peut ne pas suffire. Par exemple, pour certains types de transactions, les détails de la commande générée peuvent en effet ne pas être modifiés dans les 3 mois, mais seront mis à jour après un certain condition de déclenchement est remplie (comme le déblocage des transactions sécurisées). Ce scénario n'est pas courant dans les entreprises réelles, mais si l'entreprise se soucie vraiment des performances, nous prenons en charge la possibilité pour l'entreprise de personnaliser des règles en plus des règles de jugement à chaud et à froid par défaut, telles que :
APRÈS 3 MOIS SANS MODIFICATION SUR (order_status = « terminé »)
À ce moment, le système ne compressera que les données qui n'ont pas été modifiées depuis 3 mois et dont le statut de la commande est terminé.
Actuellement, les règles personnalisées que nous prenons en charge sont toutes les expressions de ligne légales. L'entreprise peut écrire n'importe quelle expression complexe pour représenter les règles de jugement à chaud et à froid des données, mais tous les champs référencés dans les expressions ne peuvent être que les champs de la table cible. des champs. Grâce à cette combinaison de règles par défaut et personnalisées, nous offrons aux entreprises un seuil d'utilisation suffisamment bas et une meilleure flexibilité.
organisation de stockage
Lorsque les lignes qui répondent aux conditions d'évaluation à chaud et à froid sont compressées, nous devons décider comment stocker les données compressées. En fonction de l'objectif de conception, nous choisissons l'implémentation d'organisation de stockage avec la moindre intrusion métier : la compression intra-bloc.
Nous savons que l'organisation du stockage des bases de données relationnelles est basée sur des blocs de longueur fixe. Dans la base de données GaussDB, la taille typique des blocs de données est de 8 Ko. Le choix d'un bloc de données plus volumineux est évidemment bénéfique pour la compression, mais cela aura un impact plus important sur les performances de l'entreprise. Influencer. La compression dite intra-bloc fait référence à : 1) toutes les lignes d'un même bloc qui satisfont aux conditions de jugement chaud et froid seront compressées dans leur ensemble ; 2) les données formées après la compression sont stockées dans le bloc de données actuel, et la zone de stockage est appelée BCA (Block Compressed Area), qui est généralement située à la fin du bloc.
La conception de la compression intra-bloc signifie que la décompression des données ne dépend que du bloc actuel, sans accéder à d'autres blocs de données. Du point de vue du taux de compression, cette conception n'est pas la plus conviviale, mais elle est très bénéfique pour contrôler l'impact sur l'entreprise. Notez que dans notre discussion précédente, même si l'entreprise définit des conditions de jugement à chaud et à froid, il existe toujours une certaine probabilité d'accès aux données compressées.Nous espérons que ce coût d'accès pourra avoir une limite supérieure déterministe.
La figure 2 montre le processus détaillé de la compression intra-bloc : premièrement, lorsque la compression est déclenchée, le système analyse toutes les lignes du bloc de données et reconnaît que R1 et R3 sont des données froides selon les conditions de jugement chaudes et froides spécifiées ( Figure 2(a )); ensuite, le système compresse R1 et R3 dans leur ensemble et stocke les données compressées dans le BCA du bloc de données (Figure 2(b)); si l'entreprise doit mettre à jour R1 plus tard, le système mettra à jour La dernière donnée génère une nouvelle copie R4, et marque que R1 dans le BCA a été supprimé (comme le montre la Figure 2©); enfin, lorsque le système a besoin de plus d'espace sur le bloc de données, il peut récupérer l'espace appartenant à R1 dans le BCA (Figure 2(d)).
Figure 2 : Compression intra-bloc
algorithme de compression
Sur la base des objectifs de conception, si nous examinons les indicateurs tridimensionnels du taux de compression, des performances de compression et des performances de décompression, nous avons réellement besoin d'un algorithme de compression capable de fournir un taux de compression raisonnable, des performances de compression raisonnables et des performances de décompression ultimes. C'est la base de la conception de notre algorithme de compression.
Nous avons d'abord testé l'utilisation directe de LZ4 pour la compression. LZ4 est actuellement connue comme une bibliothèque tripartite open source avec les meilleures performances de compression et de décompression. D'après les résultats de mesure réels, le taux de compression de LZ4 est relativement faible. Nous avons soigneusement analysé son principe d'algorithme. LZ4 est une implémentation basée sur l'algorithme LZ77. L'idée de l'algorithme LZ77 est très simple, c'est-à-dire que les données à compresser sont considérées comme un flux d'octets. L'algorithme part du courant position du flux d'octets et vers l'avant Trouvez la chaîne correspondante qui est la même que la position actuelle, puis utilisez la longueur de la chaîne correspondante et le décalage par rapport à la position actuelle pour représenter la chaîne correspondante, afin d'obtenir l'effet de compression . Du point de vue du principe de l'algorithme, l'algorithme LZ77 a un meilleur effet de compression pour les textes longs, mais pour un grand nombre de textes courts et de types numériques dans les données structurées, l'effet est limité, nos tests réels ont également vérifié ce point.
Ensuite, nous avons divisé l'algorithme de compression en deux couches : dans la première couche, nous avons encodé certains types numériques par colonnes, et nous avons choisi un encodage par différence simple, qui est suffisamment léger pour décompresser des champs spécifiques sans s'appuyer sur les valeurs d'autres champs ; dans la deuxième couche, nous appelons LZ4 pour compresser les données encodées. Notez que dans la première couche, nous encodons en fait par colonne et stockons par ligne, ce qui est très différent de l'implémentation générale dans l'industrie (encode et stocke par colonne). Le stockage par colonne sera plus convivial pour le taux de compression, mais la colonne Le stockage par colonne signifie que les données d'une même ligne seront dispersées dans différentes zones du BCA. Cette conception traditionnelle ne peut pas supporter la décompression partielle que nous espérons réaliser plus tard. Nous expliquerons ce problème plus en détail dans la conclusion.
Grâce à des mesures réelles, nous avons constaté que cette implémentation d'encodage de colonne + compression générale améliore efficacement le taux de compression et contrôle en même temps l'augmentation évidente de l'impact commercial, mais l'implémentation à deux couches est faiblement couplée, ce qui introduit beaucoup de surcharge supplémentaire . Par conséquent, après une pesée minutieuse, nous avons décidé d'abandonner LZ4 et de réimplémenter un algorithme de compression étroitement couplé entièrement basé sur l'algorithme LZ77.
Cela semblait être une tentative très risquée à l'époque. En fait, avant nous, aucune équipe de noyau de base de données n'aurait choisi d'implémenter un algorithme de compression général par elle-même. Mais à en juger par les avantages finaux, nous avons en fait ouvert une toute nouvelle porte. Lorsque la frontière entre l'encodage des colonnes et l'algorithme LZ77 est brisée, nous introduisons une série d'innovations d'optimisation. Compte tenu de l'espace, nous ne pouvons pas montrer tous les détails techniques. Ici, nous n'introduisons que deux petites optimisations :
La première optimisation est les limites de ligne intégrées. Nous avons constaté que lorsque le système adopte l'algorithme de compression à deux couches, nous devons également enregistrer la longueur codée de chaque ligne de données, car nous devons trouver la limite de chaque ligne après la décompression de l'algorithme LZ77, ce qui n'est pas un petit aérien. Afin d'éliminer ce surcoût, nous choisissons d'intégrer une marque de limite de ligne dans le format de codage LZ77.Cette marque n'occupe que 1 bit, et son surcoût est fortement réduit par rapport au schéma existant. Bien sûr, avec ce bit de marqueur occupé, la longueur maximale de la fenêtre de la recherche directe LZ77 est réduite de moitié, mais dans notre scénario, ce n'est pas un problème, car notre longueur de page typique n'est que de 8 Ko.
La deuxième optimisation est le codage court de 2 octets. Dans l'implémentation LZ4 d'origine, afin d'améliorer les performances de compression, le système utilise un codage sur 3 octets pour décrire une correspondance, ce qui signifie que la correspondance la plus courte que le système peut reconnaître est de 4 octets. Mais dans les données structurées, la correspondance sur 3 octets est très courante, reportez-vous à l'exemple suivant :
A = 1 … B = 2
Parmi eux, A et B sont deux champs entiers dans la même ligne de données, et leurs valeurs sont respectivement 1 et 2. Sur la base de l'ordre actuel des octets, la forme de stockage réelle de la ligne de données en mémoire est la suivante :
01 00 00 00 … 02 00 00 00
Faites attention à la partie marquée en rouge ci-dessus. Évidemment, il y a une correspondance de 3 octets, mais elle ne peut pas être reconnue par LZ4.
Nous résolvons ce problème en introduisant un code court supplémentaire de 2 octets dans l'algorithme LZ77.Le code court de 2 octets peut identifier une correspondance minimale de 3 octets, améliorant ainsi le taux de compression par rapport à LZ4.
Bien entendu, l'introduction de codes courts entraînera une surcharge supplémentaire : premièrement, les performances de compression diminueront dans une certaine mesure, car nous devons établir deux tables de hachage indépendantes. Heureusement, dans notre scénario, les performances de compression ultimes ne sont pas notre objectif. poursuivre ; deuxièmement, le codage sur 2 octets réduit la largeur en bits qui exprime la distance entre la chaîne correspondante et la chaîne correspondante, ce qui signifie que la correspondance sur 3 octets doit être plus proche pour être reconnue. Dans notre scénario, ce n'est pas un problème, car la longueur d'une ligne de données typique est suffisamment petite par rapport à cette limite.
évaluation des effets
Nous utilisons des tests TPCC standard pour évaluer l'impact commercial de l'activation de la fonctionnalité de compression du stockage OLTP. Le modèle TPCC contient un total de 9 tables, dont 3 tables de flux dont l'espace va croître dynamiquement. Parmi ces 3 tables, la table des détails de la commande (table de commande) a un ordre de grandeur supérieur à la croissance de l'espace que les autres tables, nous choisissez d'utiliser ce tableau Activez la compression. Sur la base de la sémantique métier de TPCC, une fois la livraison de chaque commande terminée, le statut de la commande passera à l'état terminé. La commande terminée ne sera pas modifiée, mais il y a toujours une certaine probabilité qu'elle soit interrogée. Sur la base de cette sémantique, nous choisissons le principe du jugement chaud et froid pour ne compresser que les commandes terminées.
Nous avons testé les valeurs de performances du système sans compression et avec compression, et les résultats sont présentés dans la figure 3 :
Figure 3 : Évaluation de l'impact sur les entreprises
Nous avons testé le taux de compression de la table Orderline.En tant qu'ensemble de données plus riche, nous avons également sélectionné quatre tables (Lineitem, Orders, Customer et Part tables) dans le modèle TPCH pour les tests. À titre de comparaison, pour chaque ensemble de données, nous avons testé les performances du taux de compression de LZ4, ZLIB et notre algorithme de compression en même temps. Parmi eux, ZLIB est un algorithme qui met l'accent sur les performances de compression et de décompression et l'équilibre du taux de compression, et sa compression et décompression les performances sont 5 fois inférieures à celles du LZ4.-10 fois. Le résultat final est illustré à la figure 4 :
Figure 4 : Évaluation du taux de compression
Conseils d'utilisation et d'entretien
Notez que notre schéma de compression est en fait hors ligne, c'est-à-dire que lorsque les données sont générées pour la première fois, il doit s'agir de données chaudes, elles ne déclencheront pas de compression et les performances de l'accès professionnel à ces données ne seront en aucune façon affectées ; au fil du temps par, la performance de ces données La température diminuera progressivement, et finalement elle sera reconnue comme des données froides par des tâches de compression indépendantes et compressées.
Le choix d'exécuter ces tâches de compression pendant les heures creuses et le contrôle de leur consommation de ressources sont des problèmes auxquels doivent prêter attention du côté de l'exploitation et de la maintenance. Dans ce domaine, nous fournissons une multitude de méthodes d'exploitation et de maintenance, notamment en spécifiant la fenêtre d'exploitation et de maintenance, le parallélisme des tâches de compression et la quantité de données compressées pour chaque tâche de compression. Pour la plupart des entreprises, la quantité de données nouvellement ajoutées par unité de temps est en fait relativement limitée, de sorte que l'entreprise peut également choisir une période spécifique pour effectuer la tâche de compression de manière intensive, par exemple de 2h00 à 4h00 le premier jour de chaque mois. point, terminer la compression des données froides ajoutées il y a 3 mois.
Avant qu'une entreprise ne décide d'activer la compression, elle peut souhaiter comprendre les avantages après l'activation de la compression et prendre une décision en fonction de l'ampleur des avantages. À cette fin, nous fournissons un outil d'évaluation du taux de compression, qui peut échantillonner les données de la table cible et utiliser le même algorithme que le processus de compression réel pour compresser les données échantillonnées et calculer le taux de compression, mais il ne générera pas réellement de BCA. et ne le modifiera aucune donnée.
Si l'entreprise migre des données compressées vers une autre table, toutes les données peuvent passer de compressées à non compressées, ce qui entraîne une expansion de l'espace. Ceci n'est pas introduit par notre solution, mais un problème que toutes les solutions de compression doivent résoudre. Si les règles de jugement à chaud et à froid sont très certaines, l'entreprise peut exécuter manuellement la tâche de compression pour que la compression prenne effet immédiatement ; pour la migration de tables compressées de grande capacité qui prend beaucoup de temps, l'entreprise peut toujours choisir de démarrer la tâche de compression automatique périodiquement pour terminer.
Enfin, nous fournissons le contrôle le plus précis pour activer et désactiver la compression. Qu'il s'agisse d'une partition unique dans une table commune, d'une table de partition commune ou de toute partition ou sous-partition unique dans une partition secondaire, l'entreprise peut être transformée on ou off indépendamment la compression. Cela permet aux scénarios où l'entreprise elle-même a différencié les données chaudes et froides (par exemple, sur la base du partitionnement temporel), cela peut toujours bien fonctionner avec notre fonction de compression.
conclusion
Dans la fonctionnalité de compression de table OLTP, nous avons introduit une série d'innovations technologiques, y compris de tout nouveaux algorithmes de compression, une détermination automatique à grain fin du chaud et du froid et une prise en charge de la compression intra-bloc, ce qui peut réduire considérablement l'impact sur la table tout en fournir un taux de compression raisonnable. Impact sur les entreprises, nous espérons que cette fonctionnalité pourra jouer un rôle important dans la prise en charge du contrôle de la capacité des services en ligne critiques.
Ensuite, nous continuerons à innover et à itérer pour réduire l'impact de l'introduction de la compression sur l'entreprise, des fonctionnalités de décompression partielle et de la compression d'index OLTP. Nous espérons avoir des percées technologiques révolutionnaires pour résoudre les problèmes connexes et créer une plus grande valeur pour l'entreprise.