А localhost резолвится вообще? Если попробовать ping localhost?

curl http://localhost:9018/ping Ok.

Да, с этим проблем нет: ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.010 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.031 ms

Посмотрел код ещё раз. Действительно будет стрелять для odbc hashed-словарей и без invalidate_query. Фикс уже есть, скоро соберём релиз.

Посмотрел код ещё раз. Действительно будет стрелять для odbc hashed-словарей и без invalidate_query. Фикс уже есть, скоро соберём релиз.

Спасибо, ждем!

Подозреваю что вопрос уже был и не раз, но всё же: первичный ключ в *MergeTree таблицах. Использую CollapsingMergeTree, соответственно должен добавить в ключ колонку с id-шником, а у него высокая кардинальность (практически уникальный). Стоит ли вместо (xx,xxx,xxxx,id) сделать (xx,xxx,xxxx,hash(id),id), где hash(id) понизит кардинальность такого поля на несколько порядков ( (xx,xxx,xxxx) обладает малой кардинальностью)? Конечно hash(id) больше index_granularity во многих случаях, в каких случаях это даст выигрыш в производительности? hash(id) не очень дорогая функция.

Привет. Подскажите пожалуйста, а как вытащить последний не нулевой элемент массива в ячейке? У меня есть столбец с массивами, но все они разной длины. Если беру просто arr[-1], то он мне почти везде 0 выдает.

Привет. Подскажите пожалуйста, а как вытащить последний не нулевой элемент массива в ячейке? У меня есть столбец с массивами, но все они разной длины. Если беру просто arr[-1], то он мне почти везде 0 выдает.

select arrayFilter(x -> x !=0, [1,2,3,0,2,0])[-1];

select arrayFilter(x -> x !=0, [1,2,3,0,2,0])[-1];

Спасибо огромное!

select arrayFilter(x -> x !=0, [1,2,3,0,2,0])[-1];

Подскажи, что значит эта часть? [1,2,3,0,2,0]

Подскажи, что значит эта часть? [1,2,3,0,2,0]

Это сам массив

Аааа, всё спс.

всем привет. это нормально, что текущая партиция в system.parts содержит на 2 порядка больше кусков, чем предыдущая? 1000 против 30-40 на ровном месте повалили мержи, пытаюсь разобраться, почему

Подскажите, как в кликхаус сделать следующий запрос из постгреса https://dumpz.org/cYffQYBgRsBc То есть в нем, я для каждого dimension1 получаю цену с самой последней датой.

Подскажите, как в кликхаус сделать следующий запрос из постгреса https://dumpz.org/cYffQYBgRsBc То есть в нем, я для каждого dimension1 получаю цену с самой последней датой.

ORDER BY datetimeadded DESC LIMIT 1 BY dimension1

SELECT * FROM system.metrics WHERE metric = 'MemoryTracking' ┌─metric─────────┬────────value─┬─description──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ MemoryTracking │ -69765993365 │ Total amount of memory (bytes) allocated in currently executing queries. Note that some memory allocations may not be accounted. │ └────────────────┴──────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ скажите, а это фича или баг? Версия КХ - 18.12.13

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

tsf-data24.us.com :) select * from system.events; SELECT * FROM system.events ┌─event───────────────────────────────────┬───────────value─┐ │ Query │ 68848667 │ │ SelectQuery │ 101904153 │ │ InsertQuery │ 513217 │ │ FileOpen │ 2778419186 │

ORDER BY datetimeadded DESC LIMIT 1 BY dimension1

Спасибо

Не пойму в чем прикол. Есть таблица в которой есть столбец с типом "Date". Вставляю в него текущее UnixTime время, потом смотрю селектом что вставилось. А там 2020-08-06

Взял время из интернета, тогда показал вообще 2020-03-16

а зачем вы время вставляете в Date

в Date надо вставлять дату

Бля

точно

ссорян

за мат

спасибо =)

этож не datetime

а зачем вы время вставляете в Date

Спасибо !

