Необходим опыт работы с базой данных Heroku?

Question

Мы столкнулись с серьезными проблемами масштабирования для нашей интеллектуальной поисковой системы / агрегатора . Наша база данных содержит около 200 тысяч объектов. Судя по профилированию и новым реликвиям, большинство наших проблем может исходить из базы данных. Мы используем самую маленькую специализированную базу данных Heroku (Ronin).

Мы занимаемся индексированием и кэшированием . До сих пор нам удавалось решить наши проблемы путем интеллектуального сокращения вызовов базы данных и кэширования контента, но теперь даже это, кажется, подходит к концу. Мы постоянно спрашиваем себя, достаточно ли хорош наш код / ​​конфигурация или мы просто не используем достаточно «аппаратного обеспечения».

Мы подозреваем, что решение для базы данных, которое мы покупаем у Heroku, может работать недостаточно. Например, простое подсчет (без объединений, без ничего) для 200 тыс. Элементов занимает около 250 мс. Это похоже на long время, хотя postgres известен своей плохой производительностью по счетам?

Мы также начали использовать поиск геолокации на основе широты / долготы. Оба столбца являются индексированными числами с плавающей точкой. Расчет расстояния требует довольно сложной математики, но мы используем очень хорошо рекомендованный гем geocoder, который, как предполагается, может выполнять очень оптимизированных запросов. Даже геокодеру по-прежнему требуется 4-10 секунд для поиска, скажем, 40 000 объектов, возвращая только предел первых ближайших 10. Это снова звучит как долгое время , и все опытные люди, с которыми мы консультируемся говорит, что это звучит очень странно, снова намекая на производительность базы данных.

Так что в основном мы задаемся вопросом: что мы можем ожидать от базы данных? Может ли быть проблема? И что мы можем ожидать, если мы решим обновить?

У меня есть еще один вопрос: я прочитал здесь , что мы можем улучшить производительность, загрузив всю базу данных в память. Мы должны сами это настроить и если да, то как?

ОБНОВЛЕНИЕ ПОСЛЕДНЕГО ВОПРОСА: Я получил это от людей из службы поддержки Heroku:

"Что это значит - иметь достаточно памяти (достаточно большой выделенный база данных), чтобы сохранить ваш горячий набор данных в памяти. Это не то вы должны сделать вручную, Postgres настроен автоматически использовать все доступной памяти в наших специализированных базах данных.

Я посмотрел на вашу базу данных и похоже, что вы сейчас использование около 1,25 ГБ ОЗУ, поэтому вы не увеличили использование памяти еще. "

ОБНОВЛЕНИЕ НА ЧИСЛАХ И ЦИФРАХ

Хорошо, теперь у меня было время взглянуть на цифры и цифры, и я постараюсь ответить на следующие вопросы:

• Прежде всего, БД состоит из около 29 таблиц с множеством связей. Но в действительности большинство запросов выполняются в одной таблице (некоторые дополнительные ресурсы объединены, чтобы предоставить всю необходимую информацию для представлений).
• В таблице 130 столбцов.
• В настоящее время он содержит около 200 тыс. Записей, но активны только 70 тыс., Следовательно, все индексы создаются как частичные индексы в этом «состоянии».
• Все столбцы, которые мы ищем, проиндексированы правильно, и ни один из них не имеет текстового типа, и многие из них являются просто логическими значениями.

Ответы на вопросы:

1. Хм, базовая производительность сложно сказать, у нас так много разных вариантов. Время, которое требуется, обычно варьируется от 90 мс до 250 мс, при выборе ограничения в 20 строк. У нас есть много подсчетов на одном столе от 250 до 800 мс.
2. Хмм, ну, это трудно сказать, потому что они не сделают это.
3. У нас около 8-10 пользователей / клиентов, одновременно выполняющих запросы.
4. Загрузка нашего запроса: в отчетах базы данных новой реликвии говорится об этом за последние 24 часа: throughput: 9.0 cpm, total time: 0.234 s, avg time: 25.9 ms
5. Да, мы изучили планы запросов наших длительных запросов. Запросы подсчета являются особенно медленными, часто более 500 мс для довольно простого подсчета записей 70 КБ, выполненных в индексированных столбцах, с результатом около 300

