А кликхаус ещё не умеет кластер без зукипера?

Прекрасно умеет и всегда умел

отлично!

ЗК нужен только для репликации.

Добрый день. Сейчас ClickHouse ожидает таймаут от зукипера равным 30000, и если сервер прислал больший, возникает такое исключение. В мастере это поправили. Пока единственная возможность побороть проблему - подкрутить таймауты у зукипера.

спасибо. Похоже мы где-то с конфигами напартачили, скопировали старые конфиги

ЗК нужен только для репликации.

Репликация мне тоже нужна, т.е. получется без зукипера не работает. Очень плохо!

спасибо. Похоже мы где-то с конфигами напартачили, скопировали старые конфиги

Нет, это скорее проблема с новой клиентской библиотекой зукипера, которую не заметили раньше.

а вот смотрите, у меня пишутся логи посещений в кх, где с некоторой долей приближения уникальные посещения (где уникальность определяется чисто комбинаций IP+UA) в рамках сайта выделяются такой конструкцией SELECT * FROM logs LIMIT 1 BY IP , UA, HOST если я из этого делаю SELECT * FROM logs ORDER BY TimeStamp LIMIT 1 BY IP , UA, HOST так я получаю самые первые вхождения этого пользователя на сайт. я правильно рассуждаю?

на первый взгляд все верно

а вот можно ли как-то также элегантно получить уникальные "сессии", когда между заходами пользователя прошло больше Х минут? в первом приближении можно конечно добавить DateStamp, тогда в пределах суток получим "уникальность" сессий, плюс ошибка когда сессия на границе суток. если добавить разбивку по toStartOfHour, будет точнее, но таких ошибок пограничных станет очень много. подозреваю, что тут нужны timeSlots но пока не осознаю как красиво сделать.

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

Это выглядит сложнее. Возможно, получится посчитать с использованием runningDifference. В целом, есть презентация на похожую тему: https://github.com/yandex/clickhouse-presentations/blob/master/meetup9/funnels.pdf

спасибо, буду ковырять

У меня ещё вопрос есть. Я переодически получаю: "DB::Exception: Too many simultaneous queries. Maximum: 100". При том, что я выставил в конфиге <max_concurrent_queries>500</max_concurrent_queries> и перезагрузил КХ. Почему не применилось? И какой вообще нормальный диапазон для этой настройки? Я могу выставить 10к или 1М? На что это влияет?

подскажите, а если я делаю ReplicatedMergeTree, а поверх нее я хочу сделать AggregatingMergeTree, то мне нужно делать сначала ReplicatedMergeTree, поверх нее Distributed а потом на Distributed вешать ReplicatedAggregatingMergeTree ?

сделайте отдельные таблицы и пишите в обе

я select буду делать только из AggregatingMergeTree

ну а зачем вам тогда мерджтри нужна

мы думали сделать MATERIALIZED VIEW с движком AggregatingMergeTree

Кто-нибудь думал о том как жить с GDPR. К примеру - клиент хочет чтобы удалили логи...

да вроде по старому живем

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

Кто-нибудь думал о том как жить с GDPR. К примеру - клиент хочет чтобы удалили логи...

У нас схема "Звезда", таблицы измерений по пользователям храним в MySQL. Оттуда удалить не проблема

Привет, есть результат UNION ALL из двух SELECT: ┌─id────────┬─count─┐ │ 1258 │ 6 │ │ 1510 │ 8 │ └───────────┴───────┘ ┌────────id─┬─count─┐ │ 1258 │ 3 │ │ 1510 │ 2 │ └───────────┴───────┘ Как для каждого id произвести арифметические действия с count, т.е. например чтобы получить (count1/count2): 1258 | 2 1520 | 4

Уже всю голову сломал

Репликация мне тоже нужна, т.е. получется без зукипера не работает. Очень плохо!

Смотря для чего используется репликация. Если для обеспечения доступности кластера в случае выхода из строя реплики, то без репликации сложно обойтись. Если для обеспечения сохранности данных в случае выхода из строя системы хранения данных, то можно обойтись без репликации, если записывать данные на сторейдж с защитой от выхода из строя типа как persistent storage в гугл клауде.

Либо, может есть другие способы считать такие вещи?

