бд, сортировка, нужен совет

А может вообще на клиенте javascript'ом cделать?

тогда расскажи как к $_SESSION обратиться через javascript

oO

Если усё делается в форме таблиц, то есть приличное количество скриптов для создания интерактивных табличек

фрейморк jQuery, prototype
что-то типа divSlide это я понимаю
но подустим что есть некий товар
который включает в себя картинку 140х140(для примера)
пот description типа text + еще 2,3 полей типа varchar, 2,3 - int

и таких товаров порядка 100
вам не кажеться что клиет просто устанет ждать пока подругрузяться все скрытыет дивы/таблы ?


ну или я не правельно вырозился

хорошо тогда еще одно условие объем данных не такой уж и мальенький что бы его за раз выдовать клиенту =)

вот

> где-то в умной книге прочитал

"Пыхопе для умалишенных" не может называться умной книгой.. В других такое не напишут.

> как я понимаю это связано с тем что бы при желании пользователя отсортировать посты/товар не соединяться с бд а просто вынимать данные из session

А сессии, конечно же, лежат в божественной безразмерной RAM с нулевым временем доступа :)

> где-то в умной книге прочитал что всю сортировку данных случше делать не в самой бд а уже в php/perl/etc

Про индексы аффтары "умной книги", разумеется, не слышали?

Абсолютно неоправдан:

- СУБД хранит данные в специальном формате, позволяющем проводить подобные операции значительно быстрее, чем при работе с сессией;

- СУБД имеет массу механизмов, позволяющих добиться высокой производительности для оптимизации таких операций (те же индексы);

- СУБД позволяют работать с гораздо большими объёмами данных (сильно я сомневаюсь, что тебе удастся отсортировать табличку хотя бы в 1 млн. записей, посредством сессии).

равносильно этому http://www.linux.org.ru/view-message.jsp?msgid=2393960&lastmod=1200040457434

ну на самом деле ты отчасти прав: ebay, google ads (могу ошибаться) говорят о том, что они сортируют данные вне базы, НО: они знают что делают, они к этому пришли не сразу, они сортируют не всё и они это делают не на похапе

всем спасибо за ответы 

если бы пожно было бы то r_asia и Pi поставил бы по +2
r_asia даже бы +3 поставил =)

да совсем забыл большое спасибо все там типа plasma, ответы которых просто вносят фантастическую ясность в проблемму =)

зы а мне таки кажеться что в моем случае это можно реализовать
объясню почему, приведу пример на web магазине
как вступление скажу что $sessoin храню не на диске а в бд
( вроде как у бд скорость считывание немного выще ) и
объем выборки не будет превышать 4096 кб (без картинок, и мы не говорим о выборке в 1 млн )

=> если я засуну все данные $session то мне нужно будет зделать на 
один запрос меньше, и там запрос будет вида 
select * from session_variable;
а не select * from gd_view where catid=xxx
т/е/ теоритически работать должно быстрей

вот только нужно придумать как лучше отсортировать массив вида
$selected = array {
               0 => array {
                   'id',
                   'name',
                   'price',
                   ....
               }
            }

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

вообщем кому интерестно - наверное на днях проведу тесты  - отпишусь =)

зы на самом деле на учел все ответы =)
всем спасибо

я тебе косвенно сказал "юзай субд"!

>т/е/ теоритически работать должно быстрей

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

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

пусть попробует, похапе - это глобально и надежно, почти ынтырпрайз. Про SQL не выдавай тайны, только слабые и хилые могут юзать его, крепкие сибирские мужики сортируют все скриптами ...

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

=)
хорошо всем спасибо

зы 2Pi - я не обижаюсь, thx =)
зыы 2Pi - поуйду качать ispell ))

> r_asia даже бы +3 поставил =)

Лучше-б ты ему синяк под глазом поставил. Надо же такое выдумать: "СУБД хранит данные в специальном формате, позволяющем проводить подобные операции значительно быстрее, чем при работе с сессией". Чудес не бывает, и скорость винчестера не зависит от специального формата и значительно ниже скорости доступа к памяти. И индексы тоже не для сортировки вывода придуманы, хотя конечно, если условие сортировки совпадает с индексом - то это хорошо, но так бывает далеко не всегда, а плодить индексы на каждый случай - это тоже идиотизм, потому что чтение-запись индексов дополнительная нагрузка канала IO, да и место для их хранения не резиновое. И даже в сортировке таблички в сотню миллионов записей вебовском процессе нет ничего принципиально ужасного, если они все помещаются в памяти: СУБД будет делать то же самое на том же процессоре, разницы нет. Кроме той разницы, что у тебя каждая сессия должна будет кешировать своё подмножество общих данных - в этом плане экономичнее кешировать данные в общем месте - кеше СУБД (у них ведь есть свой кеш в памяти) откуда СУБД и будет выдавать сессиям их строчки по каждому запросу.

