так что вполне ACID

а разве именно timescale в постгре - ACID? я никогда не использовал этот тип

а можно пояснить какие такие данные не терпят потери единичной точки, но при этом tsdb и вот это вот всё

Market data, process control, SCADA итд

финансы в tsdb ?

Ага, это обычно называется не тсдб а тикерплант, но суть та же

Postgres, вроде, используется для TSDB, да и сейчас там timescale еще

использовать для tsdb на потоке 1 метрика в секунду можно pipe в файл

Market data, process control, SCADA итд

SCADA да

согласен

использовать для tsdb на потоке 1 метрика в секунду можно pipe в файл

Там так? я не юзал. но timescale продвигают. Расскжи подробнее)

если интересно про еластик и заливку метрик в него то все что я отрыл на просторах по тестам было в 4 раза примерно медленее карбона и КХ

на запись

если интересно про еластик и заливку метрик в него то все что я отрыл на просторах по тестам было в 4 раза примерно медленее карбона и КХ

При каком конфиге? 1 диск?

Там так? я не юзал. но timescale продвигают. Расскжи подробнее)

while true; echo d=$(date +%s) echo "$d $RND" » /tmp/myvalue; done

но если в нем спецом всю индексацию порубить чисто чтоб данные писать (ну вдруг надо) то и точка была байт 15 вроде и скорость более менее... вот только нафига такой эластик

while true; echo d=$(date +%s) echo "$d $RND" » /tmp/myvalue; done

а, я думал это сарказм про медленность postgres на ingest

это сарказм на применение технологии без понимания окружения.

но если в нем спецом всю индексацию порубить чисто чтоб данные писать (ну вдруг надо) то и точка была байт 15 вроде и скорость более менее... вот только нафига такой эластик

я думал о горизонтальной масштабируемости и резервированности

карбон и КХ вполне норм масштабируются

инженерно выглядит что хранить в еластике ts не очень решение. но уверен есть кейсы в которых это будет норм. например прототипирование и команда програмистов на ноде.

человечество вон rrd юзало для мониторинга более 10 лет. а до этого mrtg. брат жив как правило.

ну я какой то веселый тест с майскулем находил... там товарищи делали из него нетранзакционную БД :) ничо так по быстроте заливки данных было :)

так что @kireevco как выглядит кейс в котором стоит взять эластик для ts ?

инженерно выглядит что хранить в еластике ts не очень решение. но уверен есть кейсы в которых это будет норм. например прототипирование и команда програмистов на ноде.

при прототипировании на ноде нужен монго. Это, в общем-то, единственный вариант когда он нужен

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

в смысле вообще единственной - все свои данные он хранил только там

скорость работы была просто космической

так что @kireevco как выглядит кейс в котором стоит взять эластик для ts ?

Хороший вопрос. Кейс для большого продакшена, в перспективе.

что именно с проектом не так что должны выбрать эластик для ts ? умение его готовить ? люботь в нему админа ?

почему будет взят он по какому критерию ?

Умение готовить, да. ну это спорное преимущество, можно научиться готовить что угодно, если оно правильно.

человечество вон rrd юзало для мониторинга более 10 лет. а до этого mrtg. брат жив как правило.

это не прогрессивное человечество юзало, прогрессивное юзало kdb и всякие operation historians, которые еще в начале 90х появились, а возможно и раньше

это только в мониторинге все недавно началось

... Стабильность технологии

в смысле в мониторинге серверов

а можно пояснить какие такие данные не терпят потери единичной точки, но при этом tsdb и вот это вот всё

любая отчётность и аналитика

это не прогрессивное человечество юзало, прогрессивное юзало kdb и всякие operation historians, которые еще в начале 90х появились, а возможно и раньше

промышленный Historian под капотом держит что-то типа виспера ?

стабильность эластика довольно часто подвергают сомнению. авторы не рекомендуют использовать эластик для первичного стораджа

не держит

