и можно много в схема sql положить

Кто-то раньше писал, что в пакете с CH идут скрипты, которые рестартят сервис, если он умирает.

это наверно в системд надо смотреть

Да, но они чаще рестартят при умирании.

Кто-то раньше писал, что в пакете с CH идут скрипты, которые рестартят сервис, если он умирает.

В кроне было, сейчас вроде закомментирован

это наверно в системд надо смотреть

Да, распавн

CREATE TABLE requests ( request_date Date MATERIALIZED toDate(request_time), request_time DateTime, request_uri String ) ENGINE=MergeTree(request_date, (request_time, request_uri), 8192); SELECT * FROM requests ORDER BY request_date DESC LIMIT 10;

Запрос видимо поднимает всю таблицу? Как такое оптимизировать? ...

WHERE

Коллеги, добрый день! Подскажите, есть ли официальная поддрежка решения clickhous или только комюнити ?

Есть Altinity, официальный партнер Яндекса. Подробнее можете у @alexanderzaitsev узнать

это наверно в системд надо смотреть

Это в cron.d нужно смотреть

Подскажите пожалуйста хотя бы куда копать Есть два шарда по две реплики КХ на все репликах созданы MergeTree таблицы mytable_real поверх них на всех репликах созданы Distributed таблицы mytable какое-то время все работает хорошо но потом одна из реплик начинает сходить с ума например: - при запросе select count() from mytable выдает ошибку об отсутствии таблицы mytable_real на втором шарде - при insert'e в mytable выдает ошибку об отсутствии колонки в таблице mytable_real. при это колонка присутствует и вставка непосредственно в mytable_real происходит без проблем

а что говорит sudo netstat -tulpn | grep :9000 на каждой реплике? нет ли там нескольких слушающих процессов?

Подскажите пожалуйста хотя бы куда копать Есть два шарда по две реплики КХ на все репликах созданы MergeTree таблицы mytable_real поверх них на всех репликах созданы Distributed таблицы mytable какое-то время все работает хорошо но потом одна из реплик начинает сходить с ума например: - при запросе select count() from mytable выдает ошибку об отсутствии таблицы mytable_real на втором шарде - при insert'e в mytable выдает ошибку об отсутствии колонки в таблице mytable_real. при это колонка присутствует и вставка непосредственно в mytable_real происходит без проблем

Какая версия КХ? Железо или докер и прочее? Адреса как ip прописаны или именами (если второе то возможно по хостнейму выдаются разные ip и сервер начинает ходить не туда). Вообще старнное поведение для Distributed, там все очень просто

Какая версия КХ? Железо или докер и прочее? Адреса как ip прописаны или именами (если второе то возможно по хостнейму выдаются разные ip и сервер начинает ходить не туда). Вообще старнное поведение для Distributed, там все очень просто

версия 1.1.54370 стоит не в докере железки по 4 ядра, 16Гб памяти (m4.xlarge) хосты прописаны именами

Какая версия КХ? Железо или докер и прочее? Адреса как ip прописаны или именами (если второе то возможно по хостнейму выдаются разные ip и сервер начинает ходить не туда). Вообще старнное поведение для Distributed, там все очень просто

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

Подскажите пожалуйста хотя бы куда копать Есть два шарда по две реплики КХ на все репликах созданы MergeTree таблицы mytable_real поверх них на всех репликах созданы Distributed таблицы mytable какое-то время все работает хорошо но потом одна из реплик начинает сходить с ума например: - при запросе select count() from mytable выдает ошибку об отсутствии таблицы mytable_real на втором шарде - при insert'e в mytable выдает ошибку об отсутствии колонки в таблице mytable_real. при это колонка присутствует и вставка непосредственно в mytable_real происходит без проблем

Диски разные? Живые?

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

Иногда появялется такая ошибка: >DB::Exception: ZooKeeper session has been expired - какая-то нужная натсройка не устанволена?

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

Пробовали указывать хосты ip-адресами, чтобы отсечь возможные проблемы с резолвером?

multi-query есть параметр

thanks)

Пробовали указывать хосты ip-адресами, чтобы отсечь возможные проблемы с резолвером?

еще нет, но сейчас попробуем

но у нас они прописаны в /etc/hosts

и в zookeeper ip адреса

Пробовали указывать хосты ip-адресами, чтобы отсечь возможные проблемы с резолвером?

