SQLAlchemy - База данных попадает по каждому запросу?

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

Большинство RDBMS имеют обширное кэширование, что приводит к чрезвычайно быстрой реакции на общие запросы.

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

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

Правда.

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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