А зачем кластер на одном сервере собирать?

Кролику становится не по себе если 1) у вас ооооооочень много очередей 2) если вы его превращается в CDN, то есть гоняете кучу лишних данных

кластер на одном сервере, в docker-compose развернут, там точно с сетью нет проблем

мне кажется, что фраза «docker-compose, с сетью нет проблем» сама по себе несет зерна самоотрицания, но можно посмотреть чем именно занят кролик внутри

вопрос не по теме кто подскажет хороший сервер очередей, взамен RabbitMQ

Kafka? )

Тогда это не проблема рэбит. 5к он спокойно держит. Скорее всего не правильно кластер собрали. Я бы попробовал такую нагрузку сперва на одном инстансе рэбита. + у рэбита есть известная проблема кластера. Если моргает сеть, то кластер не может восстановиться, м.б. у вас кластер в разных дц

спокойно держит при каком проценте потерь сообщений ?

вопрос не по теме кто подскажет хороший сервер очередей, взамен RabbitMQ

NATS

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

спокойно держит при каком проценте потерь сообщений ?

когда тестил, и 7.5к держало без проблем пока не понятна причина, того что сейчас происходит

nsq еще есть

Kafka? )

Это очень специфичная очередь

уже советовали NSQ смотрим

специфики в нем своей много, конечно

но из хорошего -- по отсечке начинает писать на диск

специфики в нем своей много, конечно

а в чем специфика?

в том, что там клиенту нужно найти писателей

и для этого отдельный сервис есть

nsqlookupd

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

пока он их не найдет

и второе -- гарантия доставки at least once

ну такая нода есть в ZK да потому что такая таблица сделана на другой репилке в шарде но насколько я понимаю CREATE TABLE не реплициурется но кажется я понял в чем косяк это потому что порядок полей при создании таблицы у меня может поменяться

create table нет, но есть create table ... on cluster

возможны дубликаты

и не гарантирован порядок сообщений

как транспорт для метрик и записей, которые нужно уложить в CH - очень неплох

но нужно понимать, что там нет какого-то кластера с сервисом

create table нет, но есть create table ... on cluster

я в курсе, вот только что будет с этим create table on cluster при подключении новой ноды в новый шард? как оно работает?

Это очень специфичная очередь

Которую очередью назвать сложно :)

ну да

я в курсе, вот только что будет с этим create table on cluster при подключении новой ноды в новый шард? как оно работает?

Мы это всегда решали копированием нужных /var/lib/clickhouse/metadata

Далее ClickHouse сам найдет, что надо стянуть

Каталоги в data создавать надо при этом?

Которую очередью назвать сложно :)

Смотря что считать очередью

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

Мы это всегда решали копированием нужных /var/lib/clickhouse/metadata

согласитесь что это все таки костыль? вообще конечно для clickhouse не хватает какой то CLI утилиты для менеджмента кластеров

Каталоги в data создавать надо при этом?

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

согласитесь что это все таки костыль? вообще конечно для clickhouse не хватает какой то CLI утилиты для менеджмента кластеров

А Вы mysql новую реплику как-нибудь инициируете первый раз?

А Вы mysql новую реплику как-нибудь инициируете первый раз?

да инициализирую, через xtrabackup streaming но точно не копированием... но мысль хорошая, спасибо, я подумаю и новая реплика mysql это все таки вообще не тоже самое что новый "шард" в clickhouse ;)

Здравствуйте. Нам необходимо "поиграться" с CH на тестовых данных. В статье http://clickhouse.readthedocs.io/en/latest/reference_ru.html есть ссылка на тестовые данные, но она не актуальная. Есть у кого архив?

Здравствуйте. Нам необходимо "поиграться" с CH на тестовых данных. В статье http://clickhouse.readthedocs.io/en/latest/reference_ru.html есть ссылка на тестовые данные, но она не актуальная. Есть у кого архив?

так сделайте свои тестовые данные

Здравствуйте. Нам необходимо "поиграться" с CH на тестовых данных. В статье http://clickhouse.readthedocs.io/en/latest/reference_ru.html есть ссылка на тестовые данные, но она не актуальная. Есть у кого архив?

актуальная документаия тут https://clickhouse.yandex/docs/ru/getting_started/index.html?highlight=%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D1%8B%D0%B5

Здравствуйте. Нам необходимо "поиграться" с CH на тестовых данных. В статье http://clickhouse.readthedocs.io/en/latest/reference_ru.html есть ссылка на тестовые данные, но она не актуальная. Есть у кого архив?

https://clickhouse.yandex/tutorial.html вот может пригодиться

@Slach, @rheinx спасибо!

Всём привет. Необходимо сделать "connect by prior" селект из кх. Почитал документацию, не нашёл как. Может кто знает?

Подозреваю, что можно сделать через массивы

arrayJoin

Подскажите, кто сталкивался <Error> Application: DB::Exception: Cannot lock file /var/lib/clickhouse/status. Another server instance in same directory is already running. Как пофиксить?

Появилась после не корректного завершениния работы, процесса clickhouse-server

Рестартовать пробовал

Проблем в записии и чтении не вызывает

прибить/переименовать файл перед рестартом пробовал?

это после обновления ?

всем привет. получаем ошибку Method dropPartition is not supported by storage MaterializedView - получается, что удалить партиции в мат.вьюхе невозможно? а так же детачнуть и т.п.? не нахожу об этом в документации

Посмотрите список таблиц SHOW TABLES и найдете по названию вьюхи, но с .inner., а лучше их создавать на уже существующие, дальше проще жить будет

спасибо

