Сессии Django

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

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

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

Я не эксперт по Django, поэтому этот ответ касается хранилищ сеансов в целом. Голосуйте против, если я ошибаюсь.

Производительность и масштабируемость

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

Хранилища сеансов базы данных и файловой системы (обычно) поддерживаются дисками, поэтому вы можете дешево проводить много сеансов (потому что диски дешевы), но запросы часто должны ждать, пока данные будут прочитаны (потому что диски медленные). Сеансы Memcached используют ОЗУ, поэтому поддержка того же количества одновременных сеансов будет стоить дороже (потому что ОЗУ дорого), но может быть быстрее (потому что ОЗУ быстро).

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

Простота

Выбор хранилища сеансов также повлияет на то, насколько легко будет развернуть ваш сайт. Отказ от значения по умолчанию будет стоить некоторых сложностей. И у Memcached, и у СУБД есть свои сложности, но ваше приложение, вероятно, в любом случае будет использовать СУБД.

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

Бонус

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

При выборе серверной части сеанса следует учитывать одну вещь: «как часто изменяются данные сеанса»? Даже сайты с умеренным трафиком пострадают, если данные сеанса будут изменяться при каждом запросе, совершая множество обращений к базе данных для хранения и извлечения данных.

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

Если в базе данных есть администратор базы данных, который не является вами, вам может быть запрещено использовать сеанс с поддержкой базы данных (это только интерфейс пользователя). Пока django не поддерживает простое слияние данных из нескольких баз данных, чтобы вы могли иметь специфичные для внешнего интерфейса вещи, такие как сеансы и сообщения пользователей (сообщения в django.contrib.auth также хранятся в базе данных) в отдельной базе данных, вам необходимо сохранить это в виду.

Начиная с Django 1.1, вы можете использовать серверную часть сеанса cached_db.

Это сохраняет сеанс в кеше (используется только с memcached) и записывает его обратно в БД. Если он выпал из кеша, он будет прочитан из БД.

Хотя это медленнее, чем просто использование memcached для хранения сеанса, оно добавляет сеансу постоянство.

Для получения дополнительной информации см .: Django Docs: использование кешированных сессий