Мы сталкиваемся с серьезными проблемами масштабирования для нашей интеллектуальной поисковой системы/агрегатора. Наша база данных насчитывает около 200 тыс. Объектов. Из профилирования и newrelic кажется, что большинство наших проблем может исходить из базы данных. Мы используем самую маленькую выделенную базу данных Heroku (Ronin).
Мы изучали индексирование и кеширование. До сих пор нам удалось решить наши проблемы за счет сокращения запросов к базе данных и кэширования контента разумно, но теперь даже это, похоже, подходит к концу. Мы постоянно спрашиваем себя, действительно ли наш код/конфигурация достаточно хорош или если мы просто не используем достаточно "аппаратного обеспечения".
Мы подозреваем, что решение для базы данных, которое мы покупаем у Heroku, может выполняться недостаточно. Например, просто делать простой счет (без соединений, ничего нечего) на 200 тыс. Элементов занимает около 250 мс. Это похоже на долгое время, хотя postgres известен своей плохой производительностью по счетам?
Мы также начали использовать геолокационные поиски на основе широты/долготы. Оба столбца представляют собой индексированные поплавки. Выполнение расчета расстояния включает довольно сложную математику, но мы используем очень хорошо рекомендованный драгоценный камень geocoder, который, как предполагается, запускает очень оптимизированные запросы. Даже геокодер все еще занимает 4-10 секунд, чтобы выполнить поиск, скажем, 40 000 объектов, возвращая только предел первого ближайшего 10. Это снова звучит долгое время, и все опытные люди, с которыми мы консультируемся, говорят, что это звучит очень странно, снова намекая на производительность базы данных.
Итак, в основном мы задаемся вопросом: чего можно ожидать от базы данных? Может возникнуть проблема? И что мы можем ожидать, если решим обновить?
Дополнительный вопрос: я читаю здесь, что мы можем улучшить производительность, загрузив всю базу данных в память. Должны ли мы настраивать это сами, и если да, то как?
ОБНОВЛЕНИЕ НА ПОСЛЕДНИЙ ВОПРОС: Я получил это от полезных людей в поддержке Heroku:
"Это означает, что у вас достаточно памяти (достаточно большой базы данных) для хранения вашего горячего набора данных в памяти. Это не что-то вам нужно сделать вручную, Postgres настроен автоматически, используя все доступной памяти в наших выделенных базах данных.
Я взглянул на вашу базу данных, и похоже, что вы сейчас используя около 1,25 ГБ оперативной памяти, поэтому вы не увеличили использование памяти еще".
ОБНОВЛЕНИЕ НА НОМЕРА И ЦИФРЫ
Итак, теперь у меня было время посмотреть цифры и цифры, и я постараюсь ответить на следующие вопросы:
- Прежде всего, db состоит из около 29 таблиц с большим количеством отношений. Но на самом деле большинство запросов выполняются на одной таблице (к ним присоединяются некоторые дополнительные ресурсы, чтобы предоставить всю необходимую информацию для представлений).
- В таблице содержится 130 столбцов.
- В настоящее время он содержит около 200 тыс. записей, но активен только 70 тыс., поэтому все индексы производятся как частичные индексы в этом "состоянии".
- Все столбцы, которые мы ищем, индексируются правильно, и ни один из них не имеет текстового типа, а многие из них просто логические.
Ответы на вопросы:
- Хм, базовая производительность, которую трудно сказать, у нас есть много разных вариантов. Время, которое требуется, варьируется обычно от 90 мс до 250 мс, выбирая ограничение в 20 строк. У нас есть много счетов в одной таблице, каждая из которых варьируется от 250 мс до 800 мс.
- Хм, хорошо, что трудно сказать, потому что они не сделают это выстрелом.
- У нас около 8-10 пользователей/клиентов, выполняющих запросы одновременно.
- Загрузка нашего запроса: в новых отчетах о реликвиях он говорит об этом за последние 24 часа:
throughput: 9.0 cpm, total time: 0.234 s, avg time: 25.9 ms - Да, мы рассмотрели планы запросов наших долговременных запросов. Запросы счетчика особенно медленны, часто более 500 мс для довольно простого подсчета на 70 тыс. Записей, сделанных на индексированных столбцах с результатом около 300
