если вы не делаете group by или order by, то вам не нужно чтобы ответ влезал в память. в принципе в случае group by это тоже не всегда обязательно.

я так понимаю тут есть ньюансы ....например у меня есть большой и жирный столбец в виде массива, тогда запрос типа select id, array from table prewhere flag> 15 limit 100 все равно выжирает память потому что array поднимается в память

я так понимаю тут есть ньюансы ....например у меня есть большой и жирный столбец в виде массива, тогда запрос типа select id, array from table prewhere flag> 15 limit 100 все равно выжирает память потому что array поднимается в память

в этом случае надо тюнить max_block_size/max_memory_usage

и если array большой то все равно будет out_of_memory... возможно конечно что КХ умный и поднимет только часть столбца (как указано в документации), но у меня так получается что куски(чанки) в партициях сами по себе по 5 гигов в сжатом состоянии... и у меня лимит в 10 гигов на запрос легко достигается

Правильно ли я понимаю что для отдачи результата select * from table без условий, не обязательно чтобы ответ влезал в память?

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

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

а своп на сервере есть? в него не могло утечь?

в этом случае надо тюнить max_block_size/max_memory_usage

именно это и сделали (max_memory_usage)... но все равно осталось какое-то странное ощущение что где-то что-то не так....

Если select * без условий, и результат пишется например на диск, можно сильно уменьшить потребление памяти, сделав SET max_threads=1. Скорость от этого не должна особо уменьшиться.

Данные целиком в оперативку влезать разумеется не должны

а своп на сервере есть? в него не могло утечь?

вроде не должно. SELECT * FROM table FORMAT Null ^CCancelling query. Query was cancelled. 227672064 rows in set. Elapsed: 215.635 sec. Processed 229.70 million rows, 201.21 GB (1.07 million rows/s., 933.10 MB/s.) KiB Mem: 13200198+total, 13132107+used, 680912 free, 825944 buffers KiB Swap: 0 total, 0 used, 0 free. 10452568+cached Mem

также стоит заметить, что в целом запросы с select * работают медленней "обычных" запросов, т.к. читают все колонки одновременно.

Всем привет :) Такой вопрос по Clickhouse — можно ли как-то быстро искать не по первичному ключу в таблице? Насколько я вижу в документации — вторичных индексов нет...

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

Всем привет :) Такой вопрос по Clickhouse — можно ли как-то быстро искать не по первичному ключу в таблице? Насколько я вижу в документации — вторичных индексов нет...

А уже тестили поиск? Оно у вас действительно долго работает?

похвастаюсь рабочей бд трафика под sflow/netflow/span:) закончил, наконец-то :)

даш потом «позыркать»?

В MySql поиск очень долгий :) 5 млн записей.

Пока просто исследуем вопрос и не тестировали Clickhouse... Возможно у кого-то были схожие случаи

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

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

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

А поиск это что такое? Это равенство, или это LIKE, или это регулярка, или что?

Равенство

Строк

Всем, добрый день. Только начала осваивать CH. Возник вопрос: Не могу понять почему в toDate не учитывается часовой пояс клиента? На сервере UTC TZ=Europe/Moscow clickhouse-client —use_client_time_zone 1 —query="SELECT DISTINCT hour FROM imho_video ORDER BY hour LIMIT 5;" 2017-01-01 00:00:00 2017-01-01 01:00:00 2017-01-01 02:00:00 2017-01-01 03:00:00 2017-01-01 04:00:00 TZ=Europe/Moscow clickhouse-client —use_client_time_zone 1 —query="SELECT DISTINCT toDate(hour) as date FROM imho_video ORDER BY date LIMIT 5;" 2016-12-31 2017-01-01 2017-01-02 2017-01-03 2017-01-04

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

А шустро это насколько? :) Хотя бы примерно)

Минуты, секунды...

10-20 сек без семплирования

На моём сферическом сервере в вакууме из таблички типа LOG в 45 млн строк конкретная запись по условию "равно" нашлась за 0.728 sec.

