So aktivieren Sie die transparente Datenkomprimierung auf MinIO

Die meisten Daten werden in leicht lesbaren Dateiformaten gespeichert, um eine einfache Anwendungsinteroperabilität zu gewährleisten. Während es weit verbreitete Formate für die Bild-, Video- und Tonkomprimierung gibt, werden die meisten anderen Daten als Text, als JSON, CSV oder andere ähnliche textbasierte Formate gespeichert.

Formate wie Parquet, Avro und ORC verfügen über eine optionale Komprimierung, sodass diese Formate normalerweise bereits beim Speichern komprimiert sind. Videos und Bilder werden in der Regel auch mit domänenspezifischen Algorithmen komprimiert, die eine bessere Komprimierung als generische Formate bieten.

Bei benutzerdefinierten Daten ist es jedoch vorzuziehen, die Daten in einem unkomplizierten Format aufzubewahren, das keinen Dekomprimierungsschritt für den Zugriff enthält. Wir möchten eine Option anbieten, diese Daten zu komprimieren, bevor sie auf Datenträgern gespeichert werden.

Transparente Komprimierung mit IO-Geschwindigkeit

Die Komprimierung für MinIO wurde entwickelt, um eine transparente Komprimierung zu ermöglichen, ohne die Gesamtleistung des Systems zu beeinträchtigen.

MinIO verwendet eine auf Snappy basierende Komprimierungsmethode namens S2. Es ist mit Snappy-Inhalten kompatibel, verfügt jedoch über zwei Formaterweiterungen . Erstens erlaubt es größere Blöcke als die 64-KB-Blöcke, die für Snappy-Streams zulässig sind. Dadurch wird die Komprimierung erheblich verbessert. Zweitens werden „Wiederholungsoffsets“ hinzugefügt, die Komprimierungsverbesserungen hauptsächlich für maschinengenerierte Daten wie Protokolldateien, JSON und CSV bieten. Es ermöglicht auch die effektive Codierung von Übereinstimmungen, die länger als 64 Bytes sind, was für Snappy ein Problem darstellt.

S2 ermöglicht auch die gleichzeitige Komprimierung mehrerer Blöcke, wenn die Eingabe schneller ist als das, was ein einzelner Kern aufnehmen kann. Dies ist wichtig, um die Reaktionsfähigkeit auf einzelne Anfragen aufrechtzuerhalten. Bei mehr als 16 Kernen liegt die Einschränkung tatsächlich in der Speichergeschwindigkeit.

Komprimierungsverhältnisse

Einige Appliance-Anbieter versprechen bei der Berechnung der Kosten pro TB ein bestimmtes Komprimierungsverhältnis oder gehen sogar davon aus. Bei der Komprimierung gibt es kein garantiertes Verhältnis über 1:1. Unterschiedliche Datentypen führen zu unterschiedlichen Komprimierungsraten, und unserer Meinung nach gibt es keine sinnvolle Möglichkeit, eine durchschnittliche Komprimierungsrate bereitzustellen. Komprimierungsverhältnisse sollten niemals im Vakuum bewertet werden – sie sollten immer mit der Komprimierungsgeschwindigkeit gepaart werden, da die praktische Komprimierung ein Kompromiss zwischen diesen beiden Faktoren ist.

Vergleichen wir einen einzelnen Datentyp, um die Unterschiede zu beobachten. Wir vergleichen Go-Implementierungen dieser Algorithmen auf einer AMD64-Plattform mit bis zu 16 Kernen.

Erstens ist die horizontale Achse ein abgeschnittenes Komprimierungsverhältnis, eine Reduzierung, die gegenüber der unkomprimierten Größe erreicht wird. Richtig ist besser. Als Referenz wurde die Single-Threaded-GZIP-Version 5 hinzugefügt.

Die Dekomprimierungsgeschwindigkeit nutzt einen einzelnen Kern, obwohl S2 eine gleichzeitige Dekomprimierung bietet.

Bei diesen Daten liegt Snappy etwa 10 % unter der Gzip-Referenz. Da es sich um Reduzierungsprozentsätze handelt, bedeutet dies auch, dass Snappy etwa das 1,6-fache des Speicherplatzes der mit Gzip komprimierten Daten einnimmt. Dies ignoriert die Tatsache, dass Snappy etwa viermal schneller dekomprimiert als Gzip.

LZ4 gilt typischerweise als überlegen gegenüber Snappy. Eine Implementierung von LZ4, die eine Komprimierung auf mehreren Kernen ermöglicht, macht diesen Punkt ebenfalls klarer. Aber die Basiskomprimierung ist besser. Der LZ4 Best, manchmal auch als LZ4-HC bezeichnet, bietet eine Komprimierung nahe an gzip, aber obwohl die Dekomprimierung schnell ist, erfolgt die Komprimierung nicht mit interaktiver Geschwindigkeit.

