записей + 42 колонок.
Мы фильтруем данные по одной или несколько колонок и получаем 6 000 000 страниц по 100 строк (пагинация по данным).
При перехода по страницам первые несколько страниц работают нормально, если выбрать последнюю то выдает ощибку и за ограничении памать в 20Гб (используется OFFSET и LIMIT)
Вопрос: при фильтрации и пагинации Clickhouse загружает эти данные в памяти? К примеру все 6 милионов строк?
в КХ нет понятия страниц, каждая страница идет отдельными запросами. Вполне естесственно что первые страницы возвращаются раньше последних. Если нужно равномерно распределенное время запроса страниц, лучше вставлять в ЛОГ таблицу, и читать оттуда.
ОК, но если мы хотим фильтровать данные а потом по результату с OFFSET взять посление 100, то в этом случае все отфильтрованные данные будут висеть в памяти пока не найдет в этом массиве OFFSET?
не будет ничего висеть в памяти ни в каком случае. вообще в вашем случае имеет смысл попробовать засунуть фильтры в PREWHERE если таблица широкая
Спасибо большое за ответ, пойду изучу 👍
а что вы в UI делаете с этой пагинацией? Рисуете чиселки со ссылками [1], [2], ....[6000000] в стиле форумов 2000-х ? Если так, то все плохо - для построения каждой отдельной страницы вам придется считать с диска не 100 строк, а всё - от начала и до куда пользователь доползет. Правильнее всего тут изменить UI/UX, и уйти от точных позиций (5123-я страница дает строки точно с 512300 до 512400) в сторону свободной промотки (нам бы 100 строк примерно из середины). Тогда можно сделать фильтрацию по какому-нибудь натуральному ключу, например времени. Тогда фильтрацию можно будет сделать на самом нижнем уровне запроса, получая ответ за десятки миллисекунд (простой кейс без аггрегаций).
Обсуждают сегодня