когда используется http интерфейс

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

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

Согласно документации: ставьте оперативу равной объему данных. От себя добавлю - ставьте оперативу по объему данных, которые реально будут постоянно читаться.

для 10 миллионов строк в единственной таблице

сколько оперативки нужно?

сколько оперативки нужно?

Тип строк?

Нужно посчтитать, сколько эти строки займут места

60 колонок в таблице

ну примерно сколько потребуется оперативной памяти?

Согласно документации: ставьте оперативу равной объему данных. От себя добавлю - ставьте оперативу по объему данных, которые реально будут постоянно читаться.

не совсем верное выражение наверное. >ставьте оперативу равной объему данных смысл CH тогда теряется. Можно просто взять любую инмемори базу

Результаты запроса должны помещаться в память

сколько оперативки нужно?

все зависит от того как вы их используете и что вообще с ними происходит. Но я все же предполагаю что у вас память съедает именно мерж. Попробуйте жирными запросами долбануть и немного подождите. Должно уменьшиться занмаемое на диске место и память естественно вычистится

а при выполнении selectов через http интерфейс

оперативу ch не должен кушать получается?

merge ведь не будет выполняться

Почему не должен? В зависимости от запроса

Как минимум, сортировка вроде в памяти идёт

оперативу ch не должен кушать получается?

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

Чем больше оперативы будет выделено, тем быстрее будут произовдиться операции чтения. 10 млн строк это мало. Достаточно выделить оперативу, полностью вмещающую эти 10 млн строк. Всегда ли все 60 колонок будут читаться? Если да, то стоит задуматься о смене логики, так как теряется преимущество столбцовой БД.

Чем больше оперативы будет выделено, тем быстрее будут произовдиться операции чтения. 10 млн строк это мало. Достаточно выделить оперативу, полностью вмещающую эти 10 млн строк. Всегда ли все 60 колонок будут читаться? Если да, то стоит задуматься о смене логики, так как теряется преимущество столбцовой БД.

"Сотни столбцов — это нормально для ClickHouse."

"Сотни столбцов — это нормально для ClickHouse."

Сотни это очень хорошо. Вопрос не в том сколько хранить, а как их использовать. К примеру: если вам всегда нужны все 100 столбцов из 100, то в столбцовой БД нет особого преимущества над строчной. А если нужно 100 из 1000, то столбцовая тут будет иметь серьезное преимущество.

добрый день, подскажите, пожалуйста: пишем в StripeLog в качестве буффера, раз в несколько минут сбрасываем INSERT SELECT * FROM StripeLog в SummingMergeTree сеть была под DDoS и в момент INSERT SELECT прилетело DB::Exception: Cannot allocate block number in ZooKeeper: zkutil::KeeperException: operation timeout повторный INSERT SELECT привел к удвоению некоторых строк

почему не сработала дедупликация? нужно использовать ORDER BY?

for i in *.csv; do echo $i; cat $i | clickhouse-client —query="INSERT INTO hit FORMAT CSV"; done;

а есть ли возможность загружать данные из простых sql файлов?

FORMAT SQL?

Что такое "простой sql файл"? Какой диалект sql?

в sql файле будет insert into table values (), ()

а если просто выполнить его как любой другой запрос, без всякого format

в sql файле будет insert into table values (), ()

>cat dump.sql | clickhouse-client —query=

Тут ведь просто найдо SQL команды отправить в CH, формат: VALUES

for i in *.sql; do echo $i; cat $i | clickhouse-client; done;

вот так сработало

А где можно почитать как сделать nullable колонку?

объявить как Nullable(T)

но в https://clickhouse.yandex/docs/ru/data_types/ действительно нет.

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

Запрос column is null по крайней мере работает

Подскажите плиз, это в версии 1.1.54362 ? Тоже столкнулся, в ченчлогах нет нчиего на эту тему

в ней

просто откатились на версию ниже?

да, на 1.1.54343

Спасибо. я смотрю, там новый stable таг есть, но что-то пока не ясно, что в нем)

объявить как Nullable(T)

Я сделал колонку Nullable(UInt16) DEFAULT NULL, но при инсурте пустого значения оно всё равно в 0 превращется, я что-то не так делаю?

