как-то так?

Ага, видимо так) я всю документацию пролистал в поисках нужной функции, а все оказалось гораздо проще)

Спасибо

подскажите, есть что-то типа ф-и getCurrentClusterNodeHostname? (Надо понять как в распределенной таблице данные по нодам кластера распределены)

hostName() так и работает :)

Но вот например version() уже не пробрасывается

hostName() так и работает :)

Спасибо!

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E0C56BD4

Что-то у меня не сработало Executing: /tmp/apt-key-gpghome.URPkrEgwdb/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv E0C56BD4 gpg: connecting dirmngr at '/tmp/apt-key-gpghome.URPkrEgwdb/S.dirmngr' failed: IPC connect call failed gpg: keyserver receive failed: No dirmngr Ubuntu 18.04

Кто-то использует внешний словарь из постргреса с SSL? Сейчас попытался настроить, но запрос к словарю роняет КХ с segmentation fault.

Всем привет! После обновления ch столкнулся вот с такой проблемой: SELECT any(rows), active FROM ( SELECT any(rows), active FROM parts GROUP BY active LIMIT 1 ) Received exception from server (version 1.1.54388): Code: 47. DB::Exception: Received from 10.60.21.118:9000. DB::Exception: Unknown identifier: rows. При этом, если во вложенном запросе объявить алисы или просто сделать select * во внешнем, все отрабатывает отлично. Это ожидаемое поведение? На предидущей версии все работало отлично.

"Исправлена деградация производительности запросов, содержащих выражение IN (подзапрос) внутри другого подзапроса (#2571)." а вот многоуровневые JOIN все еще тормозят?

как вот это можно обойти, когда надо собрать в итоговую таблицу из кучи микротабличек других по тем или иным ключам? 1. несколько джойнов подряд нельзя – Support for more than one JOIN in query is not implemented 2. многоуровненые селект с 1 джойном на каждом уровне – громозодко и на каком-то этапе начинает тормозить 3. из словарей собрать – не совсем удобно на живых данных, микротаблички эти на лету генерятся

Всем привет! После обновления ch столкнулся вот с такой проблемой: SELECT any(rows), active FROM ( SELECT any(rows), active FROM parts GROUP BY active LIMIT 1 ) Received exception from server (version 1.1.54388): Code: 47. DB::Exception: Received from 10.60.21.118:9000. DB::Exception: Unknown identifier: rows. При этом, если во вложенном запросе объявить алисы или просто сделать select * во внешнем, все отрабатывает отлично. Это ожидаемое поведение? На предидущей версии все работало отлично.

ну наконец-то это поправили select count() from (select count() from numbers(5) group by number) ┌─count()─┐ │ 5 │ └─────────┘ select `count()` from (select count() from numbers(5) group by number) ┌─count()─┐ │ 1 │ │ 1 │ │ 1 │ │ 1 │ │ 1 │ └─────────┘

как вот это можно обойти, когда надо собрать в итоговую таблицу из кучи микротабличек других по тем или иным ключам? 1. несколько джойнов подряд нельзя – Support for more than one JOIN in query is not implemented 2. многоуровненые селект с 1 джойном на каждом уровне – громозодко и на каком-то этапе начинает тормозить 3. из словарей собрать – не совсем удобно на живых данных, микротаблички эти на лету генерятся

Если генерятся на лету, то соберите на клиенте - это не удобно, но будет работать

Всем привет! После обновления ch столкнулся вот с такой проблемой: SELECT any(rows), active FROM ( SELECT any(rows), active FROM parts GROUP BY active LIMIT 1 ) Received exception from server (version 1.1.54388): Code: 47. DB::Exception: Received from 10.60.21.118:9000. DB::Exception: Unknown identifier: rows. При этом, если во вложенном запросе объявить алисы или просто сделать select * во внешнем, все отрабатывает отлично. Это ожидаемое поведение? На предидущей версии все работало отлично.

Оно так и должно работать

Доброе утро! @ztlpn , подскажи, пожалуйста, есть ли способ смержить старые партиции, в которые нападало немного данных? Ну, типа, OPTIMIZE по партиции. Сейчас на ~10Мб данных остаётся ~15-20 директорий, хотелось бы упаковать в одну

Alter table T optimize partition X final

