Какая СУБД обеспечит минимальное время доступа к непрогретым данным?

Добрый день!

Хочу спросить совета по такой ситуации. Имеются данные в количестве примерно 40-50 млн. строк (размер на диске с индексами - около 170 Гбайт). Данные довольно статичны (рост - 1-10 тыс. новых записей в неделю). Изначально я грузил эти данные в PostgreSQL, но здесь есть проблема с прогревом. Первый запрос выполняется до 30-40 секунд, второй около 5 секунд, и далее уже 150-300 мс.

Прогревать кеш перед работой нереально. Периодически приходят новые клиенты, которые запускают различные онлайн-демо с сайта. И здесь важно произвести первое впечатление - уже первый запрос уже должен быть обработан быстро, ну или хотя бы в 1-2 секунды.

Партицирование пробовал - принципиально ситуацию не меняет. Shared Buffers ставил в 6 Гбайт - тоже не помогло. Вопрос, что делать дальше? У меня в голове такие варианты:
1. Создавать копию данных на диске, структурировать ее по папкам и просто читать записанные "выборки" с диска. Я в принципе, так делал, и в определенных случаях - это самое классное и быстрое решение. Но оно не позволяет делать выборки по условиям.
2. Использовать что-то вроде Elsaticsearch. Пока все, что я про нее прочитал - устраивает. Даже приятно, что есть поиск по геоданным (найти объекты не далее 25 км от такой-то точки). Но я слышал, что у нее тоже есть прогрев, но я не нашел, насколько он быстр.
3. Применить in-memory базы, например Redis. Но это удорожает решение, поскольку придется покупать второй сервер. А проблема в том, что у меня не проблема роста сервиса, а проблема малого количества пользователей на огромный массив данных.
4. Применить Sphinx. Там я ни разу не читал про проблему прогрева, но может быть - не нашел просто.

Какие есть в такой ситуации типовые решения?
  • Вопрос задан
  • 2850 просмотров
Пригласить эксперта
Ответы на вопрос 3
opium
@opium
Просто люблю качественно работать
если выборка простая и по индексу это скорее проблема доступа к диску, поставьте базу на ссд
Ответ написан
@Timosha
заведите для новых клиентов базу поменьше, делайте так чтобы выборки поднимали как можно меньше данных и не использовали рандомное чтение с диска. руками поднимайте необходимые данные в дисковый кэш и shared buffers. вариантов борьбы много, на всех не in-memory базах скорость будет упираться в скорость случайного чтения с винчестеров в случае запроса не поднятых в память данных. ну и, как уже посоветовали, SSD :)
Ответ написан
Комментировать
@avtomon
Full-stack разработчик
Создайте дополнительный раздел с tmpfs и при каждом запуске сервера делайте синхронизацию базы на этот раздел. Но вся база у вас не влезет, поэтому выделяйте партицию, которая влезет в раздел. И читайте с этого раздела. Конечно, это тоже прогрев, но он происходит только при перезапуске сервера.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы