CH. Сам запрос, с котором он идет, всегда select 1. Упираюсь в 10к qps и никак не могу разогнать выше, при этом сами запросы исполняются < 1-2мс. Кто-нибудь сталкивался с подобными случаями и если да, то как разгоняли qps? Может, есть какие-то магические настройки в самой бд. или что-то подобное?
У кликхауса большой оверхед на запросы, он разрабатывался под сотни рпс тяжёлых запросов
то есть использовать его как бд, в которую и пишут много много всего и выбирают много много всего, не лучшая идея?
А вы опишите для начала что выбирают и как пишут
если вам надо 1000 запросов в секунду на чтение которые каждый должен по миллиарду строк фильтровать, это не лучший кейс =) и все это на одной машине то машина должна быть очень жирная (много RAM - 256\512 и много CPU 32\64)
писать надо большими батчами по 10-100 тыс, а лучше миллион записей в чанке, меньше плохая идея =) узнаете про Buffer \ clickhouse-bulk \ chproxy и т.п. костыли искать "одну запись" и юзать JOIN с множественными таблицами которые по миллиону записей и не пролазят в память, тоже на CPU и память попадете
это шутка? 10krps на OLAP базе? КХ никто не точил на это. Изначально guid для каждого запроса генерился настолько долго что 100rps не было. На сайте альтинити есть тесты CH under storm. Ну и возможно вы упираетесь в клиента.
Вроде как фишка столбцовых СУБД и состоит в быстрой обработке аналитических запросов, нет?
в быстрой это меньше чем за 10минут на запрос
10K это очень много . если это в один поток, то это порядка 6мс на запрос. 6мс - это одно чтение для жесткого диска. для ssd не знаю цифр, но если что-то не в памяти, то это прям край . наврятли такое стаблино будет работать. чуть стали читать дольше и все
Обсуждают сегодня