Не по первичному ключу?

в Log нет первичных ключей

А, ок :)

Корректно работает если только подставлять часовой пояс: TZ=Europe/Moscow clickhouse-client --use_client_time_zone 1 --query="SELECT DISTINCT toDate(hour, 'Europe/Moscow') as date FROM imho_video ORDER BY date LIMIT 5;" 2017-01-01 2017-01-02 2017-01-03 2017-01-04 2017-01-05 Можно обойтись без подставления часового пояса для toDate?

А шустро это насколько? :) Хотя бы примерно)

у меня по таблице в 232млн строк, запрос с LIKE '%some_text%' бегает за 1.066sec. Поле не ключевое

А с поиском по Array бенчмарков ни у кого нет?

В смысле select по полю с Array и выбирать записи где в Array есть нужный элемент

Или это будет очень медленно?

зависит от размера массива

Привет, обновил в debain CH в debain: dpkg -l| grep clickhouse ii clickhouse-client 1.1.54188 amd64 clickhouse-client ii clickhouse-server-base 1.1.54188 amd64 clickhouse-server-base ii clickhouse-server-common 1.1.54188 amd64 clickhouse-server-common Но клиент и сервер другой версии: # clickhouse-client ClickHouse client version 1.1.54187. Connecting to localhost:9000. Connected to ClickHouse server version 1.1.54187. :) select version(); │ 1.1.54187 │

Выложили релиз 1.1.54188. В нём исправление проблемы с OPTIMIZE FINAL и вертикальным мержем. В качестве бонуса также присутствуют NULLS FIRST/LAST, поддержка NULL в функции if, доработки ifNull, nullIf, coalesce. Оптимизация сравнений FixedString в случае размера 16 байт и ещё куча мелочей.

Алексей, а как правильно починить mrk файлы?

Народ вопрос

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

http://pastebin.com/YyYPjJJq

вот так я думаю будет понятен кейс

у меня сейчас реализованы теги , однако хочется делать теги как пару Key - Value, двумерные массывы не подходят

Единсвенное до чего я додумался это под каждый key делать столбец

теги - плохая идея для кликхауса

да, под каждый кей свой столбец - это подход КХ

но если у вас их сотни тысяч... не лучшая это идея в общем

ровно как и юзать КХ как TSDB, это не TSDB в полном смысле этого слова (если он вообще есть).

так же подумал, что возможно стоить делать два столбца key и key_value. Оба столбца типа Array. Данные класть по порядку. Те изначально имеем {'key1': 'val', 'key2': 'val2'}. Писать соотвесвенно в key ['key1', key2] а в key_value ['val', 'val2'] и как то призапросе с помощью indexOf или arrayEnumerate их сравнивать

ровно как и юзать КХ как TSDB, это не TSDB в полном смысле этого слова (если он вообще есть).

это я понимаю

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

там идея гораздо глобальнее обычной TS типа Prometheus или Influx

но если у вас их сотни тысяч... не лучшая это идея в общем

ну ограничение помоему 1500 колонок на таблицу на сколько я помню

возможно путаю с вертикой

есть еще вариант не раскладывать тэги а держать их в одной строке и разгребать через splitByChar

но это как мне кажется фигня какаето

так же подумал, что возможно стоить делать два столбца key и key_value. Оба столбца типа Array. Данные класть по порядку. Те изначально имеем {'key1': 'val', 'key2': 'val2'}. Писать соотвесвенно в key ['key1', key2] а в key_value ['val', 'val2'] и как то призапросе с помощью indexOf или arrayEnumerate их сравнивать

возможно indexOf и arrayEnumerate не нужен. arrayExists(x,y-> x='key1' and y='val', keys,values)

Привет, обновил в debain CH в debain: dpkg -l| grep clickhouse ii clickhouse-client 1.1.54188 amd64 clickhouse-client ii clickhouse-server-base 1.1.54188 amd64 clickhouse-server-base ii clickhouse-server-common 1.1.54188 amd64 clickhouse-server-common Но клиент и сервер другой версии: # clickhouse-client ClickHouse client version 1.1.54187. Connecting to localhost:9000. Connected to ClickHouse server version 1.1.54187. :) select version(); │ 1.1.54187 │