> => если я засуну все данные $session то мне нужно будет зделать на > один запрос меньше, и там запрос будет вида > select * from session_variable; > а не select * from gd_view where catid=xxx > т/е/ теоритически работать должно быстрей

Ерунда.

Во-первых "select * from session_variable;" не канает, поскольку у тебя сессий могут быть тысячи на рабочей нагрузке, так что как минимум "select * from session_variable where session_id=.."

Кстати, сколько у тебя будет одновременно активных сессий (уникальных клиентов одновременно кликающих по сайту), сколько они будут храниться в базе данных (кол-во строк таблицы session_variable = число всех сессиий * на среднее количество собственно переменных)(плюс нагрузка -как часто все эти уникальные кликальщики будут тюкать мышью в твой сайт?), и каков механизм удаления устаревших сессий (очень часто они так и хранятся навечно)?

Во-вторых ты будешь дублировать данные. Все эти записи уже лежат в gd_view, СУБД, если она не написана сумашедшим маньяком, блобы хранит отдельно (в поле записи д.б. указатель где лежит блоб - и всё) и так, что бы не качать их с диска на каждое обращение к строкам таблицы не требующее данных блоба, которые потенциально могут иметь огромный размер. Т.е. нормально СУБД обрабатывает запросы пользователей и наиболее часто запрашиваемые данные и индексы кеширует в памяти - чем больше памяти в кеше - тем больше она там закеширует данных и тем реже будет ходить за ними на мееееедлеенннный диск. Дублируя набор данных в таблице сессий ты лишь удваиваешь нагрузку на кеш СУБД и тем самым снижаешь производительность системы заставляя СУБД чаще заглядывать на диск.

В крайнем случае в session_variable можно хранить значения первичного ключа строк gd_view или их rowid'ы и селектить из gd_view where gd_primary_key in (select value from session_variable where session_id=xxx and variable_name=yyy)

> наверное на днях проведу тесты - отпишусь =)

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

>Ерунда. 

>Во-первых "select * from session_variable;" не канает, поскольку у >тебя сессий могут быть тысячи на рабочей нагрузке,
 так что как >минимум "select * from session_variable where session_id=.." 

>Кстати, сколько у тебя будет одновременно активных сессий (уникальных клиентов одновременно кликающих по сайту),
фактически для каждого клиента свой id,

> сколько они будут храниться в базе данных 
 private $session_lifespan = 1209600; // длинельность сеанса 1 день
> (плюс нагрузка -как часто все эти уникальные кликальщики будут тюкать мышью в твой сайт?), 
пока не часто, но думаю со временем число должно возрасти 

>и каков механизм удаления устаревших сессий (очень часто они так и хранятся навечно)?
см ниже

$md5 = md5($_SERVER['REMOTE_ADDR'].$_SERVER["HTTP_USER_AGENT"] ); //хочу немного изменить, добавить возможно более лучшей идентификации клиентов
            

// сама проверка сеанса
              $this->php_session_id = $_COOKIE['PHPSESSID'];
              $res = $this->dbhandle->SessionQuery (SELECT sql_cache id, last_impression, logged_in, user_id, remember FROM user_session
 WHERE ( (ascii_session_id=$this->php_session_id) AND (hash = $md5) AND (last_impression - $this->session_lifespan > 0) ));

// добавление в бд
if($res == false)
{
$this->native_session_id = $this->dbhandle->SessionQuery(INSERT INTO user_session VALUES(null, $id, time(), time(), 0, 0, $md5, 0));
}


// механизм удаления, вызываеться когда заходит клиент с устекщим сроком сессии
$remove = $this->dbhandle->SessionQuery(delete from user_session
 where (ascii_session_id=$this->php_session_id) or (time() - created) >$this->session_lifespan);



зы ты просто хотел тебе сказать спасибо =)
вообщем ради таких как вы я и задаю свои глупые вопрос
спасибо !

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