Подскажите, кто сталкивался <Error> Application: DB::Exception: Cannot lock file /var/lib/clickhouse/status. Another server instance in same directory is already running. Как пофиксить?

должно помочь удаление /var/lib/clickhouse/status

Всём привет. Необходимо сделать "connect by prior" селект из кх. Почитал документацию, не нашёл как. Может кто знает?

иерархические запросы в лоб работать не будут, но если вы сохраните транзитивное замыкание иерархии в массив, то дальше действительно можно arrayJoin, джойн на себя и попробовать выбрать какое-то подходящее множество объектов.

должно помочь удаление /var/lib/clickhouse/status

Спасибо за совет.

Привет! есть способ в запросе внутри IN передать внешний фаил?

нашёл, спасибо)

иерархические запросы в лоб работать не будут, но если вы сохраните транзитивное замыкание иерархии в массив, то дальше действительно можно arrayJoin, джойн на себя и попробовать выбрать какое-то подходящее множество объектов.

Спасибо за ответ. Не совсем понятно как сохранить транзитивное замыкание иерархии в плоской таблице в кх.

В таблице есть колонки parent, child, other data

В колонке child хранятся имена парентов

В колонке child хранятся имена парентов

чтоб никто не догадался?

Надо найти все строки у которых конкретный парент

вам нужен parents, который равен parent.parents + parent, при создании (перед вставкой) его возможно можно вычислить.

чтоб никто не догадался?

К сожалению данные уже лежат в кх

господа вот этот https://github.com/yandex/ClickHouse/pull/1806/files будет только в новой версии ?

1.1.54337 с точки зрения докера сломана получается ?

Привет! Кто нибудь знает в какой момент обновляются внешние словари? У меня HTTP источник дал ошибку и ClickHouse больше не пытается получить данные. Есть вариант ручного запуска обновления словаря?

Привет! Кто нибудь знает в какой момент обновляются внешние словари? У меня HTTP источник дал ошибку и ClickHouse больше не пытается получить данные. Есть вариант ручного запуска обновления словаря?

SYSTEM RELOAD DICTIONARY;

Скажите, пожалуйста, если я использую summing merge tree, смогу ли я потом извлечь сырые записи? И как, если это возможно?

SYSTEM RELOAD DICTIONARY;

Спасибо Владимир!

То же самое про replacing merge tree, там определённо поддерживается версионность. Но я так и не понял как вытаскивать оттуда старые значения.

То же самое про replacing merge tree, там определённо поддерживается версионность. Но я так и не понял как вытаскивать оттуда старые значения.

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

исходные данные при этом не сохраняются.

Спасибо.

1.1.54337 с точки зрения докера сломана получается ?

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

Мне оверкил

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

Какими порциями оптимально даннные сажать? В таблице 60 столбиков. Попробовал 3 ляма одной котлетой пихнуть, что-то мне не нравится результат (озушка)

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

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

текущий контейнер нормально работает я правда всегда прокидываю через volume собственный config.xml , users.xml и macros.xml

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

зависимостей слишком много?? так написано что вообще нет зависимостей кроме libc

зависимостей слишком много?? так написано что вообще нет зависимостей кроме libc

;))) насколько я смотрел пулл реквесты просто остальное как git submodules выкачивают перед тем как в cmake собрать

;))) насколько я смотрел пулл реквесты просто остальное как git submodules выкачивают перед тем как в cmake собрать

ну так это обычный процесс сборки все тут написано https://clickhouse.yandex/docs/en/development/build.html

Какими порциями оптимально даннные сажать? В таблице 60 столбиков. Попробовал 3 ляма одной котлетой пихнуть, что-то мне не нравится результат (озушка)

наверное, имеет смысл котлету до фрикадельки уменьшить. у меня, например, вообще по 100-200к чипсинки, залетают нормально, раз в несколько сек

Спасибо. Попробую по 100к. Или даже меньше. Таблица больно широкая.

Коллеги, мб кто-нибудь знает, нет ли способа сделать чтобы КХ ходил за словарями в через ODBC без prepared_statement? Это взывает проблемы при работе через pgbouncer не в режиме сессионного пулинга соединений.

Коллеги, мб кто-нибудь знает, нет ли способа сделать чтобы КХ ходил за словарями в через ODBC без prepared_statement? Это взывает проблемы при работе через pgbouncer не в режиме сессионного пулинга соединений.

Пока нет. Честно сказать, я не обращал внимания на то, что там внутри используются prepared statements.

Пока нет. Честно сказать, я не обращал внимания на то, что там внутри используются prepared statements.

Понятно. Видимо внутри метрики либо никаких словарей в постгресе, либо они совсем ненагруженные)

Да, у нас нет словарей в Постгресе.

Эта задача назначена, но по ней ещё не было работы.

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

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

Новостей нет. Она только во внутреннем трекере.

Этой задачей занимается @proller

Спасибо. Будем ждать.

Пока нет. Честно сказать, я не обращал внимания на то, что там внутри используются prepared statements.

По поводу баунсер уточню кейс. В случае когда нужно тащить словари из нагруженной БД, на ней 99% случаев есть пулер соединений. Если пулер в режиме транзакций или стейтментов то возникают ошибки вида >ERROR: prepared statement "_PLAN0x88c8580" does not exist При этом в логе постгреса подряд идущие записи >ERROR: prepared statement "_PLAN0x88c8580" does not exist >ERROR: prepared statement "_PLAN0x88c8580" already exists >ERROR: prepared statement "_PLAN0x88c8580" does not exist Такое чувство, что odbc драйвер в кликхаусе одинаково именует prepared statement'ы для разных словарей и стейтмент застревает в рандомной сессии пуллера.

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