Привет, есть результат UNION ALL из двух SELECT: ┌─id────────┬─count─┐ │ 1258 │ 6 │ │ 1510 │ 8 │ └───────────┴───────┘ ┌────────id─┬─count─┐ │ 1258 │ 3 │ │ 1510 │ 2 │ └───────────┴───────┘ Как для каждого id произвести арифметические действия с count, т.е. например чтобы получить (count1/count2): 1258 | 2 1520 | 4

сделать вместо union join?

Либо, может есть другие способы считать такие вещи?

может заменить union на подзапрос?

union бежит параллельно, хотелось бы поэффективнее )

Конечно не ахти, но работает SELECT user, sum(count_1) / sum(count_2) FROM ( SELECT 1258 AS user, toInt64(6) AS count_1, toInt64(0) AS count_2 UNION ALL SELECT 1258 AS user, toInt64(0) AS count_1, toInt64(3) AS count_2 ) GROUP BY user ┌─user─┬─divide(sum(count_1), sum(count_2))─┐ │ 1258 │ 2 │ └──────┴────────────────────────────────────┘

union бежит параллельно, хотелось бы поэффективнее )

можно попробовать извартиться чере runningDifference

Конечно не ахти, но работает SELECT user, sum(count_1) / sum(count_2) FROM ( SELECT 1258 AS user, toInt64(6) AS count_1, toInt64(0) AS count_2 UNION ALL SELECT 1258 AS user, toInt64(0) AS count_1, toInt64(3) AS count_2 ) GROUP BY user ┌─user─┬─divide(sum(count_1), sum(count_2))─┐ │ 1258 │ 2 │ └──────┴────────────────────────────────────┘

Хм, интересная мысль, ща попробуем )

У меня ещё вопрос есть. Я переодически получаю: "DB::Exception: Too many simultaneous queries. Maximum: 100". При том, что я выставил в конфиге <max_concurrent_queries>500</max_concurrent_queries> и перезагрузил КХ. Почему не применилось? И какой вообще нормальный диапазон для этой настройки? Я могу выставить 10к или 1М? На что это влияет?

Обычно значения max_concurrent_queries больше 4 приводят к замедлению выполнения запросов, т.к. один запрос по умолчанию может загрузить половину ядер процессора. Два одновременных запроса могут загрузить весь процессор. Т.к. запросы редко выполняются синхронно, то часть ядер может какое-то время простаивать. Поэтому 4 одновременных запроса точно загрузят проц работой на 100%, если все данные для запросов находятся в файловом кэше. БОльшее количество одновременных запросов приведет к замедлению их выполнения, т.к. они будут бороться друг с другом за процессорное время. Поэтому лучше выставить max_cocurrent_queries в 4, а перед кликхаусом поставить chproxy с настройкой очереди ожидания запросов. Т.е. если придет больше 4 одновременных запросов, то 4 будут выполняться, а остальные будут ожидать своей очереди

Обычно значения max_concurrent_queries больше 4 приводят к замедлению выполнения запросов, т.к. один запрос по умолчанию может загрузить половину ядер процессора. Два одновременных запроса могут загрузить весь процессор. Т.к. запросы редко выполняются синхронно, то часть ядер может какое-то время простаивать. Поэтому 4 одновременных запроса точно загрузят проц работой на 100%, если все данные для запросов находятся в файловом кэше. БОльшее количество одновременных запросов приведет к замедлению их выполнения, т.к. они будут бороться друг с другом за процессорное время. Поэтому лучше выставить max_cocurrent_queries в 4, а перед кликхаусом поставить chproxy с настройкой очереди ожидания запросов. Т.е. если придет больше 4 одновременных запросов, то 4 будут выполняться, а остальные будут ожидать своей очереди

Спасибо!

Конечно не ахти, но работает SELECT user, sum(count_1) / sum(count_2) FROM ( SELECT 1258 AS user, toInt64(6) AS count_1, toInt64(0) AS count_2 UNION ALL SELECT 1258 AS user, toInt64(0) AS count_1, toInt64(3) AS count_2 ) GROUP BY user ┌─user─┬─divide(sum(count_1), sum(count_2))─┐ │ 1258 │ 2 │ └──────┴────────────────────────────────────┘

Спасибо, работает )

