Ну тогда только тулза

Внешняя которая будет чистить

ну у меня есть и так sidecar к кх, видимо в него докину

ну зашел в зк и удалил

реплики просто так же не умирают

реплики просто так же не умирают

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

а видео пока нет?

Видео организаторы обещают только через 3..4 недели.

Кто подскажет, как лучше быть? Надо хранить РПС (уже агрегированные данные). Какой тип лучше использовать? агрегейтедмерджтри или обычный? И как понимаю лучше написать материалайзед вьюшку?

Посмотрите в сторону carbon-clickhouse и graphite-clickhouse Если у вас данные уже аггрегированы как вы написали или вам каждый реквест в базу вставлять надо?

Кто подскажет, как лучше быть? Надо хранить РПС (уже агрегированные данные). Какой тип лучше использовать? агрегейтедмерджтри или обычный? И как понимаю лучше написать материалайзед вьюшку?

Самое простое и верное - попробовать все варианты. Никто не может угадать вашы данные и нагрузку на них. Только эксперименты на живых данных

Посмотрите в сторону carbon-clickhouse и graphite-clickhouse Если у вас данные уже аггрегированы как вы написали или вам каждый реквест в базу вставлять надо?

В таблицу ложится все, я хочу сделать посагрегация уже вдругую таблицу

В таблицу ложится все, я хочу сделать посагрегация уже вдругую таблицу

Если вам нужно ускорить некий агрегирующий запрос путем хранения его на диске - мат вьюха с движком агригейтмердтри вам в помощь

Если вам нужно ускорить некий агрегирующий запрос путем хранения его на диске - мат вьюха с движком агригейтмердтри вам в помощь

Ок, хорошо, ну, просто не хвататет одного ТБ диска на месяц, поэтому решил хранить только агрегированные данные

Ок, хорошо, ну, просто не хвататет одного ТБ диска на месяц, поэтому решил хранить только агрегированные данные

А собираете чем? Zipkin? Opentracing api? Golang?

А собираете чем? Zipkin? Opentracing api? Golang?

nginx->rsyslog->kafka->kafka-engine->mview->mergetree

и надо уже с мерджтри агрегировать данные

Ок :) понятно а всякие heka и т.п. Не пробовали для логов вместо рсислог и кафки?

Ок :) понятно а всякие heka и т.п. Не пробовали для логов вместо рсислог и кафки?

нет, а он лучше? Я бы попробовал если бы знал что именно ))

Надо логи нгинса хранить

и он умеет либо в файл либо в rsyslog

filebeat -> logstash -> clickhouse

Доброе утро, вопрос. У меня есть постгревая база в которой хранится первичка, потом все это дело собирается в одну большую витрину и грузится через csv в clickhouse. В первичке попадаются спецсимволы, что приводит, например, к таким ошибкам: And if your file have right number of columns, maybe it have unescaped backslash in value before tab, which cause tab has escaped. в данном конкретном случае поле выглядело так: 321\ но встречаться может любая комбинация \t \r и т.д. вопрос - как и какие специсимволы стоит экранировать? выгрузка в csv из postgres выглядит как copy (select * from table) to STDIN WITH CSV DELIMITER AS e'\t' QUOTE e'\b' NULL AS ''

filebeat -> logstash -> clickhouse

не не...у меня как основное пока ELK, вот по тихой перехожу на схему выше

@proller @milovidov_an спасибо за фикс https://github.com/yandex/ClickHouse/pull/2313 !!!

Никто не решил проблему с кафкой?

То, что он пишет редко данные, т.е. materialized view очернь редко флушит

Так вроде же это регулируется конфигами max_insert_block_size, stream_flush_interval_ms. Или оно не работает?

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

Так вроде же это регулируется конфигами max_insert_block_size, stream_flush_interval_ms. Или оно не работает?

Не работает, сломался

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

Нет, не дождётся.

Нет, не дождётся.

а как лучше тогда вырубать ноды?

есть возможность какой нибудь RO режим включить?

чтоб запись на ноду не шла

Просто убрать ее из конфига шарда

есть возможность какой нибудь RO режим включить?

Проще всего на стороне вашей вставлялки.

то есть надо предупреждать вставлялку что щас кх будет недоступен?

Можно фронтенд на nginx делать и исключать из апстримов того, кто вот прям щаз будет выключен

то есть надо предупреждать вставлялку что щас кх будет недоступен?

Если вы хотите мягко погасить ноду, почему бы и нет. Возможности принудительно включить ридонли сейчас нет. Можно отключить реплику от зукипера, тогда она сама перейдёт в ридонли, но выглядит странно.

Проще всего на стороне вашей вставлялки.

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

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

именно

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

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

щас так и сделано, конфиг перегенерит из сервис дискавери и удалит ноду которая выключается, но я думал еще навесить режим RO

И это тоже не всегда может помочь - при асинхронной записи в Distributed конфиг шарда берётся на момент INSERT-а, а не на момент собственно вставки.

а зачем вы ее выключаете ?

а зачем вы ее выключаете ?

ну например нода уходит на обслуживание, кх укатывает на другую ноду

или например делается апдейт релиза

Можно тогда отрезать 9000 порт, дождаться, пока уже вставленное отреплицируется, и уже потом выключать. Но это всё неудобно конечно. В ClickHouse предполагается, что у вас реплики никуда не переезжают и либо восстанавливаются через некоторое время на том же хосте, либо умирают с концами.

