такая ошибка, это неправильно составлен конфиг словаря или сама структура словаря нарушена?

^^ Все победил, проблема была в структуре конфига словаря =)

все таки до конца не выходит разобраться, может кто подсказать как правильно составить запрос к словарю? в идеале на примере ip_trie

как должен выглядить 3 параметр для dictGetString если я хочу в него передать ip адрес?

select ip, dictGetString('geo_dict', 'geoname_id', ip(или что тут дожно быть чтобы заработало)) from list

clickhouse-server-base : Depends: libc6 (< 2.24) but 2.24-11+deb9u1 is to be installed

Можно скачать вручную deb-пакеты, распаковать их, и отредактировать зависимость (поставить 2.25 например), запаковать назад, и установить

ура, разобрался со словарями до конца =)

Можно скачать вручную deb-пакеты, распаковать их, и отредактировать зависимость (поставить 2.25 например), запаковать назад, и установить

Мне в плейбук... Там так низя.

Добрый день! У меня есть огромная таблица, на 3.5 млрд строк. Но мне нужны данные например только за последний месяц, а там данных на 3-4 месяца. Как мне удалить часть таблицы? Проблема в том что запросы по этой таблице очень медленные и иногда не хватает памяти

а почему бы не ограничивать запрос в where created_at_date >

SELECT ad_tag_publisher_id, ad_tag_id, publisher_id, advertiser_id, toUInt32(count()), toDate('2017-09-02'), toDateTime('2017-09-02 12:59:59'), geo_country, device_type, request_type FROM statistics.daily_statistics WHERE (date_time >= toDateTime('2017-09-02 12:55:00')) AND (date_time <= toDateTime('2017-09-02 12:59:59')) GROUP BY ad_tag_publisher_id, ad_tag_id, publisher_id, advertiser_id, geo_country, device_type, request_type

я делаю вот такой вот запрос

наверное его тормозит group by?

973 rows in set. Elapsed: 438.956 sec. Processed 3.44 billion rows, 222.69 GB (7.83 million rows/s., 507.31 MB/s.)

вот результат

вечность)

hdd?

да

покажи create table

А какой индекс?

CREATE TABLE statistics.daily_statistics ( request_id String, ad_tag_publisher_id String, ad_tag_id UInt32, publisher_id UInt32, advertiser_id UInt32, date Date, date_time DateTime, request_type String, geo_country String, device_type String) ENGINE = Distributed(datalayer, \'statistics\', \'daily_statistics_replicated\', rand())

а, это вьюха

CREATE TABLE statistics.daily_statistics_replicated ( request_id String, ad_tag_publisher_id String, ad_tag_id UInt32, publisher_id UInt32, advertiser_id UInt32, date Date, date_time DateTime, request_type String, geo_country String, device_type String) ENGINE = ReplicatedMergeTree(\'/clickhouse/tables/{shard}/daily_statistics_replicated\', \'{replica}\', date, request_id, (request_id, ad_tag_publisher_id, ad_tag_id, publisher_id, advertiser_id, date, date_time), 8192)

вот таблица сама

А, если выборка по времени, то date_time дожен быть впереди в индексе

я понял в чем дело

если я сделаю WHERE (date_time >= toDateTime('2017-09-02 12:55:00')) AND (date_time <= toDateTime('2017-09-02 12:59:59')) >>>AND date = toDate('2017-09-02')<<<

то выполняется быстро

за 40 секунд

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

спасибо!

да

я поэтому выше написал про created_at_date

это кластеризующий индекс

да, я понял. Спасибо

У нас тоже сейчас 3,5 млрд но стирать не собираемся

И ssd

У нас каждый день сейчас добавляется до 500 млн строк

Но как бы скорость вообще не важна, главное возможность делать запросы

Но как бы скорость вообще не важна, главное возможность делать запросы

А если запрос будет работать две недели? )) Скорость не важна? )

Ну всеравно пока запрос по 500 млн записей работает меньше минуты и это ок

вы неделю работаете что ли? =)

блин, вам конечно SSD нужен, но дорого будет

а есть какое нибудь элегантное решение для bitOr([1,2,3,...]) = 1 | 2 | 3 | ... что нибудь типа мапредюса?

Привет, у меня миллионы чисел с разным кол-вом знаков после запятой от 0 до 8 знаков, как лучше хранить их в clickhouse? UInt64 с умножением на 100000000? или есть какие то специальные типы которые уже умеют делать умножение/деление при вводе/выводе 75652477291.04 11.00046342 1.01