Обычно значения max_concurrent_queries больше 4 приводят к замедлению выполнения запросов, т.к. один запрос по умолчанию может загрузить половину ядер процессора. Два одновременных запроса могут загрузить весь процессор. Т.к. запросы редко выполняются синхронно, то часть ядер может какое-то время простаивать. Поэтому 4 одновременных запроса точно загрузят проц работой на 100%, если все данные для запросов находятся в файловом кэше. БОльшее количество одновременных запросов приведет к замедлению их выполнения, т.к. они будут бороться друг с другом за процессорное время. Поэтому лучше выставить max_cocurrent_queries в 4, а перед кликхаусом поставить chproxy с настройкой очереди ожидания запросов. Т.е. если придет больше 4 одновременных запросов, то 4 будут выполняться, а остальные будут ожидать своей очереди

А chproxy он только select-ы умеет оптимизировать или множество мелких insert-ов он сможет в балк собрать и в КХ записать?

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

слишком много постоянных соединений?

слишком много постоянных соединений?

А каким образом оно связано?

А каким образом оно связано?

Наверняка CH тоже не особо очищает буферы под HTTP (или другой протокол), которые используются при вставке в это соединение

Примерно как с мемкешом

Наверняка CH тоже не особо очищает буферы под HTTP (или другой протокол), которые используются при вставке в это соединение

Вижу 500 коннектов на процессе, но они все inter-server внутри кластера.

Я не знаю, спрашивали ли, но не планируется ли в ClickHouse аналоги vbr из комлекта HP Vertica для бэкапа кластера?

вариант с Select не предлагать, терабайты данных в пожатом виде, про RAW вообще умолчу )

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

а сколько памяти у сервера и что с параметром max_memory_usage ?

а сколько памяти у сервера и что с параметром max_memory_usage ?

<max_memory_usage>10000000000</max_memory_usage>, у сервера всего 256G

<max_memory_usage>10000000000</max_memory_usage>, у сервера всего 256G

можно смотреть что КХ думает про используемую им память SELECT metric, formatReadableSize(value) FROM system.asynchronous_metrics where (metric LIKE 'generic%') и можно смотреть сколько памяти жрут мержи, у меня однажды вышло в данных так, что мержу надо было очень много памяти, больше чем ее было у сервера. select formatReadableSize(memory_usage) m,* from system.merges order by m desc

можно смотреть что КХ думает про используемую им память SELECT metric, formatReadableSize(value) FROM system.asynchronous_metrics where (metric LIKE 'generic%') и можно смотреть сколько памяти жрут мержи, у меня однажды вышло в данных так, что мержу надо было очень много памяти, больше чем ее было у сервера. select formatReadableSize(memory_usage) m,* from system.merges order by m desc

Спасибо, попробуем последить, пока за короткий промежуток наблюдений, ничего такого нет, все мержи не более 200MB.

Добрый день. Поставил Clickhouse из репозитария Яндекс на OpenSUSE Leap 15.0. service clickhouse-server start висит 12-13 сек и завершается При этом в /var/log/clickhouse-server/ логи не создаются, в /var/lib/clickhouse/ файлы и подкаталоги не создаются journalctl -x выдает только: — The process /usr/bin/clickhouse-server could not be executed and failed. — — The error number returned by this process is 3. Jun 18 16:06:46 webW systemd[1]: clickhouse-server.service: Main process exited, code=exited, status=217/USER Jun 18 16:06:46 webW systemd[1]: clickhouse-server.service: Unit entered failed state. Jun 18 16:06:46 webW systemd[1]: clickhouse-server.service: Failed with result 'exit-code'.

clickhouse-server —config-file=/etc/clickhouse-server/config.xml при этом нормально запускается...

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

а systemd запускает от какого пользователя?

Что еще посмотреть?

а systemd запускает от какого пользователя?

а, да, наверное в этом дело. clickhouse.clickhouse...

а, да, наверное в этом дело. clickhouse.clickhouse...

sudo -u clickhouse 'clickhouse-server —config-file=/etc/clickhouse-server/config.xml'

я уже понял... не было таких u/g

tnx

А chproxy он только select-ы умеет оптимизировать или множество мелких insert-ов он сможет в балк собрать и в КХ записать?

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

Вот это спам

