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

Всем привет. Я пытаюсь пристрелить сервер с кликхаусом. Стреляя прямо в 8123 порт. Тут вижу, https://overload.yandex.net/9324 что ответы начинают таймаутиться, но судя по мониторингу, в проц я упираюсь не очень уверенно - какими-то пиками. На вкладке мониторинга поядерная статистика и есть cpu-cpu-total. Вероятно я упираюсь во что-то в кликхаусе, в логах такие ошибки 2017.02.21 13:58:56.127662 [ 2819 ] <Error> executeQuery: Code: 24, e.displayText() = DB::Exception: Cannot write to ostream, e.what() = DB::Exception

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

Что значит на стадии мерджа? Есть опции max_bytes_before_external_group_by и max_bytes_before_external_sort

Когда объединяются большие таблицы, насколько я понимаю.. Памяти не хватает, чтобы запомнить все данные. Ставлю большие значения параметрам, думает..

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

Что значит на стадии мерджа? Есть опции max_bytes_before_external_group_by и max_bytes_before_external_sort

Писал выше. На стадии мерджа результатов внешнего group_by. Вот выдержка из лога: 2017.02.21 13:02:31.482351 [ 21 ] <Trace> ParallelAggregatingBlockInputStream: Will merge 1546 temporary files of size 76261.6 MiB co mpressed, 291198 MiB uncompressed. После этого - срабатывание лимита.

Экспериментально выяснил, что aggregation_memory_efficient_merge_threads = 1, но получается довольно медленно. Пробую поставить 2 и посмотреть, что будет.

Тогда max_bytes_before_external_group_by можно попробовать

я уже писал: │ max_memory_usage │ 25000000000 │ 1 │ │ max_bytes_before_external_group_by │ 10000000000 │ 1 │ │ max_bytes_before_external_sort │ 10000000000 │ 1 │ │ max_threads │ 8 │ 1 │

Вот смотрю на эксперимент - aggregation_memory_efficient_merge_threads = 2 работает, сильно быстрее, чем с 1, но память прям на пределе.

не посдскажите, а нет ли в Clickhouse, что-то похожего на хранимые процедуры?

Нет

спасибо

Вот тут детали можно почитать https://github.com/yandex/ClickHouse/issues/32

спасибо

Добрый день! Скажите, имея сейчас один сервер КХ, можно ли на его основе сделать кластер не теряя данные? И можно ли по ходу работы масштабировать кластер?

Вот ещё ответ хороший https://github.com/yandex/ClickHouse/issues/11#issuecomment-226350266

Добрый день! Скажите, имея сейчас один сервер КХ, можно ли на его основе сделать кластер не теряя данные? И можно ли по ходу работы масштабировать кластер?

Короткий ответ - да, конечно можно

В перспективе что будет, реплики, шарды илито и то?

А нет ли наглядного примера как поднять кластер с нуля?

хотим 3 шарда, в каждом по 2 реплики

читал, что там необходимо использовать ZooKeeper

или можно и без него обойтись?

Если есть реплики - ЗК обязателен

А нет ли наглядного примера как поднять кластер с нуля?

Думаю нет, но это не очень сложно

Нужно ли будет при заведении шардов перешардировать текущие данные?

много ли их?

у нас 3 таблицы

в сумме 4млрд строк

на одной из таблиц есть materialized view

4 млд строк - на самом деле очень мало. Самое простое решение будет потом поднять ещё 5 машин, завести на всех 6ти серверах новые таблицы Replicated + Distributed, а пом просто сделать на первом INSERT INTO Distributed_ТАБЛИЦА from select * from старая таблица

планируем кластер поднять с 0, а текущую машино с КХ - в расход ?

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

Нет. Можно на сервере создать distributed таблицу которая ссылается на другой кластер

Надо только конфиг это кластера добавить

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

хмм, интересный подход

скажите, а как быть с materialized view? Надо тоже делать из него Distributed?

а если вьюшка это SummingMergeTree?

и кстати, я читал, что можно на каждом сервере создать Distributed таблицу

и тогда за данными можно ходить на любой из серверов

получается, если у нас будет 3 шарды в каждом по 2 реплики, то это 6 машин

можно Distributed таблицу создать на всех 6-ти?

Я бы сказал нужно

у нас есть лод балансер, теоретически можно тогда распределить нагрузку на 6 машин

и да, таблицы с движками Memory могут быть Distributed?

получается, если у нас будет 3 шарды в каждом по 2 реплики, то это 6 машин

correct me if i'm wrong, но мне кажется, для этого должно быть достаточно трех машин (должно получиться даже на две запихнуть, но это криминал и разброс нагрузки 2:1)

в смысле? собрать кластер на 2 серверах?

1 шарда из 2-х реплик?

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

возможно, я просто неправильно воспринимаю слово шард

в шардах ранятся разные данные

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

*хранятся

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

Если есть три шарда (= куска данных) с фактором репликации = 2, то три сервера обычно берут на себя конфигурацию следующим образом: host 0:[s0:0, s2:1], host 1:[s1:0, s0:1], host 2:[s2:0. s1:1], где s1:1 - это шард #1, реплика #1. Я думаю, кликхаус в этом не должен отличаться от других приложений.

Так можно, но с определёнными сложностями в настройке

