проблемы с производительностью и на метриках в это время сильно возрастают tup_fetched и tup_returned в секунду. И сильно растет при этом нагрузка на диск. Но включая логирование всех запросов я вижу только INSERT запросы и больше ничего. И так оно и должно быть, в базу идет только запись. Поэтому сейчас я немного в недоумении откуда тогда эти метрики
Знаю что у clickhouse требования вставлять большими батчами ради производительности. Я так понимаю вы по одной строчке вставляете? Может в этом дело? Не спец в tsc
Да, вставляю по одной строке. Но по идее timeseries базы как раз под это и оптимизируются. Ну и что самое главное, это хочется понимать откуда берется куча fetch/returned в метриках
А кликхаус это ведь больше для анализа база? Когда у тебя уже есть данные и ты их туда заливаешь чтобы делать всякие сложные запросы
Насколько я понимаю (могу ошибаться) timescale и clickhouse решают похожие проблемы и обе колоночные. А еще знаю что кликхаус сжимает строки lz4, возможно tsc тоже что то такое делает. Оттуда и перфоманс лосс
https://blog.timescale.com/blog/13-tips-to-improve-postgresql-insert-performance/ Может тут что то по теме есть
О, спасибо, почитаю
То есть если собираешь в реальном времени метрики, то в идеале их собирать в timeseries базу, а уже оттуда экспортировать в кликхаус, верно?
Зачем так усложнять?)))
А вы как делаете? По идее конечно можно раз в секунду вставлять сразу кучу данных и это будет почти то же самое, что и с timeseries. Но я не знаю как кликхаус работает. Может там нужно один раз вставить сразу все данные
Кликхаус советует большими пачками данные вбивать
Но вот вопрос какой может быть интервал между вставками, чтобы все было максимально оптимально
Из той статьи что я выше кинул. Зачем кликхаус если tsc вроде тоже самое
Все же я бы посоветовал дочитать ту статью
Да, надо будет попробовать мне тоже через буфер сделать. Просто меня смутили метрики. То, что там возрастает отношение fetched/returned к inserted. То есть в нормальной ситуации например 4k returned на 1k fetched (и тут тоже непонятно откуда returned, если все запросы это INSERT). А в пике может быть 320k returned на 6к inserted. Очень хочется понять что это вообще значит
https://github.com/timescale/timescaledb/issues/2512#issuecomment-705863640 Вот еще. Лучше хотя бы приблизительно временной порядок соблюдать. У них там куча оптимизаций на это
это уже не так - под капотом он сам создает буфер записей для вставки и вставляет их по мере заполнения буфера
Если интересно. Я таки сделал буферизацию и все проблемы решились :) Непонятные fetched/returned ушли из метрик и все стало замечательно 😊 Спасибо за помощь!
Обсуждают сегодня