SQLAlchemy - Хиты базы данных при каждом запросе?

Question

В настоящее время я работаю с веб-приложением, написанным на Python (и использующим SQLAlchemy). Чтобы обработать аутентификацию, приложение сначала проверяет идентификатор пользователя в сеансе и, если он существует, извлекает всю эту запись пользователя из базы данных и сохраняет ее для остальной части этого запроса. Другой запрос также запускается для проверки прав пользователя, которого он сохранил.

Я довольно новичок в мире разработки веб-приложений, но, насколько я понимаю, попадание в базу данных для чего-то подобного на каждый запрос неэффективно. Или это считается нормальным делом?

Единственное, о чем я до сих пор думал, это один раз собрать эти данные и сохранить то, что имеет отношение (большинство данных даже не требуется при каждом запросе). Однако это поднимает проблему того, что должно произойти, если эта пользовательская запись будет удалена в промежуточный период. Есть идеи, как лучше всего с этим справиться?

Answer 1

Для входа пользователя и основных токенов разрешений в простом веб-приложении я обязательно сохраню это в сеансе на основе файлов cookie. Это правда, что несколько SELECT для каждого запроса не имеют большого значения, но, опять же, если вы можете заставить некоторые / все ваши веб-запросы выполняться из кэшированных данных без обращений к БД вообще, это просто добавляет гораздо большую масштабируемость приложение, которое планирует получать большую нагрузку.

Проблема изменения токена пользователя в базе данных решается двумя способами. Во-первых, не обращайте на это внимания - для многих случаев использования не так уж сложно для пользователя выйти из системы и снова войти в нее, чтобы получить новые разрешения, которые были предоставлены в другом месте (например, в качестве примера unix). Другое состоит в том, что все мутации строки пользователя фильтруются с помощью метода, который также сбрасывает состояние в рамках сеанса на основе файлов cookie, но это эффективно только в том случае, если пользователь сам инициирует изменения через интерфейс браузера.

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

Answer 2

"попадание в базу данных для чего-то подобного в каждом запросе неэффективно."

Ложь. И вы предположили, что нет кэширования, что также неверно.

Большинство слоев ORM прекрасно кэшируют строки, сохраняя некоторые запросы к БД.

Большинство РСУБД имеют обширное кэширование, что приводит к удивительно быстрым ответам на распространенные запросы.

Все слои ORM будут использовать согласованный SQL, что поможет базе данных оптимизировать повторяющиеся операции. (В частности, оператор SQL кэшируется, экономя время анализа и планирования.)

«Или это считается нормальным делом?»

Правда.

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

Answer 3

Вы в основном говорите о кэшировании данных как об оптимизации производительности. Как всегда, преждевременная оптимизация - плохая идея. Трудно заранее определить, где находятся узкие места, тем более, если домен приложения для вас новый. Оптимизация добавляет сложности, и если вы оптимизируете не те вещи, вы не только напрасно потратили усилия, но и усложнили необходимую оптимизацию.

Запрос пользовательских данных обычно является довольно тривиальным запросом. Вы можете создать себе простой тест, чтобы увидеть, какие накладные расходы это принесет. Если это не значительный процент вашего бюджета времени, просто оставьте его.

Если вы все еще хотите кэшировать данные на сервере приложений, вам нужно придумать схему аннулирования кэша.

Возможные схемы - проверка изменений в базе данных. Если у вас недостаточно данных для кеширования, это на самом деле не намного эффективнее, чем просто перезагрузить его.

Другим вариантом является просто тайм-аут данных. Это хороший вариант, если не важна мгновенная видимость изменений.

Другим вариантом является активная аннулирование кэшей при внесении изменений. Это зависит от того, изменяете ли вы базу данных только через ваше приложение, и если у вас есть один сервер приложений или кластерное решение.

Answer 4

Это база данных, поэтому довольно часто «бьют» по базе данных, чтобы получить необходимые данные. Вы можете уменьшить количество отдельных запросов, если создаете соединения или хранимые процедуры.