вот тут было обсуждение: https://groups.google.com/forum/#!msg/clickhouse/GFl04GsTNZg/UvIfdGjuBQAJ

поэксперементировал с словарями в монге. выяснилось что ошибка с 2017.02.20 15:58:51.040516 [ 6 ] <Error> HTTPHandler: Code: 293, e.displayText() = DB::Exception: Cannot authenticate in MongoDB: server returned response for 'authenticate' command that has field 'ok' missing or having wrong value, e.what() = DB::Exception, Stack trace: возникает только начиная с 1.1.54127. на 1.1.54112 словари подгружаются. но сильно трейсят.

теперь можно собрать с новой poco и получить рабочую монгу - https://github.com/yandex/ClickHouse/commit/1c1b6ce9f52cbc9929ffb7e50afe3450b9ccd341

теперь можно собрать с новой poco и получить рабочую монгу - https://github.com/yandex/ClickHouse/commit/1c1b6ce9f52cbc9929ffb7e50afe3450b9ccd341

нее. я из тех людей которые верят вендорской сборке. подожду вполне :)

но спасибо да

Скажите, на сколько мощным должен быть сервер под ZooKeeper?

ноды КХ кластера - 15 Гб рам, 4 вЯдра

В принципе, raspberry pi должно быть достаточно

В принципе, raspberry pi должно быть достаточно

Добавите в доументацию эту рекомендацию? :-)

На самом деле, от размера кластера зависит

У нас довольно большие железки стоят для кластера из 400+

Но по памяти там не так страшно, гигов 10-20 вроде

По объёму диска не важно, проц там тоже не особо жмётся если я правильно помню

Но хорошо бы SSD

То есть на вашем масштабе zk интенсивно но ввод/вывод фигачит?

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

Если я все правильно помню

Ребята говорят, для лога транзакций

Надо чтобы он быстро сбрасывался

Но у нас нагрузка большая, да

Добрый день. Установил clickhouse, при попытке выполнить любую операцию пишет ошибку: root@server:/etc/clickhouse-server# /etc/init.d/clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator root@server:/etc/clickhouse-server# service clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator {start|stop|status|restart|forcestop|forcerestart|reload|condstart|condstop|condrestart|condreload|initdb} root@server:/etc/clickhouse-server# cat /etc/issue Ubuntu 14.04.4 LTS \n \l можете подсказать как исправить? Спасибо) Если открыть файл /etc/init.d/clickhouse-server всё выглядит правильно.

Добрый день. Установил clickhouse, при попытке выполнить любую операцию пишет ошибку: root@server:/etc/clickhouse-server# /etc/init.d/clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator root@server:/etc/clickhouse-server# service clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator {start|stop|status|restart|forcestop|forcerestart|reload|condstart|condstop|condrestart|condreload|initdb} root@server:/etc/clickhouse-server# cat /etc/issue Ubuntu 14.04.4 LTS \n \l можете подсказать как исправить? Спасибо) Если открыть файл /etc/init.d/clickhouse-server всё выглядит правильно.

замени первую строку на #!/bin/bash

вроде у них есть бага о том что не надо использовать башизмы и #!/bin/sh

Спасибо, помогло.

По результатам замеров json* значительно медленнее tsv & CSV для Format

но блин настолько удобнее

Добрый день. Установил clickhouse, при попытке выполнить любую операцию пишет ошибку: root@server:/etc/clickhouse-server# /etc/init.d/clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator root@server:/etc/clickhouse-server# service clickhouse-server status /etc/init.d/clickhouse-server: 303: [: status: unexpected operator {start|stop|status|restart|forcestop|forcerestart|reload|condstart|condstop|condrestart|condreload|initdb} root@server:/etc/clickhouse-server# cat /etc/issue Ubuntu 14.04.4 LTS \n \l можете подсказать как исправить? Спасибо) Если открыть файл /etc/init.d/clickhouse-server всё выглядит правильно.

именно это место уже поправлено и в следующем релизе само заработает

Скажите, нужно ли вносить какие-то изменения в конфиг ZooKeeper после установки, или там все работает из кробоки? Просто в туториале - этот момент не оговорен...

https://raw.githubusercontent.com/yandex/ClickHouse/master/doc/administration/tips.txt

With default settings, ZooKeeper have time bomb: "A ZooKeeper server will not remove old snapshots and log files when using the default configuration (see autopurge below), this is the responsibility of the operator." You need to defuse the bomb.

Дмитрий, спасибо!

А напомните, пожалуйста, что делает параметр distributed_group_by_no_merge?

Борюсь с запросами, где group by по десятку полей, часть из которых вызов словарей и, возможно, джойны. Вертика их как семечки щелкает, а кликхаус уходит в астрал

У меня подозрение, что весь group by происходит на initiator node, вместо того чтобы на шардах сделать большую часть работы

А напомните, пожалуйста, что делает параметр distributed_group_by_no_merge?

https://github.com/yandex/ClickHouse/blob/master/dbms/include/DB/Interpreters/Settings.h#L118

О, а я уронил clickhouse. Прибил по Ctrl-C в clickhouse-client создание VIEW. debian, clickhouse-{client,server-{base,common}}-1.1.54159 http://pastebin.com/eXEumprX