Всем привет, подскажите как работает внешний справочник? Например я подключил справочник из постгри, там табличка из 1-3кк записей. КХ поидее раз в какое-то время обновляет этот справочник. Получается он каждый раз гоняет вообще все данные из таблицы, вытаскивает и все перезаписывает или как-то работает только с новыми данными и частично удаляет?

Там обновляется полностью, но только если invalidate query другой ответ вернул. Где-то пролетало, что какой-то движок (конкретная СУБД) может только изменения присылать, но где это видел-слышал - не помню. А может это вообще звон из другой деревни.

Я заметил, что когда делаются запросы с пагинацией, то те, у которых OFFSET достаточно большой, что в ответе не будет ни одной строки, выполняются фактически мгновенно (в  system.query_log стоят нули и по времени, и по памяти). Но эти запросы подавались параллельно из нескольких потоков! (правда потоки создавались в порядке пагинации). Получается, что у Clickhouse есть какие-то хитрые оптимизации, которые дают такой эффект?

Всем привет, написал тестовый сервис, который через jdbc ходит в CH. Сам запрос, с котором он идет, всегда select 1. Упираюсь в 10к qps и никак не могу разогнать выше, при этом сами запросы исполняются < 1-2мс. Кто-нибудь сталкивался с подобными случаями и если да, то как разгоняли qps? Может, есть какие-то магические настройки в самой бд. или что-то подобное?

Коллеги, есть варианты оптимизировать запрос:
SELECT user, countDistinct(article) as count from (SELECT article, arrayJoin(arraySlice(arraySort((x,y)->y, groupArray(user),groupArray(toUnixTimestamp(time))),1,10)) as user from db WHERE status='read' group by article) group by user order by count desc limit 25
То есть, найти юзеров которые прочитали больше всего статей при условии что они были среди последних 10 юзеров прочитавших статью...

Вариант выше кажется неоптимальным, и при некоторых условиях упирается в память

Здравствуйте, коллеги.
КХ не использует вторичные индексы. Каждый раз идёт фуллскан базы

а, я читал как раз недавно эту статью. Автор в ней пишет, что при select 1 запросе 13к достикает qps. Интересно, а это пик нагрузки? Если я, например, хочу получить хотя бы 30к qps, а лучше и все 50к, то это технически не возможно сделать?

это шутка? 10krps на OLAP базе? КХ никто не точил на это. Изначально guid для каждого запроса генерился настолько долго что 100rps не было. На сайте альтинити есть тесты CH under storm.
Ну и возможно вы упираетесь в клиента.

Вроде как фишка столбцовых СУБД и состоит в быстрой обработке аналитических запросов, нет?

Постгрес и тот быстрее запросы обрабатывает, хотя тоже хранит данные на диске

Вроде как фишка столбцовых СУБД и состоит в быстрой обработке аналитических запросов, нет?

Постгрес на SSD несколько тысяч запросов в секунду спокойно держит