в этот момент /var/lib/clickhouse пуст

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

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

А в чём проблема смонтировать диск куда надо, переместить все данные на этот диск, поправить path в когфиге и перезапустить кликхаус?

я вот про это и справшивал, можно ли путь указать кх

где базы лежат

@qweran

я вот про это и справшивал, можно ли путь указать кх

https://clickhouse.yandex/docs/ru/operations/server_settings/settings.html#path

спасибо

подскажите, пожалуйста, достаточно ли экранировать апостроф и бэк-слэш в запросах, чтобы избежать инъекций?

и есть ли какая-то разница (кроме эстетической) между форматами time BETWEEN 123456778 AND 234556677 и time >= 123456778 AND time <= 234556677 ?

и есть ли какая-то разница (кроме эстетической) между форматами time BETWEEN 123456778 AND 234556677 и time >= 123456778 AND time <= 234556677 ?

Вы когда исполняете BETWEEN из нативного клиента, он показывает переписанный запрос, где запись становится как >= AND <=

спасибо!

а в джоине тоже есть where id =?

Похоже на то ))

а в джоине тоже есть where id =?

а зачем в джоине, он по left join должен прицепить только, которые отфильтрованы

clientID какой тип?

clientID какой тип?

UInt64

У меня точно такая же проблема была. при этом в консоле результат корректный. Я решил, что это косяк тебикса

У меня точно такая же проблема была. при этом в консоле результат корректный. Я решил, что это косяк тебикса

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

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

1ый watch_id всегда равен visit_id так что да, фильтрует корректно, но большие цифры отображает криво

1ый watch_id всегда равен visit_id так что да, фильтрует корректно, но большие цифры отображает криво

Спасибо

Коллеги, а ни у кого не возникло случайно сегодня проблем с обновлением логов за вчера? У меня уже несколько часов запрос висит в статусе created, хотя обычно минут 5 на рассчёт уходит..

у таббикса уже есть issue на эту тему?

сейчас гляну

походу нет

https://github.com/smi2/tabix.ui/issues?utf8=%E2%9C%93&q=is%3Aissue

Я напишу тогда

подскажите, пожалуйста: toStartOfMonth есть, toStartOfHour есть; а toStartOfDay почему-то нету... почему?

правильно ли считать, что toStartOfDay эквивалентно toRelativeDayNum(time) * 60?

правильно ли считать, что toStartOfDay эквивалентно toRelativeDayNum(time) * 60?

а group by toDate(x) не подходит?

подскажите, есть ли jvm либа для tcp общения с CH ?

Коллеги, а ни у кого не возникло сегодня проблем с обновлением логов за вчера? У меня уже несколько часов запрос висит в статусе created, хотя обычно минут 5 на рассчёт уходит.. Просто хочется убедиться, что проблема там, а не тут

а group by toDate(x) не подходит?

а тайм-зона клиента/сервера при этом учитывается?

а тайм-зона клиента/сервера при этом учитывается?

я не помню, проверьте

Коллеги, а ни у кого не возникло сегодня проблем с обновлением логов за вчера? У меня уже несколько часов запрос висит в статусе created, хотя обычно минут 5 на рассчёт уходит.. Просто хочется убедиться, что проблема там, а не тут

не только у вас.

всем привет. linux pm6 4.4.0-97-generic #120-Ubuntu. ClickHouse server version 1.1.54292. стабильный из ppa яндекса. суть в том, во время нагрузочного тестирования грохнул одну из нод (при этом запись продолжилась), после этого все ноды продолжают что-то писать на диск уже 30 минут (причём весьма активно: по 90+ мб/сек, хотя в них точно уже никто не пишет). как такое может быть?

clickhouse-client --query='SHOW PROCESSLIST' выдаёт, что это пишет дистрибьютед нода, на самой ноде та же команда выдаёт, что процессов нет.

Судя по активности дисковой подсистемы - это фоновое сжатие. /dev/mapper/vg--pm1-cl 230283684 101426340 117316660 47% /mnt/click /dev/mapper/vg--pm1-cl 230283684 68251432 150491568 32% /mnt/click Подобная картина проявляется и на других нодах. Описание подобной фитчи в документации не нашел. И почему distributed-нода не прервала процесс записи в неё при выключении ноды без реплики?