это не помогло (

гм, а сабж можно собрать clang 5?

можно

а кто-то это использует у себя?

Подскажите, конкеренткая в ставка к ClickHouse, например, по числу ядер на целевой системе быстрее, чем "однопоточная" вставка? А для replicated-таблиц?

И как реализована поддержка идемпотентности для replicated-таблиц? Не очень понятно, ведь для обычного mergetree такого нет.

Подскажите, конкеренткая в ставка к ClickHouse, например, по числу ядер на целевой системе быстрее, чем "однопоточная" вставка? А для replicated-таблиц?

быстрее. главное, не вставлять суммарно чаще где-то одного блока в секунду. Если в серднем блок вставляется N секунд, то можно вставлять в N потоков.

И как реализована поддержка идемпотентности для replicated-таблиц? Не очень понятно, ведь для обычного mergetree такого нет.

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

а кто-то это использует у себя?

сборку с clang5 тестируем стандартными функциональными тестами. пакеты, если не ошибаюсь, собираем в gcc

быстрее. главное, не вставлять суммарно чаще где-то одного блока в секунду. Если в серднем блок вставляется N секунд, то можно вставлять в N потоков.

Блок = max_insert_block_size число строк? На стороне сервера нет тротлинга? А если вставлять в реплицируемую таблицу? Если есть две реплики, то вставлять в 2 N потоков?

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

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

clcikhouse-copier

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

это копипаста, немного не то мой вопрос связан с появлением DELETE

т.е. есть два шарда, заполненных на 50%, добавляю 3 и ожидаю, что после перешардирования каждый окажется заполнен на 30%

Блок = max_insert_block_size число строк? На стороне сервера нет тротлинга? А если вставлять в реплицируемую таблицу? Если есть две реплики, то вставлять в 2 N потоков?

> Блок = max_insert_block_size число строк? да > На стороне сервера нет тротлинга? не должно быть (могу ошибаться) > Если есть две реплики, то вставлять в 2 N потоков? Если через Distributed, то в N. Можно непосредственно в каждую реплику вставлять разные данные (по N в каждую)

@kochetovnicolai Спасибо!

т.е. есть два шарда, заполненных на 50%, добавляю 3 и ожидаю, что после перешардирования каждый окажется заполнен на 30%

только не 30, а 20, наверное

вы абсолютно правы, я лишь хотел донести мысль

насколько актуальна оценка про UPDATE/DELETE в Q1-Q2 2018?

Хотел спросить тоже по UPDATE/DELETE

То, что в roadmap, пока актуально. https://clickhouse.yandex/docs/ru/roadmap/

а апдейт будет настоящим?

То, что в roadmap, пока актуально. https://clickhouse.yandex/docs/ru/roadmap/

спасибо!

про решардинг правда ничего не нашел, своими силами только если?

а апдейт будет настоящим?

Настоящими. Но не мгновенными. Если очень примерно, что можно будет указать, какие данные и с какими условиями должны быть удалены, а далее в фоне это изменение будет постепенно применяться к кускам. Примерно как мержи. Опять же, возможно я где-то ошибаюсь :)

гарантированно или как в ReplacedMergeTable ?

гарантированно

а это будет новый движок или в простой MergeTable добавите?

про решардинг правда ничего не нашел, своими силами только если?

своими силами или через clcikhouse-copier

а это будет новый движок или в простой MergeTable добавите?

просто в MergeTree

Спасибо kochetovnicolai !

/root/rpmbuild/BUILD/ClickHouse-07718746959cfc85fcb8ffd29d97c8e217b082a2/contrib/poco/Foundation/src/Thread_STD_POSIX.cpp:170:6: error: no matching function for call to 'pthread_setaffinity_np' if (pthread_setaffinity_np(_pData->thread->native_handle(), &cpuset) != 0) ^~~~~~~~~~~~~~~~~~~~~~ /usr/include/pthread.h:477:12: note: candidate function not viable: requires 3 arguments, but 2 were provided extern int pthread_setaffinity_np (pthread_t __th, size_t __cpusetsize,

что-то не выходит каменный цветок

/usr/bin/ld: cannot find -lstdc++ clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) вот оно что, Семен Семеныч

а зачем ему stdc++, когда шланг использует libc++?

просто в MergeTree

А обратно-совместимо или только для таблиц, созданных в новых версиях?

На старых таблицах будет работать. Но после выполнения UPDATE откатиться не получится.

в clickhouse-copier параметр task-path должен иметь какое-то специальное значение? из примера не работает Can't get description node /task/path/description

подскажите плиз, что такое VersionedCollapsingMergeTree?

ReplacingMergeTree сам по себе мерджится если данных для мерджа нет? Ну т.е. я создал новую таблицу, одним запросом туда данные перегнал, и вот уже пол часа жду пока оно поудаляет дубликаты

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

ReplacingMergeTree сам по себе мерджится если данных для мерджа нет? Ну т.е. я создал новую таблицу, одним запросом туда данные перегнал, и вот уже пол часа жду пока оно поудаляет дубликаты

ReplacingMergeTree не дает гарантий отсутствия дубликатов. Но вроде OPTIMIZE фиксит.

ReplacingMergeTree сам по себе мерджится если данных для мерджа нет? Ну т.е. я создал новую таблицу, одним запросом туда данные перегнал, и вот уже пол часа жду пока оно поудаляет дубликаты

насколько я понял, к ReplacingMergeTree нужно относиться как к MergeTree, то есть селектить с учетом того, что там могут быть дубли. ReplacingMergeTree просто экономит место на диске, схлопывая дубли. Но можно, например как я, схлопывать данные сразу после вставки c помощью optimize table partition final, и радоваться костылю :)))

ReplacingMergeTree не дает гарантий отсутствия дубликатов. Но вроде OPTIMIZE фиксит.

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

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

у меня 4 дня не запускалось

Я так понимаю пока я чего-нибудь туда не инсертну чтобы инициировать merge процесс, данные так и будут

пока я снова не начал туда дубли фагачить

у меня 4 дня не запускалось

да это даже ответ на мой вопрос

и в итоге всеравно 5 дублей осталось)

которые даже через optimize table partition final не убирались

если данных не очень много, можно селектить с FINAL

FINAL отбрасывает дубли

у меня 5 всеравно осталось

они потом пропали

значит они на разных шардах, поэтому и не схлопываются

после какойто очередной партии

у меня 1 сервер

ну раз пропали, значит все ок

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

даже на optimize table partition final нельзя надеятся

и нифига не сразу

у меня основная проблема - это когда обновление версии

почти всегда нужно заново залить данные в кх

не буду же я дропать таблицу и ждать полной синхры)