>> Datenbank- und View-Index-Dateien lassen sich jetzt optional komprimieren. Infolgedessen können Daten schneller von der Festplatte gelesen und gespeichert werden.
Ich weiß ja nicht. Wenn ich komprimieren muss, dann schreiben bzw. lesen und dann dekomprimieren, amortisiert sich dann nicht der Performance-Gewinn von "weniger Daten müssen gelesen werden" in Relation zu "bei jeder atomaren Operation muss die CPU erstmal komprimieren/dekomprimieren"?
Ich hätte sogar erwartet, dass je schneller der HW-Datentransfer (z.B. SSD) desto langsamer wird es mit Komprimierung in Relation.
Was meint ihr? Schließlich ist ne Partition mit Dateisystem, wo die daten komprimiert werden auch langsamer als nicht-komprimiert im Durchschnitt. Bei richtig großen Files mag das anders sein, aber das sind doch statistische Ausnahmen? Und bei nem FS ist der Treiber im Kernel und bekommt so mehr Rechenzeit/höhere Prio und damit wäre es im Vergleich zum CouchDB-Dienst der komprimierung auf App-Level macht ja auch noch schneller?!
Meiner Meinugn nach setzt man Komprimierung doch eigl. nur bei Netzwerk-Traffic ein um Payload zu verkleinern und so richtig performance zu sparen oder wenn HDD-Space zu teuer wird? Aber hier ist ja die Rede von Datafile-Komprimierung und nicht von Netzwerk-Payload?! (wäre ja durch HTTP mit gz/deflate eh komprimiert...) ?!
Die Kompression mit extrem schnellen Verfahren wie LZO, Snappy und erst recht LZ4 scheint selbst bei SSDs noch Vorteile zu bringen. In Btrfs wird mit diesen Kompressionstechniken rumexperimentiert (zumindest LZO ist schon im offiziellen Kernel): http://www.phoronix.com/scan.php?page=article&item=linux_btrfs_options&num=1
Wenn man sieht, dass LZ4 zumindest bei der Dekompression schon mit einem Core mehr als 1000 MB/s schafft und der Durchsatz auch von Top-SSDs sich "nur" im dreistelligen Bereich bewegt, ist das ja auch verständlich.
Ich kann mir eigentlich auch nicht vorstellen, das Komprimieren/Dekomprimieren heute beim Thema Rechenzeit ein Problem darstellt, haben heutige Fileserver doch eher zu viel als zu wenig Rechenleistung.
In der ersten Stunde jeder Volesung zum Thema Datenbankimplementierungstechniken bekommst du immer zu hören: Der Flaschenhals bei Datenbanken ist IMMER I/O. Erhöhst du die Datenrate, steigerst du damit auch die Geschwindigkeit. Nebenbei können spez. Controller die lästige Kompressionseinbußen kompensieren.
>> Datenbank- und View-Index-Dateien lassen sich jetzt optional komprimieren. Infolgedessen können Daten schneller von der Festplatte gelesen und gespeichert werden.
Ich weiß ja nicht. Wenn ich komprimieren muss, dann schreiben bzw. lesen und dann dekomprimieren, amortisiert sich dann nicht der Performance-Gewinn von "weniger Daten müssen gelesen werden" in Relation zu "bei jeder atomaren Operation muss die CPU erstmal komprimieren/dekomprimieren"?
Ich hätte sogar erwartet, dass je schneller der HW-Datentransfer (z.B. SSD) desto langsamer wird es mit Komprimierung in Relation.
Was meint ihr? Schließlich ist ne Partition mit Dateisystem, wo die daten komprimiert werden auch langsamer als nicht-komprimiert im Durchschnitt. Bei richtig großen Files mag das anders sein, aber das sind doch statistische Ausnahmen? Und bei nem FS ist der Treiber im Kernel und bekommt so mehr Rechenzeit/höhere Prio und damit wäre es im Vergleich zum CouchDB-Dienst der komprimierung auf App-Level macht ja auch noch schneller?!
Meiner Meinugn nach setzt man Komprimierung doch eigl. nur bei Netzwerk-Traffic ein um Payload zu verkleinern und so richtig performance zu sparen oder wenn HDD-Space zu teuer wird? Aber hier ist ja die Rede von Datafile-Komprimierung und nicht von Netzwerk-Payload?! (wäre ja durch HTTP mit gz/deflate eh komprimiert...) ?!
Ich denke auch mit SSDs bringt das nichts. Deshalb ists es wohl auch optional.
Die Kompression mit extrem schnellen Verfahren wie LZO, Snappy und erst recht LZ4 scheint selbst bei SSDs noch Vorteile zu bringen. In Btrfs wird mit diesen Kompressionstechniken rumexperimentiert (zumindest LZO ist schon im offiziellen Kernel):
http://www.phoronix.com/scan.php?page=article&item=linux_btrfs_options&num=1
Wenn man sieht, dass LZ4 zumindest bei der Dekompression schon mit einem Core mehr als 1000 MB/s schafft und der Durchsatz auch von Top-SSDs sich "nur" im dreistelligen Bereich bewegt, ist das ja auch verständlich.
Ich kann mir eigentlich auch nicht vorstellen, das Komprimieren/Dekomprimieren heute beim Thema Rechenzeit ein Problem darstellt, haben heutige Fileserver doch eher zu viel als zu wenig Rechenleistung.
In der ersten Stunde jeder Volesung zum Thema Datenbankimplementierungstechniken bekommst du immer zu hören: Der Flaschenhals bei Datenbanken ist IMMER I/O. Erhöhst du die Datenrate, steigerst du damit auch die Geschwindigkeit. Nebenbei können spez. Controller die lästige Kompressionseinbußen kompensieren.