Продолжение проблем с MV. В пятницу выяснилось что вьюхи над распределенной таблицей не есть хорошо и хоть создать ее можно и вроде как явно не запредено но это не есть гуд (хотя как ускорить без этого мой конкретный кейс там и не придумалось без этой вьюхи). Сегодня я эти вьюхи поубовал и оставил только лолкальные и распределенные таблицы и также вьюху семплирования вот такую, вроде бы она создана нормально ``` CREATE MATERIALIZED VIEW default.MetricsSampledView ( appId UInt32, metricId UInt32, timestamp UInt32, value Float64, `tags.name` Array(UInt32), `tags.value` Array(UInt32)) ENGINE = ReplicatedMergeTree(\'/clickhouse/tables/metrics/{shard}/MetricsSampledView\', \'{replica}\') PARTITION BY floor(timestamp / 86400) ORDER BY (appId, metricId, timestamp) SETTINGS index_granularity = 8192 AS SELECT * FROM default.Metrics WHERE (intHash32(timestamp) % 20) = 0 ``` Распределенная таблица над вьюхой соответственно ``` CREATE TABLE default.MetricsDistributedSampledView ( appId UInt32, metricId UInt32, timestamp UInt32, value Float64, `tags.name` Array(UInt32), `tags.value` Array(UInt32)) ENGINE = Distributed(metrics, default, MetricsSampledView, rand()) ``` Начал тестирование, прибил одну ноду из 8. На сопряженной (где реплика) начался рост партиции, мержи не шли, словил исключение о том что много частей и мержи не успевают. Батч процесс начал перевстявлять и наполучал дубликатов опять Ладно, хорошо. прибил эту последнюю вьюху и повторил тест и все прошло как надо, мержи идут и дупликатов нет Что не так с вьюхами? Я их неправильно объявляю или они слегка поломаны?

Alter table T optimize partition X final

спасибо!

пересоздал вью с TO и вроде как заработало. Что это так запланировано?