S2 bietet drei Komprimierungsstufen; S2 Default ist die schnellste Lösung und kann hinsichtlich der Single-Core-Nutzung als direkter Konkurrent von Snappy angesehen werden. Mit diesem Datentyp ist die Leistung besser als bei jedem LZ4-Level und der Durchsatz ist deutlich höher. Dieser Modus wird von MinIO für Plattformen verwendet, auf denen keine Assembly-Implementierung verfügbar ist.

S2 Better ermöglicht den Tausch von etwas CPU gegen eine höhere Komprimierung. Hier konkurriert die Komprimierung mit Gzip, aber die Dekomprimierungsgeschwindigkeit ist um einiges besser. Dieser Modus wird von MinIO auf Plattformen verwendet, auf denen Assembly verfügbar ist – derzeit AMD64.

S2 Best ist die beste Komprimierung, die S2 mit dem aktuellen Format erreichen kann. Dies kann in Situationen verwendet werden, in denen Komprimierungsgeschwindigkeit/Ressourcen nicht das Wichtigste sind, aber dennoch eine schnelle Dekomprimierung erforderlich ist. Derzeit verwendet MinIO diesen Modus nicht, implementiert ihn jedoch möglicherweise als Lebenszyklusoption für Objekte, die sich seit einiger Zeit nicht geändert haben.

Zum Vergleich hier ein paar Vergleiche anderer Datentypen:

Inkompressible Objekte

Ein wichtiges Merkmal der modernen Komprimierung besteht darin, dass sie sich gut mit vorkomprimierten Daten verhält. Traditionell waren vorkomprimierte Daten ein Problem für Komprimierungsalgorithmen. Oftmals verlangsamten sich Kompressoren unangemessen, wenn sie mit inkompressiblen Daten konfrontiert wurden.

Viele Menschen wissen daher instinktiv, dass es schlecht ist, bereits komprimierte Daten erneut zu komprimieren. Allerdings sind viele moderne Implementierungen mittlerweile einigermaßen in der Lage, inkompressible Abschnitte schnell zu überspringen.

Für die oben genannten Kompressoren sind dies die Geschwindigkeiten für inkomprimierbare 2GiB-Daten (2.147.483.647 Bytes):

Als Vertreter dieses „schlechten“ Verhaltens haben wir hier auch gzip aus der Go-Standardbibliothek eingebunden. Eine alternative gzip-Implementierung zeigt dieses Problem nicht. In allen anderen Fällen werden die Inhalte recht schnell verarbeitet und sie erhalten einen Pass.

Das bedeutet, dass MinIO voraussichtlich gut mit vorkomprimierten Daten umgehen kann.

Suche nach komprimierten Dateien

Ein typischer Nachteil der Komprimierung besteht darin, dass die Möglichkeit zum Überspringen innerhalb einer Datei verloren geht. Die Lösung hierfür besteht darin, Blöcke unabhängig voneinander zu komprimieren und einen Index beizubehalten, der eine Reihe unkomprimierter Offsets komprimierten Offsets zuordnet, an denen die Dekomprimierung beginnen kann.

Durch das Komprimieren unabhängiger Blöcke wird die Komprimierung leicht reduziert, bei größeren Blöcken jedoch weniger. Snappy/S2 komprimiert Streams von Natur aus als unabhängige Blöcke.

Für MinIO ist dies relevant, da S3-GetObject-Anfragen optional abzurufende Bereiche enthalten können. Dies ermöglicht das Abrufen von Teilen von Objekten, und wir möchten, dass dies so effizient wie möglich ist.

Ab RELEASE.2022-07-13T23-29-44Z generieren wir nun einen Index für jeden hochgeladenen Dateiteil, der größer als 8 MB ist. Der Index wird dann intern an die Metadaten angehängt. Dadurch können wir effektiv vorwärts springen und nur den Teil des Objekts dekodieren, der für die Rückgabe der angeforderten Daten erforderlich ist.

Der Index beträgt typischerweise 16 Byte + etwa 3 Byte pro MB Daten. Dadurch kann MinIO jedes Byte aus einer komprimierten Datei mit der gleichen Geschwindigkeit bereitstellen wie das erste Byte.

Komprimierung + Verschlüsselung im Ruhezustand

Standardmäßig ist für MinIO ein zusätzlicher Parameter erforderlich, um die zu verschlüsselnden Daten auf der Festplatte zu komprimieren. Damit soll sichergestellt werden, dass Sie sich der Auswirkungen bewusst sind.

Beim Komprimieren von Daten erhalten Sie zwei Zahlen; die unkomprimierte und die komprimierte Größe. Ohne Komprimierung kann jeder, der Ihre Daten erhält, nur eine davon sehen – die unkomprimierte Größe.

