Vergleich der Komprimierungsbibliotheken für JavaVM
Mehrere Bibliotheken wurden gesammelt und für die Auswahl reversibler Komprimierungsalgorithmen in JavaVM verglichen (Quellen und Zahlen unter github). Infolgedessen ist meine persönliche Wahrnehmung des Komprimierungsalgorithmus wie folgt.
| Algorithmus | Art | Anwendungen, die geeignet erscheinen |
|---|---|---|
| Zstandard | Hohe Kompressionsrate/Typ mit niedriger Verarbeitungsgeschwindigkeit | Dateibasierte Datenspeicherung und Übertragung zwischen Servern |
| lz4>Snappy | Niedrige Kompressionsrate/Typ mit hoher Verarbeitungsgeschwindigkeit | Hoher Durchsatz wie Streaming-Verarbeitung/Phasen, die eine geringe Latenz erfordern |
| bzip2 |
Komprimierungsrate höchste Priorität | Verteilung großer Datenmengen und Speicherung kalter Daten |
| gzip |
Portabilität hat höchste Priorität | Datenübertragung und Langzeitspeicherung |
Zusätzlich zum Java-Standard GZIP und Deflate (ZIP) haben wir eine Bibliothek verwendet, die die folgenden Algorithmen implementiert. Siehe build.sbt am Ende der Seite für jede Maven-Repository-ID.
- ** Zstandard **: Das Komprimierungsverhältnis ist größer oder gleich gzip und kleiner als bzip2, aber deutlich schneller als diese. Ganz zu schweigen vom vorhandenen gzip, bzip2 ist auch eine Berücksichtigung von Zstd wert, es sei denn, der Größenunterschied von einigen Prozent springt zu den Geschäftskosten. Nach Stufe einstellbar.
- ** lz4 **: Entspricht Snappy im Komprimierungsverhältnis und ist hinsichtlich der Geschwindigkeit vorteilhafter als Snappy, daher ist lz4 für die Priorität der Verarbeitungsgeschwindigkeit.
- ** Brotl i **: Selbst bei hohen Kompressionsraten kann es eines der besten sein. Der Unterschied zwischen Komprimierungs- und Dekomprimierungsgeschwindigkeit ist groß, und die Dekomprimierungsgeschwindigkeit ist schlechter als Zstd, jedoch schneller als gzip und bzip2. Durch die Verwendung des UTF-8-Modus wird die Textkomprimierung effizienter (unbestätigt).
- ** Bissig **: Hochgeschwindigkeitstyp, aber in Bezug auf die Geschwindigkeit schlechter als lz4, daher scheint es keine bestimmte Kurve zu geben. Ich verstehe, dass es eine Übertragungsmethode ist, wenn lz4 aus irgendeinem Grund nicht verwendet werden kann.
In den folgenden Benchmarks ist Block die Geschwindigkeit bei Verwendung der von jeder Bibliothek bereitgestellten API "byte []" bis "byte []" und Stream die Geschwindigkeit bei Verwendung des Standard-InputStream / OutputStream in Java. Das Ergebnis.
Textdatenkomprimierung
Die erste Beispielbinärdatei ist die US-Unabhängigkeitserklärung (http://memory.loc.gov/cgi-bin/query/r?ammem/bdsdcc:@field%28DOCID+@lit%28bdsdcc02101%29%29). Das Ergebnis der Komprimierungsverarbeitung. Da es sich um US-ASCII handelt, liegen alle Bytewerte innerhalb von 0x00-0x7F und die Entropie ist niedrig. Brotli hatte das höchste Kompressionsverhältnis und lz4 hatte die höchste Verarbeitungsgeschwindigkeit.
Das Folgende ist das Ergebnis der Verwendung des vollständigen Textes von Soseki Natsume "Kokoro" als Beispiel. Die japanische UTF-8-Darstellung hat ein höheres Komprimierungsverhältnis als das us-ascii-Dokument, da jedes Zeichen 3 Byte groß und das Muster redundant ist.
In Bezug auf Textdaten werden die Eigenschaften des Typs mit hoher Komprimierungsrate und des Typs mit hoher Geschwindigkeit klar gezeigt. Brotli scheint einen UTF-8-Optimierungsmodus zu haben, aber dieser Benchmark verwendet den GENERAL-Modus zum Vergleich mit dem Binärtyp.
Komprimierung numerischer Daten
Die folgende Abbildung zeigt eine Stichprobe von "int []", die mit der normalen Zufallszahl $ \ lfloor {\ rm Norm (\ mu = 0, \ sigma ^ 2 = 100)} \ rfloor $ initialisiert und mit Big Endian byteweise angeordnet wurde. Binär. Das heißt, 68% aller Array-Elemente liegen im Bereich von $ \ pm 10 $ und 95% im Bereich von $ \ pm 20 $. Mit anderen Worten, die meisten Werte sind Byte-Arrays, bei denen die 3 Bytes ohne das niedrigstwertige 1-Byte "0x00" oder "0xFF" sind.
Das Komprimierungsverhältnis solcher Binärdateien ist hoch, und der Typ mit hohem Komprimierungsverhältnis weist eine Verringerung von etwa 70 bis 80% auf. Da außerdem der Unterschied zum Hochgeschwindigkeitstyp in Bezug auf die Geschwindigkeit verringert wird, wird die Überlegenheit des Hochgeschwindigkeitstyps verringert.
Die folgende Abbildung zeigt eine komprimierte Stichprobe von "double []", die einen Wert mit der normalen Standardzufallszahl $ {\ rm Norm (\ mu = 0, \ sigma ^ 2 = 1)} $ im Byte-Array im IEEE 754-Format generiert hat. .. Bei Gleitkommadaten war der Komprimierungseffekt selbst bei einem Typ mit hohem Komprimierungsverhältnis mit weniger als 5% nahezu unvorhersehbar. Tatsächlich ist die Entropie der Abtastbinärdatei ebenfalls hoch, und es scheint, dass das Bytearray nahe an dem Fall liegt, in dem jeder Bytewert durch eine einheitliche Zufallszahl erzeugt wird.
Der negative Wert von lz4 zeigt an, dass die Größe leicht zugenommen hat.