При апдейте сервера проблемы быть не должно - сервер поднимется и другие реплики стянут с него недостающие куски.

а как вот лучше бороться в No replica has part? скажем сдохла реплика, на ней есть кусок которого нигде нет

и например реплика совсем сдохла, с концами прям

ну только удалить в зукипере ее путь и должна пропасть ошибки

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

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

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

и прям гадит в лог

ну только удалить в зукипере ее путь и должна пропасть ошибки

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

Непонятно, как на стороне сервера отличить случай, когда реплику вот-вот починят от случая, когда она сдохла с концами.

Так вроде же это регулируется конфигами max_insert_block_size, stream_flush_interval_ms. Или оно не работает?

stream_flush_interval_ms - не работает.

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

Непонятно, как на стороне сервера отличить случай, когда реплику вот-вот починят от случая, когда она сдохла с концами.

ну хотя бы по таймауту, я бы не против указать опцию replica_cleanup_timeout, потому что в зукипере они у меня тоже множатся и зукипер пухнет

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

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

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

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

Коллеги,а есть где-нибудь инструкция\статья по настройке CH с Zookeeper?

Вставляю данные за прошлые периоды, путём потокового чтения из источника, сбором пачки и записи в КХ и т.д.. Залил порядка 300кк записей и сделал проверку, не потерял ли чего. Нашел что в КХ недоехало примерно несколько тысяч (пару записей на каждый день) из 300кк. Кто-нибудь сталкивался с таким? Код заливки на nodejs, либа @apla/clickhouse Таблица MergeTree

Коллеги,а есть где-нибудь инструкция\статья по настройке CH с Zookeeper?

Да, вот прямо в оф документации есть, добавляете в конфиг адреса Зукипера и все, настройка закончена

Вставляю данные за прошлые периоды, путём потокового чтения из источника, сбором пачки и записи в КХ и т.д.. Залил порядка 300кк записей и сделал проверку, не потерял ли чего. Нашел что в КХ недоехало примерно несколько тысяч (пару записей на каждый день) из 300кк. Кто-нибудь сталкивался с таким? Код заливки на nodejs, либа @apla/clickhouse Таблица MergeTree

Нет, такого быть не может, или вы вставляете кусок целиком или ничего, вылететь из него пару записей не может

Коллеги,а есть где-нибудь инструкция\статья по настройке CH с Zookeeper?

Есть, но я бы не назвал ее понятной на 100%. Сам долго мучался. Могу подсказать если что.

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

Я сейчас это решаю, решалка будет в Open Source, но когда не знаю )

Я сейчас это решаю, решалка будет в Open Source, но когда не знаю )

мож в сам кх ее встроить а ?)

и так все sidecarами обвешано )

Ребят, а киньте в меня, пожалуйста, примером best practics для построения отказоустойчивого кластера с учетом использования hdd для хранения данных. В текущем виде у нас 2 шарда с двумя репликами на двух серверах, сейчас нужно построить кластер для более ресурсоемкого проекта

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

мож в сам кх ее встроить а ?)

Там будет все немного сложнее чем просто выключение пропавшей реплики ?

собственно без разницы ссд или хдд

Как в доке, это понятно, а жизнь вносит свои коррективы)

Просто сделайте несколько шардов и всё

Там будет все немного сложнее чем просто выключение пропавшей реплики ?

ну такой функционал все равно ведь логичнее запихнуть в сам кх?

Просто сделайте несколько шардов и всё

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

ну такой функционал все равно ведь логичнее запихнуть в сам кх?

Нет, Алексей (@ztlpn) уже писал что не понятно как самим КХ определять совсем пропала реплика или ещё починиться, или подняли что-то в замен ей

да и несколько реплик тоже так себе держать на одной ноде

Как в доке, это понятно, а жизнь вносит свои коррективы)

мы делаем как в доке , пока жизнь не вносила корректив

Нет, Алексей (@ztlpn) уже писал что не понятно как самим КХ определять совсем пропала реплика или ещё починиться, или подняли что-то в замен ей

ну я ж предложил сделать опциональный таймаут, по дефолту можно сделать 0, то есть не включать авточистку

это актуально для развертываний во всяких облачных штуках

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

Нет, это только всё усложнит. Если у вас приватный "клауд" и вы живете в контейнерах/виртаулках то да, можно уплотниться и выжать таким образом из железок больше, если нет то лучше все держать на отдельном железе

Т.е. по сути, если мы жадные, и у нас выделено под это два сервера, мы делаем просто реплику и все, верно?

ну я ж предложил сделать опциональный таймаут, по дефолту можно сделать 0, то есть не включать авточистку

Это может сильно стрельнуть, а так сделать это не сильно сложно, для развертывания в облаках лучше, пока, писать свою управлялку КХ в облаке

И, кстати, clickhouse дружит с zetcd?

Т.е. по сути, если мы жадные, и у нас выделено под это два сервера, мы делаем просто реплику и все, верно?

Если вы жадные то купите 4, но дешевле

И, кстати, clickhouse дружит с zetcd?

Нет, с zetcd никто не дружит

Уже пробовали?

Это может сильно стрельнуть, а так сделать это не сильно сложно, для развертывания в облаках лучше, пока, писать свою управлялку КХ в облаке

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

Уже пробовали?

Да, пробовали, просто zetcd, судя по всему, ребята писали чтоб проходили тесты для гошной либы Zookeeper, а это путь вникуда, если посмотреть на GitHub то создается ощущение что всё это поделие забросили