Коллеги, а не подкажете в какую сторону копать на тему "2018.09.13 14:40:54.368711 [ 8 ] <Error> dnl_int.dnl_log_local (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 10, e.displayText() = DB::Exception: Not found column size in block. There are only columns: , e.what() = DB::Exception" - колонка такая в самой таблице конечн же есть. Ругается на много подобных таблиц и только на поле size. С какой стороны начинать поиск?

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

Всем привет. Подскажите пожалуйста формат отправки метрик с тегами в carbon-clickhouse чем то отличается от нативного в graphite? Пробую вот так echo "my.awesome.metric1;tag1=sd;tag2=xz 11 $(date +%s)" | nc -w0 carbon-clickhouse 2003 и ничего не падает в кх.

не уверен что вопрос про кх, пойду продублирую в метрики его

подскажите, пожалуйста, нужно сделать INSERT SELECT FROM CROSS JOIN - все время упираюсь в нехватку памяти. Он то ли всю таблицу в голове пытается удержать, не пойму. Отдельные строки вроде большие, но не запредельные...

подскажите, пожалуйста, нужно сделать INSERT SELECT FROM CROSS JOIN - все время упираюсь в нехватку памяти. Он то ли всю таблицу в голове пытается удержать, не пойму. Отдельные строки вроде большие, но не запредельные...

Пытается

Пытается

А в файл выгрузить и загрузить не поможет? Все равно сначала в памяти создаст?

А вам правда нужен именно CROSS джойн?

Обычно в КХ хранят таблицы размерами в несколько миллионов строк (или миллиардов / триллионов). При CROSS джойн "на выходе" количество строк равно количеству строк в первой таблице, умноженному на количество строк в другой таблице. Если миллионы умножать на миллионы то сложно ожидать что в памяти поместится.

У меня нетипичный случай. 10000 строк. Может правда что-то другое подойдёт лучше. Кстати, он что-то успевает насовать, хоть и падает. Наверно строки тяжёлые. Массивы.

ок, а нет ли какого-то условия для сужения слияния? Вам точно нужно именно каждый с каждым?

Мне нужно все разные пары. Но с условием на различие падает ещё быстрее. Я пробовал поэтапно делать, с промежуточными таблицами.

Методом тыка удалось создать реплицируемую таблицу

CREATE TABLE lexa_test ( id Int64, i_env Int64, i_customer Int64, i_account Int64, creation_date Date ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/lexa_test', '{replica}', creation_date, creation_date, 8192)

но что это за параметры такие

creation_date, creation_date

если их не указывать

не создается реплицируемая таблица

ключ партицирования и праймери кей

это обязательные параметры получается ?

ну а как движок будет без них то

У меня нетипичный случай. 10000 строк. Может правда что-то другое подойдёт лучше. Кстати, он что-то успевает насовать, хоть и падает. Наверно строки тяжёлые. Массивы.

единственный вариант выполнить 10000 insert для каждой строки по 1.

Ладно я знаю что такое первичный ключ

а что такое ключ партицирования ? простыми словами

для чего он нужен ?

не пойму

Я просто хочу перевезти все текущие таблицы в реплицируемые. И сделать это максимально безболезнено. То есть по пути наименьшего сопротивления. Хочу обойтись минимальным количеством дополнительных параметров при создании реплицируемой таблицы.

единственный вариант выполнить 10000 insert для каждой строки по 1.

скриптом? или есть какое-то заклинание?

а что такое ключ партицирования ? простыми словами

чтобы виртуально разделить таблицу на несколько ( для ускорения select и для простоты управления таблицей ). у вас два клиента -- партиционируем по клиенту ( select where client = 1 затрагивает пол таблицы, клиент ушел, дропаем все его данные одной командой ) . Или партиционируем по-месячно, и запросы затрагивающие один, два... месяца ускоряются, и данные страше 4 месяцев легко удалить. Первичный ключ для уменьшия занимаего места на диске, из-за сортировки, и опять-же для некоторого ускорения select.

скриптом? или есть какое-то заклинание?

скриптом

чтобы виртуально разделить таблицу на несколько ( для ускорения select и для простоты управления таблицей ). у вас два клиента -- партиционируем по клиенту ( select where client = 1 затрагивает пол таблицы, клиент ушел, дропаем все его данные одной командой ) . Или партиционируем по-месячно, и запросы затрагивающие один, два... месяца ускоряются, и данные страше 4 месяцев легко удалить. Первичный ключ для уменьшия занимаего места на диске, из-за сортировки, и опять-же для некоторого ускорения select.

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

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

логично там дате ложить

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

хуже того, можно указать любую комбинацию выражений, это базовый и очень мощный инструмент. partition by (x%2, a, sha666(d)) patrition by tuple()

добрый день Имеется следующая ситуация: Linux Debian-94-stretch-64-LAMP 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 x86_64 GNU/Linux Версия КХ - 1.1.54394 Результат df -h: Filesystem Size Used Avail Use% Mounted on udev 32G 0 32G 0% /dev tmpfs 6.3G 506M 5.8G 8% /run /dev/md2 2.0T 974G 907G 52% / tmpfs 32G 4.0K 32G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 32G 0 32G 0% /sys/fs/cgroup /dev/md1 488M 38M 424M 9% /boot /dev/md3 42T 14T 27T 34% /home tmpfs 6.3G 0 6.3G 0% /run/user/1005 tmpfs 6.3G 0 6.3G 0% /run/user/1001 tmpfs 6.3G 0 6.3G 0% /run/user/0 Я далек от администрирования и не очень соображаю в устройстве raid, но КХ явно хранит данные в /dev/md2, а хотелось бы конечно использовать память из /dev/md3. Подскажите пожалуйста, можно ли это изменить в настройках КХ или следует менять что-то в ОС? Уместно ли спросить о каких-то best practice в данном случае?

я бы смонтировал в линуксе md3 в /var/lib/clickhouse

Тут всплыла подсказка, при ошибочном создании таблицы типа ReplicatedMergeTree ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) То есть вместо EventDate я должен указать из своей таблицы столбец с датой А вместо (CounterID, EventDate, intHash32(UserID), EventTime) указать стоблец с первичным ключом. Верно понимаю ?

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

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

