Vlákno názorů k článku Srovnání linuxových kompresorů dat: různé kompresní poměry a rychlost od MaraOu - Ahoj, díky za inspiraci, ale ja to asi...

Ahoj, díky za inspiraci, ale ja to asi nechapu.

Vzdyt se porovnavaji hrusky z jablkama.
Na jedne strane mame tabulku s maximalni kompresi a na druhe strane s maximalni rychlosti. Nad slunce je ale jasne ze nejde mit oboje.

Teda bylo by treba k maximalni rychlosti komprese doplnit kompresni pomer.
A naopak k maximalnimu kompresnimu pomeru cas pro kompresi.

Jinak nejde nic rozhodnout. Ta nastaveni mezi softy jsou prece tak siroka a nekonzistentni.

Původně jsem tam měl i ty dvě tabulky, které Vám chybí, ale pak jsem je smazal, protože neměly smysl. Když někdo cílí na maximální kompresní poměr, logicky ho nezajímá rychlost (je jasné, že si bude muset dlouho počkat). Když naopak někdo cílí na rychlost komprese, nebude ho ani moc zajímat dosažený kompresní poměr (bude ho zajímat ta rychlost). Nicméně všechno by se dalo vynést do grafu závislosti kompresního poměru na rychlosti komprese. Já jsem zvolil tabulky, protože mně to přijde přehlednější (přece jenom nejlepší hodnotu zvýrazníte tučně a vypadá to dobře).

To si dovolim oponovat, kdyz jsme to neco nejen naposledy resili, tak vzdycky bylo zadani "kompresni pomer co nejlepsi pri takovem nastaveni, aby se ty zalohy stacily zabalit do dalsiho dne" (+samozrejme velka rezerva v sizingu na rostouci data, ...)
Pripadne k tomu primerena rychlost dekomprese.

(coz, mimochodem, vyradilo maximalni kompresi na xz - je fuk, jestli kazdodenni job bezi 10 minut nebo 2 hodiny, ale kdyz to vychazi na 25 hodin, tak se musi udelat kompromis)

Chápu. Příště udělám podobné srovnání s grafy. Něco jako zde.

Díky, to by moc pomohlo!

Ono je zajímavé oboje. Tak jak to je teď, tak v první tabulce je maximální výkon, ve druhé pak minimální cena. To je zajímavá informace. Pokud si člověk chce udělat ještě navíc představu o poměru cena/výkon, tak ale už nemá šanci.

Já bych se za to taky přimlouval (mimochodem i tak díky za článek!). Možná by bylo zajímavé i zahrnout polemiku o tom, jaký algoritmus je v praxi vhodný pro určité použití (např. zahrnout rychlost komprese vs. účinnost vs. rychlost dekomprese a podle různých vah těchto faktorů stanovit výsledné skóre). A třeba mě by i zajímala nějaká "zlatá střední cesta", řekněme ve smyslu algoritmus/kom­presní poměr/rychlost komprese/konkrétní nastavení daného nástroje, byť je asi hodně těžké něco takového rozumně definovat.

EDIT: A ještě dodatek - v článku je uvedeno, že testy byly prováděny s omezením na jedno vlákno, což určitě pro základní porovnání dává smysl. Na druhou stranu v době dnešních vícejádrových procesorů by bylo zajímavé do porovnání zahrnout i výkon při více vláknech.

21. 11. 2024, 12:49 editováno autorem komentáře

Diky moc, to je presne ono, co mi tolikrat chybelo a co spouste lidem usetri hodne casu a nervu. :-)

Určitě by bylo dobré si říct, jaká je nejlepší možná komprese při které výstup vytěžuje 100, 1000 či 10 000 Mbps linku na maximum a jaké je při tom vytížení procesorového jádra.

Zálohy jsou záludné ze dvou důvodů, řada systémů jede non-stop a kromě režie (do které zálohy spadají) dělají i užitečnou práci. On je dobrý důvod, proč ZFS standardně používá LZ4 a hodně adminů přechází na ZSTD. Kromě early abort při špatné kompresibilitě a vysoká rychlost a slušná učinnost hlavně u ZSTD z těchto algoritmů dělá dobré kandidáty na většinu nasazení, kde nejsme v nějaké krajní poloze (např. nějaké deep archive nasazení, nebo velká limitace propustností).

Když naopak někdo cílí na rychlost komprese, nebude ho ani moc zajímat dosažený kompresní poměr (bude ho zajímat ta rychlost).

Keď niekoho zaujíma len rýchlosť, tak bude predsa dáta ukladať bez kompresie.