А фб гориллу выложили же или мне приснилось?

выложил

А фб гориллу выложили же или мне приснилось?

https://github.com/facebookincubator/beringei

Пробовал кто?

я собрать не смог (

Пробовал кто?

находка для хакерс плана да ;) ?

Ой нет

Мы своё всегда

На сжатие интересно посмотреть

вы свой сторадж пишите ?

все пишут свой сторадж :)

рано или поздно :)

/me окинул взглядом свой коннектор к Whisper на C++ на 3к строк

"Beringei is a high performance, in-memory storage engine for time series data."

судя по описанию, там нет персистенси вообще

судя по описанию, там нет персистенси вообще

нету, но если делать сторадж с tire'ами то оно пойдет как первый tire

а с таким раскладом можно выставить std::unordered_map и сходу получить 20m qps:)

а с таким раскладом можно выставить std::unordered_map и сходу получить 20m qps:)

вопрос в сжатии

а заче на первом тиере сжатие?

а заче на первом тиере сжатие?

ну вот у нас 2.5М точек в секунду, хранить например сутки в оперативке - это мягко говоря дорого

вы свой сторадж пишите ?

А как быть? Требования же у все свои

zram есть :)

тупо сжать озу) быстро и сердито)

есть еще tmpfs со сжатием, AFAIK

тупо сжать озу) быстро и сердито)

специализированное сжатие может быть быстрее

и даже лучше

Z на рандмных float'ах мало дает и долго

О!)

2.5 точек в секунду это мало же

2.5 точек в секунду это мало же

2.5 млн )

2.5 точек в секунду это мало же

это много.

2.5 точек в секунду это мало же

это к сожалению очень много, если тупо брать по 64 бита на точку (без таймстемпа) это будет 1.6ТБ )

ну требования своих, вообще задача TSDB бьется в те же самые траблы, что задача поиска "оптимального" хэша под задачи :)

без сжатия

вообще очевидно что 2,5 милионна точек в секунду это мало.

если будет просто запихнуть больше - запихнут больше :(

для сбора в реалтайме информации о небольшом городе скажем в 300к людей это _не так много метрик на человека_

о каждом узле в интернете веселее :)

поверь мне. про людей точно веселее.

да даже банально о каждом инстансе приложения если начать собирать много параметров будет уже весело )

я время от времени дополняю вот эту страничку https://github.com/pavel-odintsov/fastnetmon/wiki/Traffic-Counters-Structures-performance-evaluation

ибо in-memory TSDB у меня внутри приложения и работает оно оч быстро

но проблемы - те же, просто масштаб меньше и кое-что решается намного проще

@pavel_odintsov имея жирную in-memory базу на 48 часов данных можно начать строить всякие корреляции интересные

например

и еще веселее если умудриться впихнуть неделю данных

у меня к счастью все проще, мне хватает последнего поулчаса, часто - меньше

данные старее - тупо не нужны

у меня к счастью все проще, мне хватает последнего поулчаса, часто - меньше

у нас 60% запросов идут за 24 часа

трафик-с.

ну тогда да, другой вопрос

где-то 30% запросов за последние 7 дней

и 10% все остальное

правда это по тем запросам где явно прописано

по тем где неявно надо еще подумать как посчитать правильно

но-таки самый простой вариант, когда память у приложения локальная

пусть да же SHM

модифицировать приложение сложно (

тот же графит просто убожественно кодирует данные

особенно если не ты пишешь

pickle - вариант, но под него нет ничего нормального для С

а все text based это оч плохо, сначала тратишь ресурсы чтобы в текст загнать, потом чтобы выгнать %)

моя мечта - tsdb с поддержкой capnp :)

у нас 60% запросов идут за 24 часа

Зачем тау

а все text based это оч плохо, сначала тратишь ресурсы чтобы в текст загнать, потом чтобы выгнать %)

у нас в read pipeline'е протобуф )

*так

протобаф. сочувствую.

ERROR: S client not available

Зачем тау

я не знаю, людям нравится (

протобаф. сочувствую.

почему?

потому что куча аллокации памяти на стеке и куча копирований памяти :)

потому что куча аллокации памяти на стеке и куча копирований памяти :)

пока не критично )

https://capnproto.org/cxx.html#lessons-learned-from-protocol-buffers

собственно, у capnp и протобафа - автор один

я не знаю, людям нравится (

спасибо за такой подход. не учите меня жить дайте чо хочу.

Вот и я не пойму

спасибо за такой подход. не учите меня жить дайте чо хочу.

ну вот у нас такой подход, да. Не знаю уж, к сожалению или к счастью

я даю сервис, люди им пользуются

ну кому-то позарез надо :)

пока не начинают слать мусор я их не трогаю

те же финансы )))

24 часа - потому что по офису куча мониторов которые графики отображают, там обычно за 24 часа

так что кейсов много и не смотря на общее название TSDB все эти сериес ой какие разные)

так что кейсов много и не смотря на общее название TSDB все эти сериес ой какие разные)

ну вот да.

я очень хочу попробовать как side-project сделать сбор данных с профилировщиков в приложениях и отчеты по ним

и с ОС туда же статистику, даже банальную по времени работы сисколов для каждого pid'а.

perf чтоли переизобрести ?

perf чтоли переизобрести ?

прикрутить базу данных к нему )

чтобы оно постоянно слало данные по тому что творится в системе

боюсь твоего подхода.

а зачем так углубляться?

боюсь твоего подхода.

почему?

это слишком, имхо.

а зачем так углубляться?

кажется что позволит получить много интересной статистики в случаях когда все плохо, но непонятно почему

потому что это как идея потенциально полная замена тестированию в ядре

потому что это как идея потенциально полная замена тестированию в ядре

почему?

sysdig на этом денег миллион привлек

они именно это делают

сисдиг да

метрики с ядра в аналитику и отчеты тебе красивые