стабильность эластика довольно часто подвергают сомнению. авторы не рекомендуют использовать эластик для первичного стораджа

Хорошо. Ну а в сравнении с KH?

у нас все было поверх mssql например :) piggybacking

не держит

вот тот, что на W начинается, а на e заканчивается - держит

при сравнении с кх у него большия цена метрики и хуже скорость на запись

в любом кейсе

все лежало в могучих блобах

призываю в чатик завтра с утра бозоноводов :) нимагу я в эту норкоманию (деньги в ррд и прочее) больше - спать уже хочеца очень

при сравнении с кх у него большия цена метрики и хуже скорость на запись

ok, а с чтением?

при этом кх готов двигаться немного для тсдб а эластик нет.

при этом кх готов двигаться немного для тсдб а эластик нет.

мм... Ну да. и модель ретеншена похожая, как я понял. удалем по "индексу" или "базе" что типично делается днями или часами.

чтение у кх паралелится. язык сильно похож на sql в редакции муськи

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

мм... Ну да. и модель ретеншена похожая, как я понял. удалем по "индексу" или "базе" что типично делается днями или часами.

не верю в часовые партиции в кх. это очень сложный кейс.

верю в дневные и недельные. но может я не видал нагрузки просто

Ну ок. Идея понятна (Яж кх не видел в глаза, просто пытаюсь провести аналогии)

я не топлю за кх. просто он довольно сильно изменил правила игры на рынке этом

и сейчас объективно крут

Ну я знаю, тут все адекватные, не топят за что-то конкретное. только иногда против <censored>

но объективно КХ не затачивался под TSDB :)

да. кх много не хватает для tsdb

мягко говоря)

адекватных ролов так и нету

а кто-нибудь может ELI5 как кх хранит данные? у меня есть подозрение что там что-то вроде LSM-tree с PAX (типа column-store но только локально, внутри каждого блока)

у них документация для инопланетян, кмк

а кто-нибудь может ELI5 как кх хранит данные? у меня есть подозрение что там что-то вроде LSM-tree с PAX (типа column-store но только локально, внутри каждого блока)

присоединяюсь к вопросу

Ну вот по ingest KH понятен. А по остальному? По идее, ведь, можно через spark лепить нормальные выборки?... Хотя тогда оптимизации не особо будет. ладно, проехали

да. кх много не хватает для tsdb

а должно иметь место?

а должно иметь место?

эм

да

ERROR: S client not available

ок. перерформулируй вопрос плиз

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

да. но AggregatedGraphiteMergeTree же

то есть кх - как аналитическай скейлаут бд

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

так они же вроде вообще не про ts, просто подошли и тут

так они же вроде вообще не про ts, просто подошли и тут

я просто откомментил про не хватает для тсдб

понятно что они хотят другое. но не все стартапы способны угодать как их будут использовать

кх писался для внутренних нужд

они решали свою задачу

им пофигу стартапчики

:)

как хотите

у них голова болела от аналитики и метрик

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

и не опен тоже

Короче KH в трех словах это хороший ingest, масштабируемость и...?

как хотите

лучше на ты и без отчеств

лучше на ты и без отчеств

http://bash.im/quote/12782

бгг

Короче KH в трех словах это хороший ingest, масштабируемость и...?

и хайп

??

То есть ничего больше?))

и камунити. а так да. больше ничего

Ну блин. выходит что ES выигрывает во всем кроме ingest, возможно где-то масштабируемости ? (ну и byte per point)

@kireevco ну исходить всегда надо от задач

Ну блин. выходит что ES выигрывает во всем кроме ingest, возможно где-то масштабируемости ? (ну и byte per point)

то есть почти нигде?

Почему? синтаксис Lucene, полно тулзов

Хотя, для KH тулзы от graphite подходят если через graphite+KH делать?

в рамках этого чата - почти нигде :)

в рамках этого чата - почти нигде :)

что это значит?

Я чувствую великое возмущение Силы

Кто-то использует ES для хранения time-series data