А кто знает какой нужно указать null_value в словаре для типа Date? 0000-00-00 не работает, впрочем как и любое другое значение. Валится в readDateTextFallback :(

А кто знает какой нужно указать null_value в словаре для типа Date? 0000-00-00 не работает, впрочем как и любое другое значение. Валится в readDateTextFallback :(

'000-00-00'

'000-00-00'

Не ) Оказалось, что просто нули сработали. Ошибка была дальше в словаре. Оказалось, что там еще один Date-атрибут.

подскажите что не так. есть несколько шардов. по две реплики. все в одном кластере. в system.clusters определено все верно. делаю alter table … add column … on cluster … и получаю ошибку Code: 371. DB::Exception: Received from localhost:9000, ::1. DB::Exception: There was an error on HOST_NAME: An error occured before execution: Code: 371, e.displayText() = DB::Exception: Table test is replicated, but shard #1 isn't replicated according to its cluster definition, e.what() = DB::Exception. тож самое для модификации таблицы. Если делать на одной реплике в шарде (без on cluster`) все проходит успешно. версия везде `1.1.54385.

/ Aa

С Alex Zatelepin повозились с моим кейсом, непонятно что происходит. При стопании КХ другая реплика перестает мержить с такими ошибками, │ .inner.MetricsSampledView │ Not executing log entry for part 722f7ee72516522ffdfc83494465fd4e_3890_4300_141 because another log entry for the same part is being processed. This shouldn\'t happen often. │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused │ │ .inner.MetricsSampledView │ Not merging into part 722f7ee72516522ffdfc83494465fd4e_3890_4306_147 because part 722f7ee72516522ffdfc83494465fd4e_3890_4305_146 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused │ │ .inner.MetricsSampledView │ Not merging into part 722f7ee72516522ffdfc83494465fd4e_3890_4313_154 because part 722f7ee72516522ffdfc83494465fd4e_3890_4312_153 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused │ │ .inner.MetricsSampledView │ Not executing log entry for part 722f7ee72516522ffdfc83494465fd4e_3890_4320_156 because another log entry for the same part is being processed. This shouldn\'t happen often. │ │ │ .inner.MetricsSampledView │ Not merging into part 722f7ee72516522ffdfc83494465fd4e_4328_4333_1 because part 722f7ee72516522ffdfc83494465fd4e_4328_4328_0 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused │ │ .inner.MetricsSampledView │ Not merging into part 722f7ee72516522ffdfc83494465fd4e_3890_4327_158 because part 722f7ee72516522ffdfc83494465fd4e_3890_4326_157 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused │ Притом лидерство перекинулось нормально Что делать непонятно

Создавать тикет?

Дубликаты опять же никуда не делись если есть Вьюха Без виюхи их нет

Создавать тикет?

Да, думаю стоит завести issue.

Спсб Завел https://github.com/yandex/ClickHouse/issues/2755

как включить clickhouse-local ? это утилита по умолчанию есть в докер образе ?

Подскажите, а в чем может быть проблема, если запрос вида select count(*) from stats where message_id='71bcb9de-b87c-42a3-953b-07cecbdfe2fe' выполняется 300 секунд? при этом если аналогичный запрос по другому полю делать, то запрос отрабатывает быстро

а того аналогичного поля слуяайно в ПК нет?

а того аналогичного поля слуяайно в ПК нет?

нет

CREATE TABLE stats ( id String, entry_id String, project_id String, message_id String, client_id String, event String, datetime DateTime, date Date, user_agent String ) ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/stats', '{replica}stats', date, id, 8192 )

вот такая структура, второе поле по которому поиск делал entry_id

Оба ваши запроса не используют ПК, т.е. идёт фулл скан. Отсюда скорее всего ответ такое - быстрый запрос выполнился быстро, поскольку данные есть в памяти. А медленый - данные не были

Покажите на каждый запрос сколько строки и байт прочитано

Вероятно, поле entry_id сжимается хорошо, а message_id — нет, поэтому такая разница. Например по полю Date будет всё ещё быстрее, я уверен.

Вероятно, поле entry_id сжимается хорошо, а message_id — нет, поэтому такая разница. Например по полю Date будет всё ещё быстрее, я уверен.

+1

да, поле message_id совсе почти не сжалось

да, поле message_id совсе почти не сжалось

Во-первых храните его в FixedString(16) SELECT length('71bcb9de-b87c-42a3-953b-07cecbdfe2fe'), length(UUIDStringToNum('71bcb9de-b87c-42a3-953b-07cecbdfe2fe')), UUIDNumToString(UUIDStringToNum('71bcb9de-b87c-42a3-953b-07cecbdfe2fe')) ┌─length(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\')─┬─length(UUIDStringToNum(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\'))─┬─UUIDNumToString(UUIDStringToNum(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\'))─┐ │ 36 │ 16 │ 71bcb9de-b87c-42a3-953b-07cecbdfe2fe │ └──────────────────────────────────────────────────┴───────────────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────┘ Во-вторых можно добавить нужные поля в индекс ПС: ну и числовые идентификаторы при прочих равных тоже сильно быстрее могут быть

Здравствуйте, по https://clickhouse.yandex/docs/en/query_language/dicts/external_dicts_dict_sources/#example-of-connecting-postgresql не хватает тега <yandex> в примере словаря в Постгресе

Действительно не хватает, спасибо

Во-первых храните его в FixedString(16) SELECT length('71bcb9de-b87c-42a3-953b-07cecbdfe2fe'), length(UUIDStringToNum('71bcb9de-b87c-42a3-953b-07cecbdfe2fe')), UUIDNumToString(UUIDStringToNum('71bcb9de-b87c-42a3-953b-07cecbdfe2fe')) ┌─length(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\')─┬─length(UUIDStringToNum(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\'))─┬─UUIDNumToString(UUIDStringToNum(\'71bcb9de-b87c-42a3-953b-07cecbdfe2fe\'))─┐ │ 36 │ 16 │ 71bcb9de-b87c-42a3-953b-07cecbdfe2fe │ └──────────────────────────────────────────────────┴───────────────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────┘ Во-вторых можно добавить нужные поля в индекс ПС: ну и числовые идентификаторы при прочих равных тоже сильно быстрее могут быть

там к сожалению не uuid, но направление понял под индксом подразумевается первичный ключ? А частичный поиск по нему работает, если в фильтрации не будут использованы некоторые колонки, которые в нем используются?

Подскажите, а в чем может быть проблема, если запрос вида select count(*) from stats where message_id='71bcb9de-b87c-42a3-953b-07cecbdfe2fe' выполняется 300 секунд? при этом если аналогичный запрос по другому полю делать, то запрос отрабатывает быстро

если заменить where на prewhere ? можно сделать mv ( message_id, date, id) order by message_id и запрос переписать в select count(*) from stats where id,date in (select id,date from mv where message_id='71bcb9de-b87c-42a3-953b-07cecbdfe2fe') and message_id='71bcb9de-b87c-42a3-953b-07cecbdfe2fe'

там к сожалению не uuid, но направление понял под индксом подразумевается первичный ключ? А частичный поиск по нему работает, если в фильтрации не будут использованы некоторые колонки, которые в нем используются?

Да, частичный работает

Коллеги, добрый день. подскажите по ошибке Received exception from server (version 18.1.54396): Code: 171. DB::Exception: Received from localhost:8124, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different number o f columns: COLUMN1 String String(size = 0) COLUMN2 String String(size = 0), COLUMN1 String String(size = 0)

Коллеги, добрый день. подскажите по ошибке Received exception from server (version 18.1.54396): Code: 171. DB::Exception: Received from localhost:8124, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different number o f columns: COLUMN1 String String(size = 0) COLUMN2 String String(size = 0), COLUMN1 String String(size = 0)

Запрос покажите, у вас случаем не разный набор колонок в SELECT-ах для UNION?

Запрос SELECT COLUMN1 from TABLE WHERE COLUMN2='A' LIMIT 100

Но причина ошибки уже ясна. LIMIT. Без лимита ошибки нет. Спасибо.

Но причина ошибки уже ясна. LIMIT. Без лимита ошибки нет. Спасибо.

Есть пример чтоб воспроизвести, это достаточно страно чтоб лимит так афектил?

Это воспроизводится если обе колонки имеют NULL значения. (Наврал. Не в этом причина. Если смогу воспроизвести выложу кейз). Если вместо where использовать prewhere то работает и с лимитом

А откуда может взяться таймаут на выполнение запроса в 120 секунд, вроде ни в конфиге кх нет, и в библиотеке доступа из руби в кх тоже нет таймаута, а по дефолту вроде 300 секунд в кх.

подскажите по groupArray, если я применяю его к 2м колонкам(v, t), получу ли я в итоге колонки вида: [v1, v3, v2], [t1, t3, t2] или же это будет: [v3, v1, v2], [t2, t3, t1]?

подскажите по groupArray, если я применяю его к 2м колонкам(v, t), получу ли я в итоге колонки вида: [v1, v3, v2], [t1, t3, t2] или же это будет: [v3, v1, v2], [t2, t3, t1]?

i-ый элемент полученных массивов будет относиться к одной и той же строке исходных данных

i-ый элемент полученных массивов будет относиться к одной и той же строке исходных данных

отлично, спасибо

А почему в исходниках ClickHouse комментарии через три слеша, а не два? :)

написано было что для Doxygen вроде, но он не используется

А... Понял, спасибо.

тот случай, когда в КХ не жалеют байты

А этот уже просто по привычке.

Я, собсно, не просто так, пусть и понимаю, шо менять не будут. Просто доставляет при копипасте исходника в другой язык (имена констант соблюсти, местами логику) немножко колбасит эти слешики уничтожать.

Подскажите пожалуйста, создаю materialized view из таблицы SELECT * FROM db1.transactions ALL INNER JOIN ( SELECT ED1_ID, max(ED1_UPLOAD_TIMESTAMP) ED1_UPLOAD_TIMESTAMP FROM db1.transactions GROUP BY ED1_ID, ) USING (ED1_ID, ED1_UPLOAD_TIMESTAMP) А при добавлении в таблицу db1.transactions значений, они не добавляются в materialized view Хотя в документации написано, что при изменении данных в исходной таблице - данные materialized view тоже добавляются.

Добрый день, коллеги! Делаю выборку: select request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - одна строка. Затем подставляю в селекте вместо request_id некоторую константу, но с тем же условием: select 'new_request_id' as request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - пусто. Это баг или так и задумано?

Добрый вечер! Подскажите как реализовать rank() partition by? У меня получилось только так https://hastebin.com/obajexinib.sql

На конференции по ClickHouse в Питере через неделю можно будет найти Яндекс колонку? :)

На конференции по ClickHouse в Питере через неделю можно будет найти Яндекс колонку? :)