чем Float64 не подойдет?

в документации написано: Не рекомендуется хранить числа с плавающей запятой в таблицах.

если вам нужна арифметика без внезапного округления - то лучше велосипед фиксированной точности в целом типе. если это не принципиально - можно хранить float как есть.

всем привет! подскажите, при создании словаря появляется ошибка: element dictionary.layout should have exactly one child element

я так понимаю он ругается на разедл <key>

но в key у меня всего 1 атрибут

смотри, вот так у меня выглядит словарь, который генерируется внешней системой:

<dictionaries> <dictionary> <name>hostnames</name> <source> <file> <path>/opt/retroview/priv/hostnames.csv</path> <format>CSV</format> </file> </source> <lifetime> <min>300</min> <max>360</max> </lifetime> <layout><complex_key_hashed/></layout> <structure> <key> <attribute> <name>server_id</name> <type>String</type> </attribute> </key> <attribute> <name>hostname</name> <type>String</type> <null_value></null_value> </attribute> </structure> </dictionary> </dictionaries>

это мапит UUID сервера на хостнейм

а у тебя какой словарь?

<dictionaries> <dictionary> <name>geoip</name> <source> <file> <path>/etc/clickhouse-server/GeoIP2-City-Blocks-IPv4.csv</path> <format>CSVWithNames</format> </file> </source> <layout> <ip_trie /> </layout> <structure> <key> <attribute> <name>network</name> <type>String</type> </attribute> </key> <attribute> <name>geoname_id</name> <type>UInt64</type> <null_value></null_value> </attribute> <attribute> <name>registered_country_geoname_id</name> <type>UInt64</type> <null_value></null_value> </attribute> <attribute> <name>represented_country_geoname_id</name> <type>UInt64</type> <null_value></null_value> </attribute> <attribute> <name>is_anonymous_proxy</name> <type>UInt8</type> <null_value></null_value> </attribute> <attribute> <name>is_satellite_provider</name> <type>UInt8</type> <null_value></null_value> </attribute> <attribute> <name>postal_code</name> <type>String</type> <null_value></null_value> </attribute> <attribute> <name>latitude</name> <type>String</type> <null_value></null_value> </attribute> <attribute> <name>longitude</name> <type>String</type> <null_value></null_value> </attribute> <attribute> <name>accuracy_radius</name> <type>UInt8</type> <null_value></null_value> </attribute> </structure> <lifetime> <!— Lifetime of dictionary in memory —> 300 </lifetime> </dictionary> </dictionaries>

у меня закралось подозрение, что возможно в моем билд еще нет layout = ip_trie

Если эта ошибка появилась после апдейта ClickHouse, то это значит, что при апдейте были изменены конфиги пользователей (users.xml) и в них как-то изменились права доступа. Хотя конфиг по-умолчанию из пакета разрешает доступ пользователю default без пароля. Можно посмотреть на конкретном сервере, откуда приходит ошибка, почему он не разрешает пользователю default соединиться. Кстати, для удобства обновлений, можно держать оригинальные конфиги из пакета без изменений, а все изменения прописывать в отдельных файлах в conf.d, users.d директориях. Так ещё и проще следить за множеством изменений.

А в таком случае запрос должен идти от дефолтного юзера или от того, который указан в <remote_servers>?

у меня закралось подозрение, что возможно в моем билд еще нет layout = ip_trie

вполне возможно

вполне возможно

а где можно найти полный changelog не подскажите?)

если кто может, подскажите, в версии 1.1.54140 уже был ip_trie?

Иногда во время вставки 100к строчек в кликхаус происходит таймаут clickhouse error: [999] zkutil::KeeperException: operation timeout, path: /clickhouse/tables/02/daily_statistics_replicated/temp/abandonable_lock- INSERT INTO statistics.daily_statistics (request_id,ad_tag_publisher_id,ad_tag_id,publisher_id,advertiser_id,date,date_time,request_type,geo_country,device_type) VALUES (?,?,?,?,?,?,?,?,?,?), ... У вас бывают такие проблемы? Как вы их решаете?

или просто делать ретрай пока не запишется?

Добрый день. Имею кликхаус с таблицей ReplicatedMergeTree. С некоторого момента кликхаус на запросы в http-интерфейс стал отвечать zkutil::KeeperException: connection loss, path: /clickhouse/tables/sent_notifications/temp/abandonable_lock в логах зукипера куча ошибок NoNode for /clickhouse/tables/check_state/temp/abandonable_lock-0001360070 NoNode for /clickhouse/tables/check_state/block_numbers/201708/block-0001211086 ClickHouse client version 1.1.54226. zookeeper version 3.4.6 Подскажите пожалуйста, куда смотреть и что нажимать, чтобы заработало

