11238
Обсуждаем ClickHouse
Блин) а на тестах кх рвет пг в чистую)) одинакое железо, одинаковый запрос, кх 20 сек, пг ушел на 2 часа...
И что делать?😁
половина моих кликхаус консультаций на работе выглядит как "не выёбывайся, возьми постгрес"
Читать полностью…
так в таблицы инсерты тоже не атомарны, может ни одной строки не запишется, а может половина.
Читать полностью…
согласен поэтому предложил автору топика лечить причину а не симптомы
Читать полностью…
Ну я просто описал о чем выше говорили
Читать полностью…
А ну кажется только на старте надо будет «выровнять» буфер с основной таблицей на случай падения сервера. А в остальном супер решение , спасибо
Читать полностью…
https://clickhouse.com/docs/engines/table-engines/special/buffer
Читать полностью…
Не совсем понимаю каким именно образом сделать буфер. Изнутри кликхауса как-то или снаружи только возможно?
Читать полностью…
Понял, спасибо за мнение! Яичко поберегу :) Пока пойду бенчмаркать MV, может вообще зря себе голову забиваю
Читать полностью…
какой именно софт обрабатывает у вас эту информацию ? как именно? может ему надо напрямую а не через clickhouse обрабатывать?
если человек то про "реальное время" это вранье...
даже блин на МКС и SpaceX телеметрия не реалтайм, а с кучей задержек до единиц секунд... потому что большинство решений софт в микроконтроллере принимает самостоятельно на борту...
MV то будет отрабатывать вовремя, это ж обычный триггер по сути. Самая частая проблема как раз в множестве мелких слияний, которые могут хорошо нагружать КХ.
Читать полностью…
Как раз уходим от зоопарка в один-единственный ClickHouse ради упрощения.
Раз в 10 секунд - не вариант. Результаты некоторых MV нужны в режиме реального времени.
Пока мой план такой: подготовить извраты на Refreshable Materialized Views на случай если время инсертов выйдет за одну секунду. Переписать самые тяжелые MV с incremental на refreshable (на самом деле тоже incremental, просто через ж***).
Ребят, есть способ заставить incremental MV обрабатывать данные не на каждый чих, а батчами покрупнее?
У нас данные льются ~ раз в секунду мелкими порциями. Хочется настроить каскад MV для агрегаций, но если повесить 100 MV на таблицы - боюсь кликхаус взгруснет, обрабатывая каждый секундный инсерт через все эти вьюхи (или нет, может зря перестраховываюсь).
В идеале хочется что-то типа: "эй, MV, копи данные и обрабатывай их раз в минуту одним батчем" или "когда накопится 10к строк". Но чтобы сами сырые данные были доступны сразу для real-time метрик.
Есть что-то нативное для такого? Или костыли на refreshable Materialized Views - лучших выход?
Если парсер посчитал значение датой, а потом не смог его распарить - это баг, такого быть не должно. Особенно если выключены настройки вывода дат совсем. Создайте issue на GitHub с воспроизведением проблемы и я займусь этим
Читать полностью…
Да, я прочитал про тесты, я правильно понимаю, что я делаю форк, делаю у себя изменения, билдюсь, запускаю тесты , и потом делаю мр в прод?
Читать полностью…
Просто КХ доволно сложен, и требует усилий.
Также точно в postgresql надо потратить месяцы на понимание как блокировки реплицируются при логической или физической репликации и какие фантомы из-за этого возможны.
Если ты делаешь один инсёрт в одну таблицу, то без специальных геморройных усилий нет гарантии что он войдёт или не войдёт в неё атомарно
Читать полностью…
MV не консистентны? 💀 То есть если я вставлю строчку в таблицу, дерну шнур из розетки, то нет 100% гарантии, что основная таблица + MV запишутся или не запишутся вместе?
Читать полностью…
это так, но обычное дерево matview без буферов тоже не сказать чтобы переживало жёсткий ребут без потерь.
можно получить и данные в основной таблице есть, во вьюхах нет, и наоборот
ненадежная схема, любая перезагрузка внезапная и данным из buffer engine кирдык...
Читать полностью…
Это же идеально, если я правильно понимаю!
Читать полностью…
MergeTree engine -> matview -> buffer engine -> margetree
Читать полностью…
Вон поминали Buffer таблицы, которые обычно втыкают между сильно резкими клиентами и основной таблицей.
Совершенно никто не запрещает воткнуть Buffer между основной таблицей и таргетной таблицей инкрементального matview
(если проблема с кучей маленьких мерджей окажется реальной, а буферизировать основную почему-то нельзя)
ну... удачи... refreshable с append only наверное конечно вас спасет, но надо иметь отсечку четкую по какому то критерию, чтобы данные не дублировали
полный refreshable подход, вы быстро себе яичко левое отстрелите...
Спасибо, буду бенчмаркать и пойду «продавать» коллегам
Читать полностью…
Но на самом деле будем просто молиться, что MV будут отрабатывать вовремя и никаких костылей не нужно будет
Читать полностью…
вставлять в buffer таблицы... или в кафка \ redpanda а оттуда уже в клик...
или вставляйте раз в 10 секунд... зачем раз в секунду, подкопите батчи...
ну вообще секунды должно хватать даже для мелких чанков
клик может быть всгрустнет на куче мелких мержей которые потом случатся, просто ему не будет хватать
если по дискам запас есть и CPU ядер дофига и памяти ... можно более аггрессивные мержи настроить еще...
https://github.com/ClickHouse/ClickHouse/issues/89368
я описал как мог, повторить очень сложно ( там гиганские JSON)
если нужно я могу в личке какую -то доп инфу предоставить
Это как хотите, можете не билдить, если вы знаете какой результат должен получится и ну впишите нужное в reference файл.
Читать полностью…
да, оно может так работать создайте issue в clickhouse-backup
вообще посмотрите настройки конфига в clickhouse-backup
там есть rbac_backup_always поставьте его false вместо дефолтного true
и все будет хорошо, если нет пишите вопросики