GROUP BY ifNull(x,0)

Спасибо

Еще вроде можно GROUP BY or(0, x) щас нашел

потому что данные в этих таблицах постоянно обновляются

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

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

Не очень понял смысл этого священнодейства) Есть же уже словари нормально работающие.

Ну я так буду решать проблему с массивами. А у вас, я так понял, есть проблема с поисками в словарях?

нет, у нас потенциально есть проблема с размером flat-словаря, есть вероятность, что рано или поздно один из них вырастет до 500к записей

Ну я так буду решать проблему с массивами. А у вас, я так понял, есть проблема с поисками в словарях?

а какая у вас проблема с массивами?

Ставьте лайк :) https://github.com/yandex/ClickHouse/issues/1640

вот

а, понял :)

Ну если речь про поиск внутри массивов - пока предложенный мной вариант нас устраивает

Привет! Сталкивался ли кто или знаете причину такого? На всех машинах кластера схема одинаковая. Делаю запрос SELECT ... FORMAT JSON.Запрос делается в distributed таблицу. В ответе меня интересует поле rows_before_limit_at_least. Странность: Один из серверов отдает 0 в этом поле. Все остальные сервера отдают одинаковое значение не 0. Полезные данные - строки результата - совпадают на всех серверах.

Как оказалось, репликация идёт по отдельному порту 9009. Пробросил его и репликация пошла

угу. И там к тому же протокол HTTP. Т.е. он на этом порту запускает HTTP сервер, а в зукипере публикует "адреса" партиций которые оттуда можно (и нужно) скачать.

привет! мы делаем эксперименты в рамках clickhouse базы и разных BI тулзов. сейчас пытаемся подключить BI tool которые умеет работать с MySQL базок к Clickhouse базе. Поставили ProxySQL, который умеет переписывать синтаксис с MySQL на Clickhouse. Пока что оно заводится, держит connection, и в целом работает. Столкнулись пока что только с одним косяком - запросы типа SELECT col1 FROM table GROUP BY 1 не проходят. Rewrite rules в ProxySQL под такое писать не хотелось бы, потому что жесть. Есть ли в обозримом будущем в Clickhouse базе планы на поддержку GROUP BY 1,2 / ORDER BY 1,2 запросов?

всем привет. Запрос SELECT * FROM track_log t WHERE (track_id=462739066) AND (date='2018-05-20') на 1.1.54236-4.el7 работает мгновенно. Переехали на 1.1.54385-1.el7, там этот запрос 8 секунд работает. Что может быть, что посмотреть? Базу переливали Select ... format native | insert into

киньте структуру старой и новой таблиц

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

а структура разве разная? show create table — этой командой создал на новом сервере CREATE TABLE trk.track_log ( date Date DEFAULT toDate(unix_timestamp), unix_timestamp DateTime, track_id Int64, repeat_track_id Int64, campaign_id Int32, split_from_campaign_id Int32, source_id Int32, offer_id Int32, ip String, params String, status Int32, redirect_url String, price_rub Float32, price Float32, currency_id Int32, user_agent String, url String, fraudscore_status String, referrer String, device_locale String) ENGINE = MergeTree(date, (date, track_id), 8192)

1 rows in set. Elapsed: 7.698 sec. Processed 73.73 thousand rows, 51.42 MB (9.58 thousand rows/s., 6.68 MB/s.) 1 rows in set. Elapsed: 0.016 sec. Processed 8.19 thousand rows, 5.28 MB (498.23 thousand rows/s., 321.26 MB/s.)

какой-то печальный сервер, 6.68 MB/s

таблицы-то точно одинаковые? Processed 73.73 thousand rows и Processed 8.19 thousand rows

в том-то и дело

ну у вас чтение в 15 раз медленее

что сервер совершенно не печальный. 48тредов, SSD

ну что то не так явно с чтением проверьте диск

а почему у вас индекс такой (date, track_id), а не (track_id, date), как в доке советуют

