Я заметил, что когда делаются запросы с пагинацией, то те, у которых 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 юзеров прочитавших статью...

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

если вам надо 1000 запросов в секунду на чтение которые каждый должен по миллиарду строк фильтровать, это не лучший кейс =) и все это на одной машине

то машина должна быть очень жирная (много RAM - 256\512 и много CPU 32\64)

писать надо большими батчами по 10-100 тыс, а лучше миллион записей в чанке, меньше плохая идея =)
узнаете про Buffer \ clickhouse-bulk \ chproxy и т.п. костыли

искать "одну запись" и юзать JOIN с множественными таблицами которые по миллиону записей и не пролазят в память, тоже на CPU и память попадете

Пишется большими батчами с некоторыми интервалами, с этим проблем нет. А чтение - запросы сами простые, из разряда select count from where или select что-то from where. Все из одной таблицы выбирается. Сейчас тестирую на пустой бд, но планируется, что в ней будет на вскиду, пока что, до 100 миллионов записей.

сервер, на которой бд, 24 ядра и много (не знаю сколько точно) памяти, с этим проблем нет, своими тестами максимум 8 ядер смог загрузить

50 миллионов записей это маленький объем для clickhouse

=) одной машины хватит...

У нас похожий кейс.
Используем кластер СН (2 шарда по 2 реплики), читаем около 1к рпс на бекенды (на СН около 3к рпс).
Сервера жирные (48 ядер, 200+Гб оперативки, диски ссд по 1Тб), максимально нагружали сервера на 25% загрузки ЦПУ, дальше бекенды просто не выдерживали.
Таблицы по 500+ млн

а вы как-то подкручивали сам кх? И чем ходите из бекенда в кх?

Пытаюсь найти статью ребят из Altinity team, где они проводили тесты на нагрузку, там давали и настройки некоторые.
Под "чем ходите" Вы подразумеваете язык программирования? 🙂

ну, не прям язык, а способ. У меня это через jdbc, он может быть сыроватым еще и, например, на своей стороне не давать разогнать нагрузку

По нативному TCP протоколу

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