Dadurch erhalten Sie zwar immer noch keinen Zugriff auf Daten in der komprimierten Datei, es werden jedoch einige Hinweise auf die Daten gegeben. Es kann Ihnen einige Arten von Daten mitteilen, die es unmöglich sein kann. Wenn Sie eine um 50 % komprimierte Datei sehen, ist es äußerst unwahrscheinlich, dass sie MP4-komprimiertes Video enthält.

Ebenso enthält eine auf nur wenige Bytes komprimierte Datei wahrscheinlich eine sehr einfache wiederholte Sequenz. Es ist nicht möglich, die Reihenfolge zu bestimmen, aber es schränkt die Möglichkeiten ein. MinIO aus RELEASE.2022-07-13T23-29-44Z füllt die komprimierte Ausgabe auf ein Vielfaches von 256 Bytes auf. Diese Polsterung ist nirgendwo aufgezeichnet. Wir betrachten dies nicht als vollständige Lösung des Problems, aber es verringert den Nutzen der durchgesickerten Größeninformationen für Angreifer erheblich.

Dies ist der Hauptgrund dafür, dass MinIO keine Informationen über die komprimierten Größen an Clients zurückgibt. Daher würde jede diesbezügliche Information Zugriff auf den Backend-Speicher oder die Backend-Netzwerkkommunikation erfordern.

Mit diesen Informationen verfügen Sie nun über genügend Wissen, um festzustellen, ob Sie es für sicher halten, Komprimierung und Verschlüsselung zu aktivieren.

Angriffe im CRIME -Stil sind auf MinIO nicht möglich, da wir keine Änderungen oder Anhänge an komprimierte Streams zulassen. Wir deduplizieren/komprimieren auch nicht über mehrere Objektversionen hinweg, da dadurch zu viele Informationen über Dateien verloren gehen würden.

Komprimierung in MinIO konfigurieren

Standardmäßig ist die Komprimierung auf der Festplatte in MinIO deaktiviert. Die Komprimierung auf der Festplatte kann jederzeit aktiviert oder deaktiviert werden. Um die Komprimierung auf der Festplatte zu aktivieren, verwenden Sie mc admin config set myminio compression enable=on .

Dadurch wird die Komprimierung für eine voreingestellte Anzahl von Erweiterungen und MIME-Typen aktiviert. Standardmäßig umfassen diese Folgendes:

Sie können die aktuellen Einstellungen mit mc admin config get myminio compression überprüfen.

Sie können diese Liste jederzeit ändern, indem Sie Folgendes ändern:

 mc admin config set myminio compression \ extensions=.txt,.log,.csv,.json,.tar,.xml,.bin \ mime_types=text/*,application/json,application/xml,binary/octet-stream

Standardmäßig schließt MinIO Erweiterungen häufig inkomprimierbarer Daten wie GZIP-, Audio-, Video- und Bilddateien zwangsweise aus.

Es ist möglich, die Komprimierung für alle Objekte außer den ausgeschlossenen zu aktivieren, indem Sie die Erweiterungsliste und die MIME-Typen auf leer setzen:

 mc admin config set myminio compression enable=on extensions= mime_types=

Die letzte Einstellung ist allow_encryption=on , die die Komprimierung auch für zu verschlüsselnde Objekte ermöglicht. Stellen Sie dies nur ein, wenn Sie den obigen Abschnitt gelesen haben und die Auswirkungen verstehen.

Abschluss

MinIO bietet das beste Komprimierungsschema seiner Klasse, das eine vollständig transparente Komprimierung von Daten auf der Festplatte ermöglicht. Dies kann in vielen Szenarien zu einer Reduzierung der Speicherkosten führen, indem einfach die Komprimierung aktiviert wird.

Die GET- und PUT-Leistung sollte in allen Fällen nahezu gleich bleiben, wenn die Komprimierung aktiviert ist. In Situationen, in denen die Leistung durch die Lesegeschwindigkeit der Festplatte begrenzt ist, kann die Komprimierung tatsächlich eine zusätzliche Leistung bieten, da weniger Daten gelesen werden müssen.

Wir werden weiterhin neue Funktionen hinzufügen. Wir evaluieren derzeit Konfigurationsoptionen auf Bucket-/Präfixebene sowie die Komprimierung über den Lebenszyklus, mit der Dateien komprimiert werden, wenn sie ein bestimmtes Alter erreichen.

Wenn Sie an diesen Funktionen interessiert sind, laden Sie MinIO herunter und probieren Sie es selbst aus. Wenn Sie Fragen haben oder uns etwas über die großartigen Apps erzählen möchten, die Sie mit MinIO erstellen, senden Sie uns einen Pin an [email protected] , treten Sie der Slack-Community bei, folgen Sie unserem Blog oder abonnieren Sie unseren Newsletter.