перелейте в (track_id, date), посмотрите, будет ли разница, для интереса

щас диск попробую по hdparmить

[root@gala3 etc]# hdparm -t /dev/nvme0n1 /dev/nvme0n1: Timing buffered disk reads: 4414 MB in 3.00 seconds = 1470.86 MB/sec

буфферед конечно ни о чём. но всё же не 6mb/s

регресс из-за какого-то сильного бага в этой версии исключён?

у многих КХ на продакшене, тут бы ор стоял

ну явно что-то не то с КХ

таблицы-то точно одинаковые? Processed 73.73 thousand rows и Processed 8.19 thousand rows

+1. Явно есть какое-то несоответствие. Сам запрос прям к trk.track_log делается? Случайно не к какой-нибудь Disturbed-таблицы поверх trk.track_log?

да не. всё отлично работало на старом сервере

структуру данных никто не менял

всем привет. Запрос SELECT * FROM track_log t WHERE (track_id=462739066) AND (date='2018-05-20') на 1.1.54236-4.el7 работает мгновенно. Переехали на 1.1.54385-1.el7, там этот запрос 8 секунд работает. Что может быть, что посмотреть? Базу переливали Select ... format native | insert into

Попробуйте перелить через tsv формат, может что-то не так с format native

А лучше просто скопируйте партиции

уже не получится, прод-данные со вчера льются в это новое глючащее место

Так не только кх новый, но и сервер под ним новый?

Странный ssd конечно

да, перееххали на новый сервер, на него же новая версия КХ прилетела

На тысячах строк оно должно работать моментально

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

неа

# hdparm -t /dev/md1 /dev/md1: Timing buffered disk reads: 4314 MB in 3.00 seconds = 1437.32 MB/sec с рэйда тоже нормально

iowait ваще нулевой

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

кстати да

Привет, кто скрещивал КХ с superset, может сталкивались с ошибкой `'str' object has no attribute 'db_type'` когда подключаешь базу. Когда жмешь тест пишет ОК, но потом выкидывает с ошибкой.

докладаю. в новой версии регресса нет. на новом сервере КХ отожрал слишком много памяти, 122G virt, 75G RES. после мучительного рестарта работает быстро

Привет, кто скрещивал КХ с superset, может сталкивались с ошибкой `'str' object has no attribute 'db_type'` когда подключаешь базу. Когда жмешь тест пишет ОК, но потом выкидывает с ошибкой.

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

что за утечка — непонятно

подскажите как мониторить статус репликации кликхауса?

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

все по умолчанию, там нужно что то еще прописывать кроме clickhouse://localhost:8123/ ?

подскажите как мониторить статус репликации кликхауса?

По таблице system.replicas можно например

вот тоже смотрю. в документации хороший запрос приведен

https://clickhouse.yandex/docs/ru/system_tables/system.replicas/

вот тоже смотрю. в документации хороший запрос приведен

Я примерно как-то так и реализововал

все по умолчанию, там нужно что то еще прописывать кроме clickhouse://localhost:8123/ ?

Только что попробовал создать коннект - такая же ошибка

Просто много людей писало что у них все работает, а тут бац, и чет не гуглится. Явно что то делаю не так.

ставил на ubunte 18.04 может там что наломали

Просто много людей писало что у них все работает, а тут бац, и чет не гуглится. Явно что то делаю не так.

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

Скажите, а кто-нибудь натравливал на clickhouse-server.log обычный системный logrotate? Хочется логи по сутками все-таки разбивать.

А в чем проблема?

По дефолту в убунту вроде логротейтятся

По дефолту он сам за ротейт отвечает. По размеру.

а ну может быть

граждане, особенно разработчики.. нет ли в 1.1.54385-1.el7 проблемы с жором памяти?

час поработал после рестарта, опять память выжрал и тормозит

граждане, особенно разработчики.. нет ли в 1.1.54385-1.el7 проблемы с жором памяти?