если кто может, подскажите, в версии 1.1.54140 уже был ip_trie?

нет, примерно в 1.1.54241 появился

Господа, 9ый дебиан мимо да ?

официальные пакеты собраны для убунты, и ставить их в дебиан - не самая лучшая идея. Лучше собрать руками. Кстати совсем недавно появилась возможность собирать через pbuilder для почти любых дебиантов-убунт. https://github.com/yandex/ClickHouse/blob/master/debian/.pbuilderrc

да, просто для 8-ки таки работает.

собрать руками в плейбук не положишь :(

официальные пакеты собраны для убунты, и ставить их в дебиан - не самая лучшая идея. Лучше собрать руками. Кстати совсем недавно появилась возможность собирать через pbuilder для почти любых дебиантов-убунт. https://github.com/yandex/ClickHouse/blob/master/debian/.pbuilderrc

а зачем там sudo ?:)

потому что pbuilder работает от рута

Продолжаем скрещивать Табло с КХ. C CAST разобрались, теперь возникла проблема с подстановкой параметров-дат. Есть запрос SELECT site, date, toString(date) as date1, uniqExact(uid) as uv, uniq(uid) as uv0, count() as vv from groot3.content_watch where date>= <Parameters.date_from> and date< <Parameters.date_to> group by site, date, toString(date) Табло подставляет вместо <Parameters.date_from> дату в виде {d '2017-07-01'} и скармливает получившийся запрос драйверу. Драйвер это не переваривает и кадает в КХ запрос в неизменном виде: SELECT site, date, toString(date) as date1, uniqExact(uid) as uv, uniq(uid) as uv0, count() as vv from groot3.content_watch where date>= {d '2017-07-01'} and date< {d '2017-07-02'} group by site, date, toString(date) Вот что сами Табло пишут For example, the ODBC specification details that dates should be specified in SQL statements by using the syntax: {d 'yyyy-mm-dd'}. This format is then translated by the driver to the proper date syntax of the actual database.

@alexanderzaitsev можно вас попрсить собирать пакеты и для debian 8/9 в туже репу альтинити ?

Всем привет! Подскажите с баянистым вопросом, про дубли при репликации. Хочу попробовать на тесте завестись с двумя нодами. Но после инсерта одной записи в Distibuted таблицу получаю две при селекте. Конфиг вот такой https://pastebin.com/E1YAypgm При этом на нодах меняется только секция macros, а сама таблица создается так: CREATE TABLE tesd (...) ENGINE ReplicatedMergeTree('/clickhouse/tables/{slicer_shard}/default/tesd', '{replica}', date, (siteId, date, docUuid), 8192);

А в кейсах нельзя агрегировать? т.е если у меня в then есть что-то и это что-то я хочу сделать sum() ?

всем привет! подскажите, при создании словаря появляется ошибка: element dictionary.layout should have exactly one child element

интересно. обычно такая ошибка происходит, если есть несколько тегов <layout> или несколько тегов внутри <layout> ... </layout>. Скопировал конфиг себе, распарсился без ошибок. Возможно, в файле конфигурации есть еще что-то? Не дублируется ли конфигурация для словаря?

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

А в кейсах нельзя агрегировать? т.е если у меня в then есть что-то и это что-то я хочу сделать sum() ?

Можно сделать sumIf вместо case

Либо сделать запрос с кейсом, а поверх него уже сделать запрос на агрегацию нужных данных

Либо сделать запрос с кейсом, а поверх него уже сделать запрос на агрегацию нужных данных

у меня запрос с кейсом делает из узкой таблицы широкую, по сути генерируя столбцы тут по идее sumif не подойдет же?

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

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

если бы не умел ip_trie, была бы ошибка "unknown dictionary layout type"

если бы не умел ip_trie, была бы ошибка "unknown dictionary layout type"

странно, сейчас у меня вообще КХ падает при попытке обработать словарь

А в кейсах нельзя агрегировать? т.е если у меня в then есть что-то и это что-то я хочу сделать sum() ?

можно делать case sum() можно делать sum(case ). главное чтобы на пути из select в листья агрегатные функции были один раз. в первом случае case будет работать меньшее число раз.

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

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

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

Делается типа так select sumIf(...), column from (select с кейсом) group by column

на том же конфиге?