> В крайнем случае в session_variable можно хранить значения первичного ключа строк gd_view или их rowid'ы и селектить из gd_view where gd_primary_key in (select value from session_variable where session_id=xxx and variable_name=yyy)

да согласен, еще раз thx
таки так сделаю

> фактически для каждого клиента свой id,

Это понятно, что они должны идентифицироваться, с точки же зрения производительности важно сколько их будет.

> пока не часто, но думаю со временем число должно возрасти

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

>> механизм удаления, вызываеться когда заходит клиент с устекщим сроком сессии

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

> Это понятно, что они должны идентифицироваться, с точки же зрения производительности важно сколько их будет.

скажем 40-60 запросов в минуту ( это не сильно большой показатель как я понимаю, верно ? )

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

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

пиковые нагрузки ?
я думаю где-то 10 - 15 клиентов одновременно будет это точно

> Вот-вот, а если он никогда не придёт? У тебя же на каждого нового клиента создается сессия, в т.ч. на всех ботов и случайных пришельцев с Гугла - они же никогда не вернутся, а если и вернутся, то ты просто пересоздашь запись в таблице.

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


ps сделал что ты посоветывал - действительно, производительность заметно возрасала !
у меня к тебе вопрос, существуют ли какие-то программы\боты, с помощью которых можно нагрузить сайт с целью протестить производительность ?

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

psss редко пишу т/к/ сейчас сессия, не всегда есть время заниматься сайтом (

еще такой вопрос
по поводу взаимосвязи пользователь\нагрузка, а точнее, заметил что не
многих сайтах ограничивают действия пользователя в плане нагрузки
сервера

допустим ставят ограничение - не добавлять более 1 сообщение за N секунд
не делать поиск чаще чем раз в 10 сек

на чем основываются такие алгоритмы ?
т.е. какие задержки ставить что бы сильно не раздражать пользователя
и в тоже время защитить себя от DDOS и т.п. ?

> скажем 40-60 запросов в минуту ( это не сильно большой показатель как я понимаю, верно ? ) .. > пиковые нагрузки ? > я думаю где-то 10 - 15 клиентов одновременно будет это точно

А как ты предлагаешь судить большую ли нагрузку на систему оказывают 10-15 клиентов, каждый из которых отгружает по 4 запроса в секунду? Смотри что делается по этим запросам, если у тебя на каждый http-запрос базе приходится шерстить гигабайты данных на диске или приложению считать что-нибудь хитрое и навороченное - то 40-60 запросов может оказаться и много. У меня, например, дома очень узкий аплинк и поэтому при попытке разместить страницы с множеством картинок, я упираюсь в ширину сетевого канала. А на нормальном внешнем хостинге этого бы не было, там скорее были бы заморочки связанные с повышенной нагрузкой на ресурсы сервера.

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

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

Это так называемый "poorman's cron" т.е. "cron для бедных". Плох тем, что срабатывает в самый неподходящий момент, когда клиент ожидает ответа системы, а это время очень важно с точки зрения удобства пользования. К тому же грузить систему "хозяйственной" деятельностью лучше вне пикового времени, когда нагрузка на систему минимальна - например когда у твоей аудитории ночь или согласно собранной статистике происходит минимально количество обращений.

> у меня к тебе вопрос, существуют ли какие-то программы\боты, с помощью которых можно нагрузить сайт с целью протестить производительность ?

Выше чем до колена, посмотри тут например: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Internet http://www.ict4us.com/testtools/loadandperformancewikipedia.htm http://www.dmoz.org/Computers/Programming/Software_Testing/Load_and_Performan...

Это разумно прогрузить систему и помониторить во что у тебя упирается производительность - что при этом загружается под 100% : память, cpu или i/o.

> pss никогда не читал дзен ?

Нет, он в моей прикладной области малоприменим.

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

А вот Publilius Syrus сказал так: "Кого уважают, тем никогда не льстят, потому что уважение чтит, а лесть насмехается".

> psss редко пишу т/к/ сейчас сессия, не всегда есть время заниматься сайтом (

Эт правильно - учеба первична.

>допустим ставят ограничение - не добавлять более 1 сообщение за N секунд не делать поиск чаще чем раз в 10 сек

>на чем основываются такие алгоритмы ?

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

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

> т.е. какие задержки ставить что бы сильно не раздражать пользователя

ИМХО нулевые :-)

> и в тоже время защитить себя от DDOS и т.п. ?

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