пока не было замечено. память может тратиться по многим причинам: кеши, словари, мержи. может просто удерживаться аллокатором про запас.

пока не было замечено. память может тратиться по многим причинам: кеши, словари, мержи. может просто удерживаться аллокатором про запас.

вот он после рестарта первое время работал очень быстро, пока памяти много не сожрал. потом сожрал 70гиг и начал тормозить на селектах

можно ли откатить версию на 1.1.54236-4.el7 обратно, или хранилище обратно не совместимо?

можно

а есть где-нибудь самый свежак в RPM-пакетах?

щас это: https://packagecloud.io/altinity/clickhouse/el/7/$basearch не самый свежак

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

нет, вопрос не снят. пытаюсь поставить из Яндекс-репы yum'ом: Transaction check error: файл / из устанавливаемого пакета clickhouse-server-1.1.54388-2.noarch конфликтует с файлом из пакета filesystem-3.2-21.el7.x86_64 файл /lib из устанавливаемого пакета clickhouse-server-1.1.54388-2.noarch конфликтует с файлом из пакета filesystem-3.2-21.el7.x86_64 файл /usr/bin из устанавливаемого пакета clickhouse-server-1.1.54388-2.noarch конфликтует с файлом из пакета filesystem-3.2-21.el7.x86_64 файл /etc/init.d из устанавливаемого пакета clickhouse-server-1.1.54388-2.noarch конфликтует с файлом из пакета chkconfig-1.7.4-1.el7.x86_64

это я что-то не так делаю?

а при удалении он тебе / удалит, интересно?)

Создал реплицируемую таблицу, залил данные через INSERT INTO .. SELECT Вроде всё нормально, но в логе постоянно пишется такое 2018.07.04 12:19:31.594641 [ 2 ] <Debug> load_stat (ReplicatedMergeTreeQueue): Not executing log entry for part 20180317_20180319_285_290_1 because source parts size (30.02 MiB) is greater than the current maximum (4.45 MiB). На что это влияет и что можно подкрутить в настройках чтобы такого не писало?

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

т.е. в сессии перед insert select нужо set max_block_size = 8192

всем привет. Запрос SELECT * FROM track_log t WHERE (track_id=462739066) AND (date='2018-05-20') на 1.1.54236-4.el7 работает мгновенно. Переехали на 1.1.54385-1.el7, там этот запрос 8 секунд работает. Что может быть, что посмотреть? Базу переливали Select ... format native | insert into

Там размер максимального куска увеличили с 100 до 150 gb, возможно он у вас мержами был занят и сильно на диск давил

можно ли откатить версию на 1.1.54236-4.el7 обратно, или хранилище обратно не совместимо?

вы количество одновременных мержей временно уменьшите, он данные помержит спокойно и все будет ОК

вы количество одновременных мержей временно уменьшите, он данные помержит спокойно и все будет ОК

А это что такое? Как меняется?

Для реплицируемых таблиц max_replicated_merges_in_queue в конфиге для merge_tree секции и background_pool_size там по дефолту по 16

https://github.com/yandex/ClickHouse/blob/4535f96148da1fe6da9c9c7061efe1ab61c11de4/dbms/src/Interpreters/Settings.h#L58

Для применения этих настроек нужен рестарт сервера КХ

Спасибо, завтра попробую

Tima указание max_block_size/max_insert_block_size перед insert into select лучше взять за привычку, в зависимости от того как вы храните данные и какие они можно сильно уйти по памяти, возможно это нужно сделать в самом КХ или как-то адаптивно просчитывать его и размер мержей при этом @milovidov_an ?

ну и max_threads тоже в 1

Tima указание max_block_size/max_insert_block_size перед insert into select лучше взять за привычку, в зависимости от того как вы храните данные и какие они можно сильно уйти по памяти, возможно это нужно сделать в самом КХ или как-то адаптивно просчитывать его и размер мержей при этом @milovidov_an ?

Спасибо, буду пробовать