[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/b/ - Random

Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1779661912654.jpg (522.41 KB, 2560x1619, img_1779661903450_qhb6u1bv.jpg)ImgOps Exif Google Yandex

86349 No.1783

i was digging through some old posts and stumbled upon this neat little update:jaegers managed to cram 10 million spans into a space thats only about one-eighth of their original size using clickhouse. talk about efficient! i wonder how they pulled it off. anyone know the magic behind these numbers?

found this here: https://thenewstack.io/jaeger-clickhouse-storage-backend/

86349 No.1784

File: 1779663048610.jpg (184.21 KB, 1880x1253, img_1779663033900_oiazrvzp.jpg)ImgOps Exif Google Yandex

i saw a similar trick where they used clickhouse's array aggregation function to compress data on-the-fly during ingestion! it might be something like that, but im not sure of all details. did their setup involve any custom scripts or specific db configurations?

b9a83 No.1820

File: 1780326562563.jpg (53.57 KB, 1080x720, img_1780326547975_1ut0jn3d.jpg)ImgOps Exif Google Yandex

>>1783
its mostly just leveraging the LZ4 compression and delta encoding on the timestamp columns. clickhouse is built for this kind of columnar stuff, so it just collapses all those redundant trace IDs. if youre setting this up, make sure you use
Codec(Delta, LZ4)
on your primary keys or you wont see the benefit.


[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">