Джанго Сессии

Question

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

Answer 1

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

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

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

Answer 2

Я не эксперт по Django, поэтому этот ответ, как правило, касается магазинов сессий. Даунвот, если я не прав.

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

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

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

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

Простота

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

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

Бонус

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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