внешние словари вроде целиком данные все подсасывают каждые N секунд, в зависимости от лайфтайма и того, запрашивали их или нет а потом просто в оперативке хранятся в течение своего TTL (так происходит в случае с flat, hashed) а для cache описывается, как доп.запросы будут происходить https://clickhouse.yandex/docs/ru/single/index.html#cache

INSERT INTO table2 SELECT * FROM table1 DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB (attempt to allocate chunk of 524288 bytes), maximum: 9.31 GiB.

и что делать с большими таблицами?

через внешний файл только?

ну можно кусками инсертить же

INSERT INTO table2 SELECT * FROM table WHERE date BETWEEN '2017-05-01' AND '2017-05-31';

ну... закат солнца вручную конечно

но для CH походу это норма и фича

ща попробуем так

INSERT INTO table2 SELECT * FROM table1 DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB (attempt to allocate chunk of 524288 bytes), maximum: 9.31 GiB.

сам запрос у вас потоковый, но если у вас тяжелые строки, а в случае select * так может быть, то нужно чтобы за один раз в память читалось не слишком много строк.

ну и ограничение делать вот по редложению Игоря?

я бы покрутил что-то вроде max_block_size

нда... суточные данные не всегда проходят

либо еще дробить либо как-то системно

значит max_block_size, говорите

а этот параметр можно на уровне сесси установить?

но как-то из описания не очень вериться, что это поможет

перечитал еще раз

да похоже оно

спасибо за наводку

спасибо за наводку

Ещё поставьте max_threads = 1. Для INSERT SELECT без фильтрации большее количество не имеет смысла.

извините что фигню посоветовал (

ды не почему

норм

просто у меня данные вылезают

в другом случае может и прокатило бы

но это более системный вариант походу

ща нащупаю размеры оптимальные и запущу

А decompress=1 какие компрессии поддерживает? Через gzip прогнать ок?

а вот при таком массовом insert-е как merge работает? Я правильно ожидаю, что после копирования новая таблица будет иметь больше part-ов чем исходная (в которой достаточно старые данные)?

и как следствие больше размер и менее эффективная

А decompress=1 какие компрессии поддерживает? Через gzip прогнать ок?

decompress=1 поддерживает только внутренний формат сжатия. Для использования gzip, указывать его не нужно. Вместо этого просто используйте HTTP заголовок. https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00302_http_compression.sh

а вот при таком массовом insert-е как merge работает? Я правильно ожидаю, что после копирования новая таблица будет иметь больше part-ов чем исходная (в которой достаточно старые данные)?

Да, после копирования таблица может иметь больше part-ов. Мержи работают примерно так же, как при обычных INSERT-ах, хотя и более оптимально если вставляются уже сортированные данные (это так при INSERT SELECT без преобразований, и с выставленной настройкой max_threads=1).

у меня изменился немного PK

это преобразование?

Да. Если сортированность данных по PK меняется, то будет несколько менее оптимально по CPU.

спасибо за пояснения!

ну так писал миловидов их начальник по clickhouse

Да, отчёты Метрики строятся налету из неагрегированных данных, хранящихся в ClickHouse. Это работает одинаково, как для свежих, так и для старых данных. Отдельных примочек для свежих данных нет, кэшей нет, предагрегации тоже нет.

Да, отчёты Метрики строятся налету из неагрегированных данных, хранящихся в ClickHouse. Это работает одинаково, как для свежих, так и для старых данных. Отдельных примочек для свежих данных нет, кэшей нет, предагрегации тоже нет.

А после выборки есть какая то постобработка? Есть же какая то бизнес-логика поверх данных

Да, отчёты Метрики строятся налету из неагрегированных данных, хранящихся в ClickHouse. Это работает одинаково, как для свежих, так и для старых данных. Отдельных примочек для свежих данных нет, кэшей нет, предагрегации тоже нет.

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

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

У меня 850 млн строк и достаточно массивные запросы отрабатывают не дольше 150мс

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

Очень странно, что у вас все так долго (

эм.. тогда я точно не понимаю в чем дело

а какой сервер? может какие-то настройки сервера отличные от тех что по умолчанию?

Я нормальное распределение считаю по 500 млн буквально за 50мс )

у меня много группировок по строковым типам

У нас три шарда по 32 ядра, 96 гигов оперативы и по 300 гигов ссд. Это виртуалки.

Может есть смысл сделать внешний словарь и перевести строки в числа? Что-то типа предварительной подготовки данных

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

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

сервер 4 ядра и 8 гигов ram. это конечно в 10к раз хуже вашего

Ну я первый раз гонял КХ на сервере с один ядром и 4 гигами оперативы :) Навалил туда 2.5 ярда )

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

магия

Действительно странно

вот элементарный пример

SELECT count(*) FROM xxx

7 сек чтобы посчитать количество ... это норм?

http://img.facedsid.ru/6ea9j.jpg

не тормозит

это в 4 раза медленее. но это запрос на сервере. а если отправлять запрос на порт 8123 то 7 сек

и у вас 18 rows/s у меня почему-то 3 rows/s

диски ssd

У нас сложная бизнес-логика и нам приходится какие то данные агрегировать и "кешировать", но данные мы выбираем асинхронно, порядка 10-11 одновременных запросов в КХ. Таких инстансов, делающих асинхронные запросы на данный момент 50 штук.

Все летает

но на примере обычного теста я отстаю в 4 раза. это как объяснить?)

Возможно все таки кол-во потоков играет определенную роль :)

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

есть мониторинг

только что смотреть. памяти хватает. проц съедают потоки clickhouse-server. место есть

iops не упирается в диск

вот еще раз выполнил запрос

уже почти 0.5

в среднем от 0.2 до 0.5

А ещё к слову, мне тут что то подумалось, что индекс же должен влиять в том числе на скорость group by, даже если нет фильтрации. Разве нет?

Я, к сожалению не спец по кишкам КХ, но я думаю должен

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

В том числе и группировки стали шустрее работать

Ну логика говорит что должен влиять в общем :)

группировки по ключу?

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

Просто по этим же колонкам приходится еще фильтр делать

В ключе у меня 4 колонки всего

Дата, идентификатор сайта, идентификатор пользователя и действие которое пользователь совершил

Когда перекладываем данные, то они частично сортированы и пишутся пачками по 100 000 строк в 200 потоков :) Потолок в 10млн строк в минуту не пробил, т.к. монга быстрее не отдает

а сколько у вас дисков, от 100->200 потоков было какое-то увеличение в скорости?

У нас по одному диску на каждом шарде. Скорость увеличивалась по мере увеличения потоков на запись

Причем чуть ли не линейно )

а, вы не в одну машину пишете

В три

Точнее в одну распределенную таблицу

А данные уже по шардам расползаются сами

Сейчас из-за бага с broken pipe пишу по серверам напрямую, но там не больше 10к строк раз в 10 минут )

Большими порциями мы архивные данные гоняем в КХ, такое практикуем раз в месяц где то

Сейчас есть release candidate. В stable ещё не попало, так как много заморочек с выкладкой на наши серверы. Из последнего тега testing уже можете собирать.

А инструкции по сборке deb пакетов есть у вас?