Сессии или регулярное обращение к БД ?

[StUV]

Сессии или регулярное обращение к БД ?

Есть таблица в БД (MySQL), описывающая основные разделы сайта (сейчас 50, предвидится не более 150). Записи описывают структуру сайта в виде дерева (id, pid, level, short_caption, ... + разные флаги и дескрипторы). Сейчас все организовано так, что при заходе на сайт все дерево качается из базы, анализируется, создаются дополнительные массивы для ускорения навигации и обработки данных и все это пишется в переменные класса с набором функций для обработки данных. Этот класс в конце работы скриптов сохраняется в сериализованном виде в сессию и, при переходе на другие разделы сайта все указанные операции не повторяются - структура сайта вытягивается из сессии и по id раздела строится страница.

Вопросы вот какие:
1. при росте кол-ва разделов обратил внимание, что уже сейчас сессионный файл занимает ~10Кбайт - много это или нет ?

2. не лучше ли было бы при заходе на раздел вытаскивать запись из базы по id раздела, обрабатывать (при этом может потребоваться выкачать из базы инфо всех предков раздела до корня - но уровней больше 5-6 не предвидется) и хранить в сессии только основные флаги (авторизация и т.п.) - таблица ведь небольшая и запрос должен выполняться достаточно быстро ?

Посоветуйте плиз. Или, может быть, идея с такой структурой изначально некорректна ?

Всем спасибо.

 

[Oleg Marchuk]

А ты попробуй и так и так.

 

[StUV]

А ты попробуй и так и так.

для этого надо разбить класс на два - сохраняемый/несохраняемый в сессии...
в принципе несложно - но при разрастании сайта тестить оба варианта постоянно ?
может кто сталкивался или просто знает (в силу глубоких теоретико-практических познаний в ИТ-области) ?

 

[Mammoth]

> ...много это или нет ?
Если ты боишься, что не хватит места под файлы сессий, то совет - вычисляй. Формула вычисления занятого места зависит:
1. от посещаемости;
2. шанса, что пользователь не подхватит ид сессии;
3. среднего отношения "кол-во хитов"/"юзер";
4. частотой чистки "покинутых" сессий.

> не лучше ли было бы...
Stuv - у тебя для каждого юзера своя структура сайта?

 

[StUV]

у тебя для каждого юзера своя структура сайта?

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

P.S.: возможно под твоим вопросом скрывалось нечто большее ? (если - да - скажи плиз конкретнее - я не догоняю

 

[eddie]

я делаю так (может пригодится)

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

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

при обновлении чего-либо -- просто update .. set cache=''

 

[StUV]

фактически ты все равно каждый раз дергаешь значение поля cache из базы, или хранишь его в сессии ?

 

[eddie]

поскольку я все-равно дергаю данные о запрошенной странице, то этим же selectом я и получаю cache

 

[sokol]

2StUV - это получается что для каждого юзера у тебя строится структура и записывается в сессию? Тебе не кажется что это крайне не рационально? Ну раз спрашиваешь значит кажется

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

Для этого можно делать так:
1. Сериализцем всю структуру в 1 файл.
2. При добавлении новго раздела делать рекурсивно Restore в файл, что ты и делаешь, но при каждом заходе нового юзера.
3. Флаг cache не нужен, т.к. файл переписывается только при изменении структуры.

Я для этого как-то использовал WDDX сериализацию, при этом не проблема будет построить карту сайта.

Да и xml парсеры могут распарсить содержание wddx пакета т.к. это допустимый xml.

 

[Orange]

Re: Сессии или регулярное обращение к БД ?

Originally posted by StUV
не лучше ли было бы при заходе на раздел вытаскивать запись из базы по id раздела, обрабатывать (при этом может потребоваться выкачать из базы инфо всех предков раздела до корня - но уровней больше 5-6 не предвидется) и хранить в сессии только основные флаги (авторизация и т.п.) - таблица ведь небольшая и запрос должен выполняться достаточно быстро ?

Дерево в 5-6 уровней и в 100-200 записей не большое. Вполне можно его обрабатывать каждый раз заново по id раздела. Можно конечно ускорить эту обработку, если в таблицу БД добавить дополнительное поле, которое будет хранить полный путь к предку верхнего уровня. Но в данном случае, мне кажется, нет смысла писать лишний код.

 

[clevel]

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

согласен, именно так и поступаю... это 2-ой уровень у меня в модуле 4-х уровневого логического кеширования страниц

 

[StUV]

2All:
наконец-то допер где [...] зарыта ...
дальше справлюсь своими силами...
всем спасибо

 

[varan]

Автор оригинала: eddie
при следующем запросе все данный уже беруться из этого cache. лишних запросов к базе делать не приходится

при обновлении чего-либо -- просто update .. set cache=''

Ага. Только если таблица имеет много записей, то эти cache сильно увеличат объем таблицы, особенно, если cache большой.
Кроме того, насколько это целесообразно? Если в поле cache хранится мало данных, то мне кажется по скорости эффективнее сделать пару select, чем один update.

Тем более, что скорость операций с таблицей сильно зависит от ее объема.

 

[eddie]

1. а если это не "пара select" ?
2. update делается один раз, до тех пор, пока данные не изменяться, а это (update информации на сайте) обычно значительно реже, чем запросы посетителей

если посчитать для некоего "среднестатистического сайта" -- то выигрыш получается значительный
ну вот к примеру -- допустим корпоративный сайт

сайт изменяется раз в сутки (обычно реже) и на него ходит 100 чел/сутки и какая-нибудь страница имеет пускай даже только +2 select (которые можно закешить) к основному, который берет данные о странице (там же и кеш)

считаем:
без кеша
1*100+2*100=300 sel
с кешем
1*1+2*1+update // это первый запрос при пустом кеше
1*99=99 sel
итого: 102 sel + 1 upd vs. 300 sel

даже если дополнительных селектов всего 1 -- все-равно выигрыш
а если их нет, то и кешировать ничего не надо, тогда и update не нужен