Wie optimiert man die Nutzung von Zstandard- oder Brotli-Kompression bei der Kommunikation zwischen Scraper und Backend?

Die Optimierung der Kompression zwischen Scraper und Backend erfordert eine Analyse des Datenvolumens und der verfügbaren CPU-Ressourcen auf beiden Seiten. Während Brotli oft höhere Kompressionsraten bei statischen Texten erzielt, bietet Zstandard (zstd) eine überlegene Geschwindigkeit und Flexibilität für dynamische Datenströme.

Wir unterscheiden die beiden Algorithmen nach folgenden Kriterien:

Um die Effizienz zu steigern, setzen wir auf folgende technische Maßnahmen:

1. Dictionary-Training (Zstandard): Da Scraper oft repetitive JSON-Strukturen an das Backend senden, trainieren wir ein spezifisches Wörterbuch mit repräsentativen Datensätzen. Dieses Wörterbuch wird sowohl im Scraper als auch im Backend hinterlegt. Dadurch entfällt die Notwendigkeit, redundante Header-Informationen in jedem Paket erneut zu komprimieren, was die Kompressionsrate bei kleinen Payloads massiv steigert.
2. Anpassung der Kompressionslevel: Wir vermeiden maximale Kompressionsstufen, da diese die CPU-Last überproportional erhöhen, ohne den Bandbreitenvorteil signifikant zu verbessern. Für Zstandard wählen wir meist Level 3 bis 7; bei Brotli beschränken wir uns auf niedrigere Level, um Latenzen im Backend zu minimieren.
3. Streaming-Implementierung: Anstatt Payloads vollständig im Speicher zu puffern, nutzen wir Streaming-Kompression. Dies reduziert den Memory-Footprint des Scrapers und ermöglicht dem Backend die Verarbeitung der Daten, während sie noch eintreffen.

Im Rahmen unserer Projekte im Bereich Data Engineering integrieren wir diese Mechanismen direkt in die Transportlayer-Konfiguration, wobei die Aushandlung über den Content-Encoding Header erfolgt.

Für die Kommunikation zwischen Scraper und Backend empfehlen wir Zstandard gegenüber Brotli. Die Fähigkeit, eigene Wörterbücher zu trainieren, in Kombination mit der extrem schnellen Dekompressionsgeschwindigkeit, macht zstd zur technisch überlegenen Wahl für hochfrequente Datenübertragungen. Brotli ist für diesen spezifischen Anwendungsfall zu rechenintensiv in der Kompressionsphase und bietet keinen messbaren Vorteil bei der Paketgröße, sobald ein zstd-Wörterbuch implementiert ist.