Answer 1

Я настроил несколько приложений Rails, размещенных на Heroku, а также на других платформах, и обычно проблемы делятся на несколько основных категорий:

1. Слишком много в ruby, что можно сделать на уровне БД (сортировка, фильтрация, объединение данных и т. Д.)
2. Медленные запросы
3. Неэффективное использование индексов (недостаточно или слишком много)
4. Слишком старается сделать все это в БД (это не так часто встречается в рельсах, но бывает)
5. Не оптимизировать кэшируемые данные
6. Не эффективно использовать фоновую обработку

Сейчас вам трудно помочь, потому что ваш вопрос не содержит каких-либо подробностей. Я думаю, вы получите лучший ответ, если определите самую большую проблему, с которой вам нужна помощь, а затем спросите.

Некоторая информация, которая поможет нам помочь вам:

1. Каково среднее время ответа ваших действий? (из новой реликвии, запрос-лог-анализатор, логи)
2. Какой самый медленный запрос, с которым вам нужна помощь?
3. Каковы запросы и код в этом запросе?
4. Отличается ли производительность сайта, когда вы запускаете его локально, по сравнению с heroku?

В конце концов, я думаю, вы обнаружите, что это не проблема, специфичная для Heroku, и если бы ваше приложение было развернуто на Amazon, Engineyard и т. Д., Вы бы имели такую ​​же производительность. Хорошей новостью является то, что я думаю, что ваши проблемы являются общими, и их не должно быть слишком сложно исправить после того, как вы выполните некоторые тесты и профилирование.

-Джон МакКаффри

Answer 2

Мы постоянно спрашиваем ...

... это кажется много ...

... это подозревается ...

... Чего нам ожидать ...

Хорошие новости! Вы можете положить конец тому, чтобы казаться, подозревать удивление и ожидать через магию измерения !!!

Если серьезно, вы не упомянули ни одного из основных пунктов, которые вам понадобятся, чтобы получить полезный ответ:

1. Какова базовая производительность БД, выполняющей последовательное сканирование и выборки индекса из одной строки? Вы говорите, что Heroku говорит, что ваша БД помещается в ОЗУ, поэтому при измерении не должно возникать проблем с дисковым вводом / выводом.
2. Соответствует ли это представление тому, что, по словам Героку, должно быть?
3. Сколько одновременных клиентов?
4. Какова нагрузка вашего запроса - какие запросы и как часто?
5. Проверяли ли вы планы запросов на наличие каких-либо подозрительно длительных запросов?

Как только вы получите такую ​​информацию, возможно, кто-то скажет что-нибудь полезное. То, что вы читаете здесь, означает только догадки.

Answer 3

Во-первых: вы должны проверить свою конфигурацию postgres.(показать все из psql или другого клиента, или просто посмотреть на postgres.conf в каталоге данных). Параметр, который оказывает наибольшее влияние на производительность, равен effective_cache_size, который должен быть равен примерно (total_physical_ram - memory_in_use_by_kernel_and_all_processes)Для машины 4 ГБ это часто составляет около 3 ГБ (4-1).(это очень точная настройка курса, но она даст наилучшие результаты для первого шага)

Второй: Почему Вы хотите все подсчеты?Лучше использовать типичный запрос: просто спросите, что нужно, а не то, что доступно.(причина: невозможна оптимизация для COUNT (*): либо всю таблицу, либо нужно сканировать весь индекс)

Третье: начать сбор и анализ некоторых планов запросов (для типичных запросов, которые плохо работают).Вы можете получить план запроса, поставив EXPLAIN ANALYZE перед фактическим запросом.(другой способ - повысить уровень ведения журнала и получить их из файла журнала). Плохой план запросов может указывать на отсутствующую статистику или индексы или даже на плохое моделирование данных.

Answer 4

Newrelic мониторинг может быть включен в качестве дополнения для heroku (http://devcenter.heroku.com/articles/newrelic).). По крайней мере, это должно дать вам глубокое понимание того, что происходит за кулисами, и может помочь вам определить некоторые проблемы.