Добрый день, тестирую CH с Distributed таблицами, на тестах с 20 потоками с выборкой за месяцы получаю ClickHouseUnknownException: ClickHouse exception, code: 1002, host: 127.0.0.1, port: 8123; 127.0.0.1:8123 failed to respond на одной из НОД нахожу в логе 2018.06.18 05:42:39.284854 [ 102 ] <Error> executeQuery: Code: 210, e.displayText() = DB::NetException: Connection reset by peer while writing to socket (172.26.101.132:35852)

и стектрейс Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x45d5226] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0x25f068f] 2. clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x274) [0x45f5914] 3. clickhouse-server(DB::WriteBuffer::next()+0x26) [0x25ff5d6] 4. clickhouse-server(DB::TCPHandler::processOrdinaryQuery()+0x4ad) [0x25fb88d] 5. clickhouse-server(DB::TCPHandler::runImpl()+0x4e0) [0x25fdd70] 6. clickhouse-server(DB::TCPHandler::run()+0x1c) [0x25fe9ec] 7. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x47ee56f] 8. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x110) [0x47eebd0] 9. clickhouse-server(Poco::PooledThread::run()+0x77) [0x4a08f57] 10. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x38) [0x4a066b8] 11. clickhouse-server() [0x4b027cf] 12. /lib64/libpthread.so.0(+0x7dc5) [0x7f86c298fdc5] 13. /lib64/libc.so.6(clone+0x6d) [0x7f86c1d4673d] 2018.06.18 05:42:39.310318 [ 21 ] <Warning> TCPHandler: Client has gone away. 2018.06.18 05:42:39.335951 [ 102 ] <Warning> TCPHandler: Client has gone away.

я так понимаю это надо какую то настройку Distributed tables увеличить, чтобы дожидалось ответа от НОДы ... или все иначе?

благодарю за уделенное время

запрос выполнялся 90 секунд. Но до этого были и другие забпрос , выполнявшиеся и по 110 секунд, они были успешны

а тут череда фейлов

Товарищи, а есть способ КХ сбросить кэши ? У меня сейчас была ситуация, при которой КХ подъел всю свободную память в RSS, при этом, судя по всему, не мог нормально выделить новые куски и тормозил люто

Похоже, что дело в uncompresses cache

В целом - его работа меня устраивает, но есть ли способ очистить память вручную ?

Посоны, у меня clickhouse не стартует. В папочке job_searches похоже столько файлов скопилось, что я ещё даже через ls открыть не могу. Что там в этой папке находится? Можно это дропнуть безболезненно?

Посоны, у меня clickhouse не стартует. В папочке job_searches похоже столько файлов скопилось, что я ещё даже через ls открыть не могу. Что там в этой папке находится? Можно это дропнуть безболезненно?

если /var/lib/clickhouse/data/*/job_searches - то это данные таблицы job_searches

ага.. хм..

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

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

Подозреваю, что не очень правильно. Этот КХ мне в наследство достался.

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

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

Ну вот он упал и не поднимается.

Есть возможность зачинить это как-то?

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

да, я так и делаю сейчас. А в дальнейшем данные можно востановить будет? Тула может есть какая-то?

я бы включил trace в логах кх и посмотрел чего он делает при старте, скорее всего из-за тормозов фс он не может считать их чтобы смержить. если оно все память поместится, то может быть на какую-нить in-memory фс всю базу закинуть? и оставить на ночь )

du -sh я тоже не могу сделать, что-бы сказать поместится оно или нет.

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

Может issue завести?

или попробовать КХ попатчить, или мердж за него сделать?

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

при обработке запроса возникла ситуация, когда кх сообщил memory limit exceeded. При этом сообщил он о превышении лимита у профиля default, а у пользователя был свой, бОльший лимит, поставленный некоторое время назад, до апгрейда на версию 54381. Эт

о сейчас что, мЕньший лимит применяется?

Или баг и смотрится только лимит у default?

или попробовать КХ попатчить, или мердж за него сделать?

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

Где можно почитать как будет работать Update/delete?

Где можно почитать как будет работать Update/delete?

Насчет DELETE: ALTER TABLE table_name DELETE WHERE id=1

А с точки зрения внутренностей? Синтаксис меня мало интересует, интересую нюансы

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

В replicated merge tree

Товарищи, а есть способ КХ сбросить кэши ? У меня сейчас была ситуация, при которой КХ подъел всю свободную память в RSS, при этом, судя по всему, не мог нормально выделить новые куски и тормозил люто

Похоже, что дело в uncompresses cache