Comments 29
Простите, но прочитав код и описание, не нашел ничего «действительно умного». Просто реализация сессий под свои конкретные нужды (т.е. временное кеширование сессионной инофрмации в memcache).
Не только, еще и авторизации. Я рад что не нашли, однако многие люди до этого еще не дошли, и используют обычный session_start() с хранением memcached. Это совсем другое.
Тут проявляется одно из преимуществ использования фреймворков.
Берем для примера джангу.
Там есть «django.contrib.sessions.backends.cached_db»:
This uses a write-through cache – every write to the cache will also be written to the database. Session reads only use the database if the data is not already in the cache.
По сути, то же самое, что и описано.
Но иногда такой вариант не подходит, т.к. может не хватать скорости (кроме memcached работает еще и БД). Тогда идем в настройки и меняем SESSION_ENGINE, например, на 'django.contrib.sessions.backends.cache'. Данные сессий теперь хранятся только в кеше.
Причем кеш ведь тоже может быть разный — локальная память процесса, файлы, БД, memcached, можно и свое что-нибудь написать.
В итоге в большинстве случаев не тратится время на изобретение, обкатку и ремонт велосипедов.
Ничего не имею против варианта организации сессий, который тут описан, просто рассуждения.
Берем для примера джангу.
Там есть «django.contrib.sessions.backends.cached_db»:
This uses a write-through cache – every write to the cache will also be written to the database. Session reads only use the database if the data is not already in the cache.
По сути, то же самое, что и описано.
Но иногда такой вариант не подходит, т.к. может не хватать скорости (кроме memcached работает еще и БД). Тогда идем в настройки и меняем SESSION_ENGINE, например, на 'django.contrib.sessions.backends.cache'. Данные сессий теперь хранятся только в кеше.
Причем кеш ведь тоже может быть разный — локальная память процесса, файлы, БД, memcached, можно и свое что-нибудь написать.
В итоге в большинстве случаев не тратится время на изобретение, обкатку и ремонт велосипедов.
Ничего не имею против варианта организации сессий, который тут описан, просто рассуждения.
Но ведь по сути, фреймворк — не более чем собрание чужих протестированных «велосипедов». Если понадобится какая-то из ряда вон выходящая возможность, придется разбираться в тонне чужих идей и в еще бОльшем количестве кода.
Я веду к тому, что не надо идеализировать тот же django. Если разрабатываемый проект полностью укладывается в возможности того или иного фреймворка, то тогда да, действительно, всё что нужно сделать — это просто использовать предоставленные наработки.
Я веду к тому, что не надо идеализировать тот же django. Если разрабатываемый проект полностью укладывается в возможности того или иного фреймворка, то тогда да, действительно, всё что нужно сделать — это просто использовать предоставленные наработки.
Вы, безусловно, во многом правы.
Но у меня есть 2 «но».
Первое «но» — очевидное. На практике в веб-разработке «из ряда вон выходящая возможность» встречается все реже и реже. Может у меня как-то сознание замутилось к вечеру, но сейчас сходу пример выходящей из ряда вон возможности не придумывается.
Препятствие чаще в том, что человек может не знать, как сделать какую-либо вещь простым способом, используя фреймворк, даже когда этот способ существует. Да, фреймворк требуется изучать, и на это нужно время и умственные усилия. Это обычно сложнее, чем изобрести отдельный велосипед и сделать все в «лоб», т.к. требуется часто как-то свои взгляды пересматривать, перенимать стиль мышления чужих людей. Да, и тут такое дело, если фреймворк выбран неудачно — время может быть потрачено почти впустую. Но в случае удачно выбранного фреймворка потраченные усилия окупаются с лихвой.
Второе «но» — идеологическое. Если каждый будет постоянно изобретать велосипед, мы никуда не придем.
В джанге той же есть свои уродства и ограничения, чего уж. Например, невозможность в ORM использовать несколько БД одновременно. Но над этим работают (проект на GSoC), и когда-нибудь этот вопрос будет решен. Как и многие другие вопросы.
И именно благодаря объединению усилий в итоге веб-приложения становится писать легче и приятнее — люди не изобретают свои велосипеды по отдельности, а пробуют проверенное, и стараются сделать это «проверенное» лучше, если их что-то не устраивает, пишут патчи и сторонние приложения. Все это вместе образует инфраструктуру, которая призвана минимизировать написание одного и того же кода по многу раз разными разработчиками. Если в этом «вариться» и представлять, что уже написано и писать не надо, а что еще не написано и будет полезно всем, то первое — жизнь упрощается, т.к. не пишешь велосипеды, и второе — мир становится лучше, т.к. пишешь и выкладываешь во всеобщее достояние то, чего там еще нет.
Тьфу, пафосно вышло, ну и ладно)
Но у меня есть 2 «но».
Первое «но» — очевидное. На практике в веб-разработке «из ряда вон выходящая возможность» встречается все реже и реже. Может у меня как-то сознание замутилось к вечеру, но сейчас сходу пример выходящей из ряда вон возможности не придумывается.
Препятствие чаще в том, что человек может не знать, как сделать какую-либо вещь простым способом, используя фреймворк, даже когда этот способ существует. Да, фреймворк требуется изучать, и на это нужно время и умственные усилия. Это обычно сложнее, чем изобрести отдельный велосипед и сделать все в «лоб», т.к. требуется часто как-то свои взгляды пересматривать, перенимать стиль мышления чужих людей. Да, и тут такое дело, если фреймворк выбран неудачно — время может быть потрачено почти впустую. Но в случае удачно выбранного фреймворка потраченные усилия окупаются с лихвой.
Второе «но» — идеологическое. Если каждый будет постоянно изобретать велосипед, мы никуда не придем.
В джанге той же есть свои уродства и ограничения, чего уж. Например, невозможность в ORM использовать несколько БД одновременно. Но над этим работают (проект на GSoC), и когда-нибудь этот вопрос будет решен. Как и многие другие вопросы.
И именно благодаря объединению усилий в итоге веб-приложения становится писать легче и приятнее — люди не изобретают свои велосипеды по отдельности, а пробуют проверенное, и стараются сделать это «проверенное» лучше, если их что-то не устраивает, пишут патчи и сторонние приложения. Все это вместе образует инфраструктуру, которая призвана минимизировать написание одного и того же кода по многу раз разными разработчиками. Если в этом «вариться» и представлять, что уже написано и писать не надо, а что еще не написано и будет полезно всем, то первое — жизнь упрощается, т.к. не пишешь велосипеды, и второе — мир становится лучше, т.к. пишешь и выкладываешь во всеобщее достояние то, чего там еще нет.
Тьфу, пафосно вышло, ну и ладно)
У сторонних фреймворков есть недостаток, либо тебе в нем что-то не нравится, либо когда заглядываешь в код, становится страшно и неприятно :(
> Действительно умные сессии и авторизация
Можно было бы пост назвать чуть по скромнее.
Sorry. Не буду прикапываться :-)
Можно было бы пост назвать чуть по скромнее.
Sorry. Не буду прикапываться :-)
Вы тоже сторонник
>ctime` int(11)?
Maybe
>function gpcvar_str(&$var) {if (is_array($var)) {return '';} return strval($var);}
function gpcvar_str(&$var) {if (!is_string($var)) {return '';} return strval($var);}
>ctime` int(11)?
Maybe
>function gpcvar_str(&$var) {if (is_array($var)) {return '';} return strval($var);}
function gpcvar_str(&$var) {if (!is_string($var)) {return '';} return strval($var);}
Я плакаль…
Смысл моей статьи был — обратить внимание на то, что мы обычно игнорируем, а не поделится кодом.
Смысл моей статьи был — обратить внимание на то, что мы обычно игнорируем, а не поделится кодом.
А разве это хорошо — хранить идентификаторы сессий в БД? На небольших проектах это, в общем-то, нормально. Но на небольших проектах точно также нормально хранить сессии и в файлах. Причем в файлах даже лучше — запрос идет по имени файла — просто открывается файл с нужными именем. А в БД идет строковый поиск по таблице идентификаторами — не лучший подход.
Ну а на больших проектах идентификаторы в базе хранить еще более невыгодно.
Если неправ, поправьте.
Ну а на больших проектах идентификаторы в базе хранить еще более невыгодно.
Если неправ, поправьте.
А Вы что думаете, файлы открываются просто так, и поиск по имени там не ведется что-ли?) Да те же самые индексы — хэши, деревья. Чудес не бывает)
БД лучше тем, что решение с БД масштабируется. А вот решение с файловой системой — нет. Скорость же сама по себе штука сложная, много от чего зависит, и говорить о ней абстрактно — бессмысленно, все лучше измерять и не верить своим прикидкам.
БД лучше тем, что решение с БД масштабируется. А вот решение с файловой системой — нет. Скорость же сама по себе штука сложная, много от чего зависит, и говорить о ней абстрактно — бессмысленно, все лучше измерять и не верить своим прикидкам.
Я говорю про небольшие решения.
Про большие — в чем минус хранения сессии в том же самом Memcache?
Про большие — в чем минус хранения сессии в том же самом Memcache?
В том, что при перезапуске memcached (или переполнении отведенной ему памяти — там данные вытесняются) данные о сессии пропадут. Memcache — это кэш, а не постоянное хранилище данных, и сохранность он не гарантирует. Это не минус, это особенность. Ее следует иметь в виду и принимать меры, когда надо. Например такие, как в статье.
1. Сами сессии хранятся исключительно в memcache.
2. Идентификаторы сессий в реляционной СУБД лежат для того чтобы при перезапуске сервера люди не теряли авторизацию. Еще для того чтобы получить список всех сессий для конкретного пользователя. При желании, это можно переделать на хранение в memcacheDB.
3. Вообще-то, если Вы не знали, файловая система при запросе какого-то файла, делает операции сродни операциям СУБД (ведет хеш-таблицы), однако в файловых системах этот процесс медленнее т.к. дерево обычно больше. Конечно можно завести отдельную файловую систему типа ReiserFS или btrfs исключительно под сессии, но нам нужно будет как минимум поверх поднять nfs для совместного доступа… я уж не говорю о том что придется извращаться с символическими ссылками и папками для того чтоб можно быстро получить все сессии пользователя. Выгоды не будет.
> А в БД идет строковый поиск по таблице идентификаторами — не лучший подход.
Про B-tree+ слышали?
> Ну а на больших проектах идентификаторы в базе хранить еще более невыгодно.
База идентификаторов запрашивается очень очень редко (при повреждении кеша и при нажатии «Выйти на всех компьютерах»).
2. Идентификаторы сессий в реляционной СУБД лежат для того чтобы при перезапуске сервера люди не теряли авторизацию. Еще для того чтобы получить список всех сессий для конкретного пользователя. При желании, это можно переделать на хранение в memcacheDB.
3. Вообще-то, если Вы не знали, файловая система при запросе какого-то файла, делает операции сродни операциям СУБД (ведет хеш-таблицы), однако в файловых системах этот процесс медленнее т.к. дерево обычно больше. Конечно можно завести отдельную файловую систему типа ReiserFS или btrfs исключительно под сессии, но нам нужно будет как минимум поверх поднять nfs для совместного доступа… я уж не говорю о том что придется извращаться с символическими ссылками и папками для того чтоб можно быстро получить все сессии пользователя. Выгоды не будет.
> А в БД идет строковый поиск по таблице идентификаторами — не лучший подход.
Про B-tree+ слышали?
> Ну а на больших проектах идентификаторы в базе хранить еще более невыгодно.
База идентификаторов запрашивается очень очень редко (при повреждении кеша и при нажатии «Выйти на всех компьютерах»).
>однако в файловых системах этот процесс медленнее т.к. дерево обычно больше
уверены? а СУБД не в рамках той же файловой системы работает? как может программа работать быстрее среды, в которой она выполняется?
Из интереса решил проверить на практике, набросал скриптик, который засекает время чтения строки из БД и отдельно время нахождения файла изображения по данным той же строки, прогнал в цикле 1000 раз — ФС до 10 раз быстрее.
уверены? а СУБД не в рамках той же файловой системы работает? как может программа работать быстрее среды, в которой она выполняется?
Из интереса решил проверить на практике, набросал скриптик, который засекает время чтения строки из БД и отдельно время нахождения файла изображения по данным той же строки, прогнал в цикле 1000 раз — ФС до 10 раз быстрее.
>решил поделиться действительно умной схемой, которая по всем параметрам превосходит предложенную
я так и не понял, а в чем превосходит то?
В быстродействии — не факт, полезность возможности «Выйти на всех компьютерах» сомнительна, ну разве что в «умности» реализации…
я так и не понял, а в чем превосходит то?
В быстродействии — не факт, полезность возможности «Выйти на всех компьютерах» сомнительна, ну разве что в «умности» реализации…
хмм… уважаемый, а какие у вас сейчас нагрузки и сколько в этй таблице записей? и насколько давно вы проектируете таблицы под MySQL?
`session_id` char(32) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
PRIMARY KEY (`session_id`),
KEY `uid` (`uid`)
) ENGINE=InnoDB;
у вас табличка колом не встала еще??
dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html
я конечно могу ошибаться, но дело в том, что насколько мне известно MySQL хранит данные в InnoDB физически кластеризуя их рядом в соответсвии с PRIMARY KEY, длинный PRIMARY KEY сильно повышает дисковый IO при сохранении идентификатора новой сессии
`session_id` char(32) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
PRIMARY KEY (`session_id`),
KEY `uid` (`uid`)
) ENGINE=InnoDB;
у вас табличка колом не встала еще??
dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html
я конечно могу ошибаться, но дело в том, что насколько мне известно MySQL хранит данные в InnoDB физически кластеризуя их рядом в соответсвии с PRIMARY KEY, длинный PRIMARY KEY сильно повышает дисковый IO при сохранении идентификатора новой сессии
Sign up to leave a comment.
Действительно умные сессии и авторизация