Нет, там поставки от нас никак не зависят. Хотя на всякий случая я спрошу, вдруг что-нибудь получится.

Здравствуйте, коллеги. Не подскажете, есть какие-то методики расчёта оптимальной конфигурации кластера (и железа)? условно, по 800 миллионов записей в день, порядка 10 колонок, хочется семи-реалтайма на селектах с group by по 3-6 колонкам

у нас 7 колонок, 7млрд записей в день запросы по последним нескольким дням до месяца 8 машинок * 8 ядер - 64ГБ - 1.9ТБ ССД

у нас 7 колонок, 7млрд записей в день запросы по последним нескольким дням до месяца 8 машинок * 8 ядер - 64ГБ - 1.9ТБ ССД

у нас с собой было: семь колонок, семь миллиардов записей в день. мы знали, рано или поздно мы перейдем на клик-хаос

какой самый безопасный способ обновиться на самую актуальную версию КХ? как при этом сохранить возможность откатиться на текущую установленную? (кх standalone, ubuntu 16)

по идее там один бинарник, можно тупо его сохранить

which clickhouse-client ?

а, они там еще все симлинки на один /usr/bin/clickhouse

у нас 7 колонок, 7млрд записей в день запросы по последним нескольким дням до месяца 8 машинок * 8 ядер - 64ГБ - 1.9ТБ ССД

И сколько rps