мержи происходят в фоне, это нормальное поведение. запись в distributed таблицу по-умолчанию асинхронная. данные сначала буферизуются в файлы, затем отсылаются на другие ноды. Если нода не доступна, то запись продолжается, просто данные для такой ноды остаются на диске (в clickhouse/data/database/distributed_table должны быть данные вида user:password@host:port)

мержи чего? сжатие в смысле?

можно включить синхронную вставку (для Replicated* таблиц): insert_distributed_sync поставить в true в users.xml. тогда ошибка будет непосредственно при вставке

не, у меня без репликации всё

при этом происходит процесс фонового сжатия

почему так?

мержи чего? сжатие в смысле?

CH хранит данные в кусках. Если просто, каждый запрос вставки порождает кусок. Выгоднее иметь мало больших кусков, чем много маленьких. Поэтому в фоне содержимое объединяется в более крупные куски.

ясно, а насколько это влияет на другие запросы?

т.е. просадки по производительности из-за этого не будет?

может быть просадка, конечно, так как ресурсы на мерж тратятся :) но в целом не должно быть критично

а можно отключить это? или квотировать?

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

отключать мержи не стоит, так как если их не делать, то через какое-то время все перестанет работать

ясно

а по второму вопросу?

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

@kochetovnicolai т.е. я правильно понимаю, что дистрибьютед-таблица выполняет функции защиты данных в случае отказа ноды или всех её реплик? а что будет на чтение? она прочитает из этой временной таблицы?

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

нет, из временной таблицы не прочитает

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

да

и с себя удалит?

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

лул

можно, плиз, написать ещё неочевидных для обычных БД вещей

особенно связанных с возможностью про*ба данных или неконсистентной записи/чтения

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

я занимаюсь его тестированием

и честно говоря от кластеризации не в восторге

совсем потерять данные, кажется, нельзя (кроме понятных ситуаций, типа смерти всех реплик). В целом, лучше использовать Replicated таблицы. А также можете вставлять данные с insert_distributed_sync, если нужно знать об ошибках вставки сразу.

ок, вопрос: как более-менее нормально работать с большим кластером? доступим на 20 таблиц по 3 реплики? писать скрипты, которые, будут делать мерджед-таблицы и куски XML-файла?

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

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

(куски XML-файла конфига)

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

Почему через зад? Через ZooKeeper:)

ок, вопрос: как более-менее нормально работать с большим кластером? доступим на 20 таблиц по 3 реплики? писать скрипты, которые, будут делать мерджед-таблицы и куски XML-файла?

может быть это поможет: https://clickhouse.yandex/docs/ru/operations/configuration_files.html?highlight=zookeeper

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

@qweran @kochetovnicolai ещё вопрос: допустим у нас полностью уничтожилась одна реплика, как её восстановить? при попытке создать на новом сервер пишет со стороны зукипера, что такая реплика уже существует. решалось так: удалял всю ветку реплики в зукипере, потом создавал на новой ноде всё также, как на старой, уцелевшая магическим образом цеплялась к новой ноде и реплицировалась в неё

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

думаю, если делать attach таблицы, то не надо удалять ветку зукипера

или физически переложить table_name.sql в из metadata/database/ другой реплики в аналогичное место

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

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

есть саксесс стори, в которой использовался этот мануал https://clickhouse.yandex/docs/en/single/index.html#recovery-after-complete-data-loss , зукипер не трогали, перетаскивали метадату с реплик и создавали файл force_restore_data

не менее жопно

а с мониторингом кто-нибудь что-нибудь делал?

особенно состояния кластера

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

@kochetovnicolai кстати, ты говорит о фоном мердже. а как так получилось, что у меня из 33гб стало после завершения меджа стало 22гб. не слишком ли большая разница?

учитывая, у меня гарантированно уникальные данные

добрый вечер, не нашли способа, и есть вопрос, есть-ли возможность абсолютно отказаться от CLANG в сборке и использовании clickhouse ?

>добрый вечер, не нашли способа, и есть вопрос, есть-ли возможность абсолютно отказаться от CLANG в сборке и использовании clickhouse ? зачем?

>добрый вечер, не нашли способа, и есть вопрос, есть-ли возможность абсолютно отказаться от CLANG в сборке и использовании clickhouse ? зачем?

мне нельзя говорить о причинах, скажем так, это слишком дорого, из-за огромных размеров исходного кода этого самого CLANG

@kochetovnicolai кстати, ты говорит о фоном мердже. а как так получилось, что у меня из 33гб стало после завершения меджа стало 22гб. не слишком ли большая разница?

такое может произойти, так как данные сжимаются