Да, это бага, несоответствие починится в следующем релизе. а версия на самом деле одна.

возможно indexOf и arrayEnumerate не нужен. arrayExists(x,y-> x='key1' and y='val', keys,values)

О ! Круто, спасибо!

Алексей, а как правильно починить mrk файлы?

Здесь два варианта. Первый вариант - в таблице ещё есть кусок с неправильными .mrk файлами. Второй вариант - при запуске сервера, этот кусок был признан повреждённым и был перенесён в директорию broken. Сначала рассмотрим первый вариант: 1. Создать таблицу типа Log такой же структуры, как ваша таблица MergeTree. 2. Вставить туда все данные из вашей таблицы (либо только данные из повреждённых партиций) с помощью INSERT INTO table_log SELECT * FROM table. Перед запросом выставить SET max_threads = 1, merge_tree_uniform_read_distribution = 0 По сути, это бэкап ваших данных. 3. Установить новую версию сервера. Перезапустить сервер. Удалить или сделать DETACH повреждённых данных в таблице MergeTree. Вставить данные из таблицы типа Log, которые мы сохранили на предыдущем шаге.

Добрый день, я пробую создать VIEW с запросом с JOIN двух таблиц, и когда создаю, сразу вставка данных в эти таблицы выдает: "DB::Exception: Not found column value in block. There are only columns:", с чем это может быть связано? Или VIEW должен создаваться только над одной таблицей?

Добрий день

Я пробовал и MATERIALIZED VIEW и обычный и в двух случаях такая ошибка, при вставке в таблицы которые задействованные в запросе для VIEW. Хотя сам VIEW создаеться и работает нормально. Может я что-то не так делаю, создаю таким запросом: https://paste.ofcode.org/32wm2DtaXLwxZeSrpq2VfZp

можно пример вставки который выдаёт ошибку?

Добрый день, я пробую создать VIEW с запросом с JOIN двух таблиц, и когда создаю, сразу вставка данных в эти таблицы выдает: "DB::Exception: Not found column value in block. There are only columns:", с чем это может быть связано? Или VIEW должен создаваться только над одной таблицей?

Кажется вот это оно: https://github.com/yandex/ClickHouse/issues/127

можно пример вставки который выдаёт ошибку?

INSERT самый простой, и за раз вставка до 1к строк INSERT INTO adverts_stats (integration,date,account_id,campaign_id,advert_id,keyword_id,keyword,spent,currency,impressions,clicks,reach,frequency) VALUES ('google-adwords','2017-03-17','1148492832','676317588','148953584045','58335222311','boomuserlist::3555311',0,'UAH',3,0,3,1) И выдает: [10] DB::Exception: Not found column value in block. There are only columns: integration, date, account_id, campaign_id, advert_id, keyword_id, keyword, spent, currency, impressions, clicks, reach, frequency, cpm, cpi, cpc, cpp, ctr, day, month, year

Вставка идет в таблицу: https://paste.ofcode.org/342mTweNeJWSyCQUexxAnRD

Добрый день, я пробую создать VIEW с запросом с JOIN двух таблиц, и когда создаю, сразу вставка данных в эти таблицы выдает: "DB::Exception: Not found column value in block. There are only columns:", с чем это может быть связано? Или VIEW должен создаваться только над одной таблицей?

Похоже на баг. Issue #127. По видимому некорректно отрабатывает AS внутри вложенного селекта ? или как говорят -"это не бага а фича"