for i in *.sql; do echo $i; cat $i | clickhouse-client; done; залил в базу миллион строк (в каждом файле было 10к строк) htop пишет о том что съедено 1.28Gb оперативки прошло полчаса в логах появляются записи 2018.03.19 11:14:36.052169 [ 17 ] <Trace> default.hit (Data): Renaming temporary part tmp_merge_20131201_20131231_9_117_1 to 20131201_20131231_9_117_1. 2018.03.19 11:14:36.052756 [ 17 ] <Trace> default.hit (Merger): Merged 4 parts: from 20131231_20131231_9_9_0 to 20131207_20131210_117_117_0 2018.03.19 11:14:36.052793 [ 17 ] <Debug> MemoryTracker: Peak memory usage: 866.13 MiB. но htop пишет те же цифры не подскажите, почему оперативная память не высвобождается?

htop не пишет, кем съедено? А то может в кеше осело.

htop пишет что ест clickhouse-server

Аллокаторы же не сразу отдают память ОС. То есть эта память недоступна для ОС, но доступна для аллокаций внутри ClickHouse.

Спасибо. я смотрю, там новый stable таг есть, но что-то пока не ясно, что в нем)

Там фиксы, в частности проблемы с ON CLUSTER. Changelog сделаем.

Там фиксы, в частности проблемы с ON CLUSTER. Changelog сделаем.

Спасибо, пойду собирать 370й значит

for i in *.sql; do echo $i; cat $i | clickhouse-client; done; залил в базу миллион строк (в каждом файле было 10к строк) htop пишет о том что съедено 1.28Gb оперативки прошло полчаса в логах появляются записи 2018.03.19 11:14:36.052169 [ 17 ] <Trace> default.hit (Data): Renaming temporary part tmp_merge_20131201_20131231_9_117_1 to 20131201_20131231_9_117_1. 2018.03.19 11:14:36.052756 [ 17 ] <Trace> default.hit (Merger): Merged 4 parts: from 20131231_20131231_9_9_0 to 20131207_20131210_117_117_0 2018.03.19 11:14:36.052793 [ 17 ] <Debug> MemoryTracker: Peak memory usage: 866.13 MiB. но htop пишет те же цифры не подскажите, почему оперативная память не высвобождается?

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

спасибо

данные обновляются достаточно большими пачками (> 1000 строк), а не по одной строке, или не обновляются вообще; данные добавляются в БД, но не изменяются;

первая строчка имеется ввиду "добавляются" а не "обновляются" слово верно?

первая строчка имеется ввиду "добавляются" а не "обновляются" слово верно?

ну все что можно назвать обновлением в CH это про replasingmergetree, возможно речь о нем

Всем привет! Работаем со следующими данными: Существует порядка 5 млрд. объектов с уникальными идентификаторами object_id, каждый объект участвует в нескольких операциях (порядка 30, порядок операций рандомный). После каждой операции объект и часть его атрибутов изменяются, также меняется state объекта и сохраняется дата текущей (последней) операции operation_date). Соответственно нужно сохранять сам объект и все его атрибуты после каждой операции. Получается порядка 150 млрд. записей. Необходимо быстро в потоковом режиме извлекать строки (или некоторые столбцы), где тот или иной объект находится в текущем state (operation_date максимальна). Группировать по operation_date дорого как по памяти, так и по времени. Решили проанализировать несколько подходов: 1) Отдельно хранить инфу о текущем состоянии объекта. Использовать CollapsingMergeTree, OPTIMIZE TABLE, чтобы перезаписывать объект после каждой операции. 2) Возникла идея использовать внешние словари. Писать в какую-нибудь key-value базу (натипо Mongo или Redis) пары object_id, operation_date и извлекать объекты в текущем состоянии подобным запросом: select count() from object_current_state where operation_datetime = dictGetDateTime('obj_op_date_map', 'operation_datetime', tuple(object_id)) Кто что думает по каждому подходу? Есть ли драйвер для Redis, чтобы использовать его в качестве словаря?

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

Нужно в коде приложения писать/обновлять данные в редис по ключу. Чтоб потом кликхаус их подцеплял и обновлял в хеш таблице только те данные, которые изменились