Скажите пожалуйста, а где в этом тексте ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) PrimaryKey ?

первичный ключ -- это ключ сортировки, его назвали неправильно в КХ, чтобы всех запутать.

Это была не единственная причина )

первичный ключ -- это ключ сортировки, его назвали неправильно в КХ, чтобы всех запутать.

Так где получается в этом списке ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Primary Key ?

Это EventDate ? или CounterID ?

не пойму

(CounterID, EventDate, intHash32(UserID), EventTime)

Так где получается в этом списке ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Primary Key ?

Это старый синтаксис, тут дата - это ключ партиционирования, потом ключ семплирования и сам ПК он задает сортировку

должно быть партиционирование по EventDate, семплирование по intHash32(UserID), сортировка по (CounterID, EventDate, intHash32(UserID), EventTime)

(CounterID, EventDate, intHash32(UserID), EventTime)

Так значит

понял

не просто

сложно даже)

спасибо всем !

=)

Используй новый синтаксис он понятнее будет)

А где его почитать ?

А где его почитать ?

https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/

https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/

Вот про это речь ? ENGINE [=] MergeTree() [PARTITION BY expr] [ORDER BY expr] [SAMPLE BY expr] [SETTINGS name=value, ...]

Где Order By - это первичный ключ

Где Order By - это первичный ключ

Угу

Понял. Спасибо, буду игратся)

я бы смонтировал в линуксе md3 в /var/lib/clickhouse

т.е. сделать /dev/md3 mounted on /var/lib/clickhouse? а где в таком случае будет храниться то что уже есть в /home ?

ну так перенесите куда-нибудь, откуда я знаю куда вам надо

но само хранение данных КХ в любом случае не вариант никуда переносить, верно?

Все разобрался. Вдруг кто то такой же глупый как и я, будет искать пример создания по новому синтаксису, таблицы на движке Replicated Merge Tree. Поясняю. ============================== CREATE TABLE lexa_test ( id Int64, i_env Int64, i_customer Int64, i_account Int64, creation_date Date ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/lexa_test', '{replica}') PARTITION BY creation_date ORDER BY id в PARTITION BY нужно указать имя столбца с типом данных Date а в ORDER BY нужно указать стоблец который будет первичным ключом #пример #ReplicatedMergeTree #новый #синтаксис