а фича-то почему (

!stats

Кто-нибудь сталкивался со следующим исключением: Element of set in IN or VALUES is not a constant expression: toDate

делаю вставку через JDBC 30000 строк (каждая строка с колонокой Date и колонкой Array(String))

Иногда попадаю на это исключение, иногда нет...

Да, в value передаётся (toDate(now()), [array])

где на месте array некоторый строковый массив

Здесь два варианта. Первый вариант - в таблице ещё есть кусок с неправильными .mrk файлами. Второй вариант - при запуске сервера, этот кусок был признан повреждённым и был перенесён в директорию broken. Сначала рассмотрим первый вариант: 1. Создать таблицу типа Log такой же структуры, как ваша таблица MergeTree. 2. Вставить туда все данные из вашей таблицы (либо только данные из повреждённых партиций) с помощью INSERT INTO table_log SELECT * FROM table. Перед запросом выставить SET max_threads = 1, merge_tree_uniform_read_distribution = 0 По сути, это бэкап ваших данных. 3. Установить новую версию сервера. Перезапустить сервер. Удалить или сделать DETACH повреждённых данных в таблице MergeTree. Вставить данные из таблицы типа Log, которые мы сохранили на предыдущем шаге.

Не смог выполнить п. 2. При выборки конкретной партиции(WHERE (toYear(date_t) = 2014) AND (toMonth(date_t) = 11). Ошибка: Code: 9. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Size of filter doesn't match size of column.. Перенес партицию в отдельную таблицу и сделал выборку в Log таблицу без where. Ошибка: Code: 12. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Parameter out of bound in IColumnString::insertRangeFrom method.. Т.к. возможны еще какие то баги, держу в курсе )

такое ощущение, будто clickhouse как-то неудачно парсит выражения и иногда отрезает кусок от toDate или today() функций

Code: 36, e.displayText() = DB::Exception: Element of set in IN or VALUES is not a constant expression: tod

Code: 36, e.displayText() = DB::Exception: Element of set in IN or VALUES is not a constant expression: t

Два разных прохода, одни и те же данные

Ещё на нескольких всё прошло нормально

/stat@combot

combot.org/chat/-1001080295593

Не смог выполнить п. 2. При выборки конкретной партиции(WHERE (toYear(date_t) = 2014) AND (toMonth(date_t) = 11). Ошибка: Code: 9. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Size of filter doesn't match size of column.. Перенес партицию в отдельную таблицу и сделал выборку в Log таблицу без where. Ошибка: Code: 12. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Parameter out of bound in IColumnString::insertRangeFrom method.. Т.к. возможны еще какие то баги, держу в курсе )

Написал в личку.

такое ощущение, будто clickhouse как-то неудачно парсит выражения и иногда отрезает кусок от toDate или today() функций

Так и есть. Обычно INSERT предназначен для вставки готовых данных в заданном формате и не умеет выполнять выражения (такие как toDate(now()) или то же самое - today()). В качестве исключения, возможность выполнять выражения, была добавлена в формат Values. Но эта возможность добавлена в очень ограниченном виде. Во-первых, производительность вставки будет очень низкой. Во-вторых, она работает в пределах размера данных, помещающихся в буфер (~1 МБ), и в случае большего размера, выдаётся недостаточно хорошая диагностика - именно это вы наблюдаете. Поэтому я предлагаю всё-таки указывать конкретное значение даты в виде '2017-03-19'.

Доброго времени суток. Есть distributed табличка, которая смотрит на на три таблички на других серверах. Пишу insert ручками в distributed таблицу - клиент пишет, что все хорошо, вставлена одна запись, однако селект мне не возвращает данные...( При вставке непосредственно в таблицы все хорошо, селект все возвращает. В чем может быть проблема?

После вставки в Distributed таблицу, отправка данных на удалённые серверы производится полностью асинхронно. Если при отправке возникает ошибка, её следует смотреть в логе отправляющего сервера.

После вставки в Distributed таблицу, отправка данных на удалённые серверы производится полностью асинхронно. Если при отправке возникает ошибка, её следует смотреть в логе отправляющего сервера.

А если вставлять в локальные таблицы в произвольном порядке, то перешардирование само произойдёт?

Нет

А вам нужно распределение по ключу шардирования?

у нас rand() стоит