Всем привет! Работаем со следующими данными: Существует порядка 5 млрд. объектов с уникальными идентификаторами object_id, каждый объект участвует в нескольких операциях (порядка 30, порядок операций рандомный). После каждой операции объект и часть его атрибутов изменяются, также меняется state объекта и сохраняется дата текущей (последней) операции operation_date). Соответственно нужно сохранять сам объект и все его атрибуты после каждой операции. Получается порядка 150 млрд. записей. Необходимо быстро в потоковом режиме извлекать строки (или некоторые столбцы), где тот или иной объект находится в текущем state (operation_date максимальна). Группировать по operation_date дорого как по памяти, так и по времени. Решили проанализировать несколько подходов: 1) Отдельно хранить инфу о текущем состоянии объекта. Использовать CollapsingMergeTree, OPTIMIZE TABLE, чтобы перезаписывать объект после каждой операции. 2) Возникла идея использовать внешние словари. Писать в какую-нибудь key-value базу (натипо Mongo или Redis) пары object_id, operation_date и извлекать объекты в текущем состоянии подобным запросом: select count() from object_current_state where operation_datetime = dictGetDateTime('obj_op_date_map', 'operation_datetime', tuple(object_id)) Кто что думает по каждому подходу? Есть ли драйвер для Redis, чтобы использовать его в качестве словаря?

redis не нужен если у вас эти данные лежат где то снаружи в какой то другой базе. CH сам может их загрузить в память и использовать.

https://clickhouse.yandex/docs/ru/dicts/external_dicts_dict_lifetime/

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

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

можно попробовать сделать HTTP словарь с использованием http://webd.is/#http

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

из того что CH уже умеет из коробки это mysql и все к чему можно подключиться через odbc. Остальное придется как-то прикручивать, например как посоветовали выше, через http словарь

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

ну и если делать по http запросу без keep-alive к http серверу, то там будет взрыв кишки аналогично

Коллеги, а последний стэйбл никто не собирал сам? /root/clickhouse-rpm/rpmbuild/BUILD/ClickHouse-1.1.54370-stable/libs/libdaemon/src/BaseDaemon.cpp:375:26: error: 'BUS_MCEERR_AR' was not declared in this scope case BUS_MCEERR_AR: ^~~~~~~~~~~~~ что-то вылезает. Это у меня со сборкой беда или не у меня?

Коллеги, а последний стэйбл никто не собирал сам? /root/clickhouse-rpm/rpmbuild/BUILD/ClickHouse-1.1.54370-stable/libs/libdaemon/src/BaseDaemon.cpp:375:26: error: 'BUS_MCEERR_AR' was not declared in this scope case BUS_MCEERR_AR: ^~~~~~~~~~~~~ что-то вылезает. Это у меня со сборкой беда или не у меня?

Это у многих. Там исправлено одним из следующих коммитов. Можете взять master.

select * from hit where id = id

допустим в таблице hit лежат три строки

одна sign 1, вторая -1, третья sign 1

и схлопывания еще не произошло

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

argMax(x, (_part_index, sign))

а можно чуть подробнее?

что у вас возвращает select _part_index, sign from hit where id = id?

┌─_part_index─┬─sign─┐ │ 0 │ 1 │ └─────────────

но этот результат уже после схлопывания

посмотрите на пример хита, который еще не схлопнулся, и посмотрите доку на argMax

возможно для вашего случая подойдет.

argMax(x, (_part_index, sign))

что означает x?

та колонка из hits, которую вы хотите заселектить.

я хотел бы * заселектить

select argMax(lead_id, (_part_index, sign)) from hit where id = '5aaf95d45422c';

вот так да работает

я хотел бы * заселектить

Пишите argMax... для каждой колонки

SELECT argMax(tuple(*), 1) FROM ( SELECT 1 AS a, 2 AS b ) ┌─argMax(tuple(a, b), 1)─┐ │ (1,2) │ └────────────────────────┘

но это выглядит как хак даже для меня.

к тому же на выходе будет одна колонка вместо нескольких.

Всем привет. Подскажите как бороться с такой багой: При использовании LIMIT N BY ... не дает использовать агрегацию на уровне выше. Пример: SELECT count() FROM (SELECT parent_id, count() as c, id, date FROM example WHERE date between today()-30 and today() GROUP BY id, parent_id, date ORDER BY date, parent_id, count() desc LIMIT 10 BY date, parent_id ) При этом, если заменить count() на *, то все работает. Ошибка: "Code: 10, e.displayText() = DB::Exception: Not found column date in block. There are only columns: parent_id, e.what() = DB::Exception"

Если убрать LIMIT BY, то тоже работает

а если в hit новое поле добавить

updated_time

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

select * from hit where id = "x" order by updated_time desc