И да, мы сперва обновляем тестовый кластер из 2 КХ, которые в соседних LXC на этих же серверах. Если на них всё начинает работать "плохо", то мы ждём следующий релиз. Обычно это пол часа ;)

Можно ещё что нить с кафкой придумать, но в этом пока нет необходимости

норм

В timescaledb наконец-то подвезли сжатие данных - https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/

бандиты, вопросик, что то не выходит лейбл переиначить в метриках прометеяю (забираю через federate)
сейчас лейбл instance="0.0.0.0:111" ,  делаю следующие

    relabel_configs:
      - source_labels: [instance]
        regex:  '(.*)'
        target_label: instance
        replacement: '${1}'

где я проэтавался?

знаем мы на чью Z-мельницу они воду льют :-)
не, молодцы они конечно, но ведь с другой стороны - такого контраргумента лишают...

На вскидку все равно сильно хуже чем у других тсдб

Просто теперь не в 50 раз, а в 3-4

если я правильно помню вы все что нашли на то и заменили

если действительно хуже, то непонятно почему, алгоритмы  то те же
если я правильно понял у них около 5байт на точку получилось, у многих где-так и есть (у меня сейчас 2-4 байта на точку)
там где меньше байта на точку - и объемы реально большие и алгоритмы не дефолтные

Ну я так понимаю у них и оверхед всякого разного сильно выше. 5 байт у них по тестам best case судя по всему. Worst - около 10

все равно их сжатие не дотягивает до ВМ в 4-5 раз, судя по данным из их статьи

Зато оно не loseless 😂

Вообще, по статье не очень то и понятно, сколько там байт на точку.

Я вижу два недостатка. Они сначала пишут в row-order, потом перезаливают в column-order. Из-за этого, во первых, часть данных всегда лежит на диске раздутой, во вторых, процесс/поток, который эти данные жмет в column-order может не успевать.

Я отталкивался от прошлых тестов и инфы

yandex/ClickHouse tagged: v19.11.13.74-stable
Link: https://github.com/ClickHouse/ClickHouse/releases/tag/v19.11.13.74-stable
Release notes:

v19.11.13.74-stable

Кроме этого, есть еще и другие недостатки:
- Нужно явно прописывать порядок сортировки и партиционирования данных, чтобы достичь максимального сжатия. Если неправильно укажешь эти параметры, то в одной строке окажутся значения для разных рядов, раскиданные в случайном порядке. Для них компрессия - что мертвому припарка.
- Значения для одного ряда остаются разбросаны по диску даже при правильном указании порядка сортировки и партиционирования. Просто раньше они были разбросаны по одному значению, а теперь будут разбросаны по небольшим группам значений. В итоге, для того, чтобы прочитать с диска исторические данные одного ряда, требуется много disk seeks, что не очень хорошо работает на HDD.

если экспортер возвращает несколько значений в одной метрике, то как к ним обратиться в alert правилах prometheus?
например для heartbeat_data{device="zzzz"} x y
как получить доступ к x и y ?