Snappy 1.2: Googles Kompressionsbibliothek, ein Durchsatzmonster mit 250MB pro Sekunde

Zusammenfassung

Snappy jagt nicht der kleinsten Ausgabe nach, sondern dem Tempo: mehr als 250MB pro Sekunde beim Komprimieren und ueber 500MB pro Sekunde beim Dekomprimieren auf einem gewoehnlichen Kern, zum Preis einer Ausgabe, die zwanzig Prozent bis doppelt so gross ist. Dieser Tausch ist der Grund, warum sie unter Datenbanken, Grossdatensystemen und Protokollpipelines sitzt.

Empfehlen
Name
Snappy
Version
1.2.2
Open Source
Open Source
Betriebssystem
WindowsmacOSLinux
Aktualisiert
2026-10-05 09:46

Es geht nicht um die kleinste Datei, sondern um ein absurd hohes Tempo

Beim Komprimieren gibt es meist einen Tausch: je kleiner die Ausgabe, desto mehr Arbeit. Snappy, die quelloffene Bibliothek, die Google unter einer Lizenz im BSD-Stil veroeffentlicht, geht bewusst den anderen Weg. Sie jagt nicht dem hoechsten Verhaeltnis nach, sondern einem Durchsatz, der fast unvernuenftig ist: auf einem einzelnen Kern eines gewoehnlichen Desktop-Prozessors komprimiert sie mit mehr als 250MB pro Sekunde und dekomprimiert mit mehr als 500MB pro Sekunde, rund eine Groessenordnung schneller als der schnellste Modus einer traditionellen Kompressionsbibliothek, und der Preis ist eine Ausgabe, die zwanzig Prozent bis doppelt so gross ausfaellt. Dieser Tausch laesst sie ueberall gluehen, wo Kompression das Geschaeft nicht bremsen darf: Datenbankspeicher, grosse Datensysteme, Protokollpipelines und die Kompressionsschicht unter einer ganzen Reihe bekannter verteilter Systeme. Stand September 2026 ist sie bei 1.2.2.

Woher das Tempo kommt

Das Tempo ist nicht das Ergebnis handgeschriebener Assembler-Magie, sondern zweier bewusster Entscheidungen, einer im Algorithmus und einer in der Umsetzung. Die Kompressionsstrategie ist einfach und direkt: sie sucht nur in nahen Daten nach wiederholten Fragmenten, was die Rechenkosten komplizierter Modellierung vermeidet. Die Umsetzung ist dafuer hart auf die gaengigen 64-Bit-Prozessoren optimiert und verarbeitet mehr Daten pro Operation. Hoher Durchsatz ohne eine Zeile Assembler bedeutet zugleich, dass Portabilitaet und Wartbarkeit erhalten bleiben, weshalb das Verhalten ueber Plattformen hinweg stabil ist. Ein Messwerkzeug liegt dem Projekt bei, ein Durchlauf mit den eigenen Daten vor dem Einbau sagt also, welche Geschwindigkeit und welches Verhaeltnis zu erwarten sind.

Stabilitaet aus dem Produktivbetrieb

Die Zuverlaessigkeit hat eine echte Vorgeschichte: seit Jahren komprimiert die Bibliothek bei Google Daten in Petabyte-Groessenordnung, das Bitstromformat ist stabil geblieben, und dass die Kompatibilitaet zwischen Versionen bricht, muessen Nutzer nicht befuerchten. Der Dekomprimierer ist sorgfaeltig gebaut und stuerzt auch bei beschaedigten oder absichtlich boshaft geformten Eingaben nicht ab, was fuer einen Dienst mit nicht vertrauenswuerdigen Daten sehr viel bedeutet. Die Bibliothek ist unter einer Lizenz im BSD-Stil offen, kommerzielle Nutzung kostet also nichts; sie ist in C++ geschrieben und bietet eine C-Schnittstelle, und fuer die meisten Sprachen gibt es ausgereifte Bindungen Dritter, sodass der Einbau in ein Projekt nicht schwerfaellt.

Wer sie benutzt, und warum diese

Sie taucht als Standard- oder Wahlmoeglichkeit zur Kompression in einer ganzen Reihe gaengiger Datenbanken und Grossdatenkomponenten auf: spaltenorientierte Speicher lassen sie auf Datenbloecken arbeiten, Nachrichtensysteme auf dem Netzwerkverkehr, eingebettete Speicher auf Dateien, die auf die Platte gehen. Gemeinsam ist diesen Systemen haeufiges Lesen und Schreiben plus Empfindlichkeit gegen Verzoegerung, wo jede zusaetzliche Millisekunde beim Komprimieren zu einem Leistungsproblem wird; genau dieser Anspruch an eine Kompression, die auch schnell ist, hat den Entwurf gepraegt. Fuer einen einzelnen Entwickler, der einem Speicherprojekt, einem Protokollwerkzeug oder einem Netzwerkprotokoll eine Kompressionsschicht hinzufuegt, ist sie ausserdem die Wahl mit den niedrigsten Einstiegskosten und der klarsten Dokumentation, Quelle und Formathinweise sind oeffentlich.

Wann man sie nimmt, und wann nicht

Die Probe ist einfach. Wo die Menge gross ist, der Durchsatz weh tut und Speicherkosten vertretbar sind, gehoert sie zu den besten Antworten, mit typischen Verhaeltnissen um 1,5 bis 1,7 fuer Text und 2 bis 4 fuer webartige Inhalte; bereits komprimierte Daten wie Bilder und Video werden nicht noch einmal verarbeitet. Geht es dagegen um die kleinstmoegliche Groesse, etwa bei der Archivierung oder ueber teure Bandbreite, ist ein Algorithmus mit hoeherem Verhaeltnis die richtige Wahl. Die Bauabhaengigkeiten sind einfach genug fuer eine Standardwerkzeugkette, und dem Projekt liegen Werkzeuge fuer Messung und Korrektheit bei, was Abstimmung und Pruefung unkompliziert macht. Fuer ein Team, das seinen eigenen Speicher- und Transportweg baut, ist diese kleine und ziemlich harte Bibliothek einen Platz wert.

SnappyDownload
Unterstützte Systeme: Windows macOS Linux