Для начала - не начинай вопрос с того, что тебя уже где-то послали Потому что появляется подсознательная мысль "а по делу послали, наверное..."

По сути вопроса. Я лично не понял сути записи "LIMIT 0,9" в конце SELECT'а. Там, вроде как, должно быть целое число больше нуля, которое как раз и ограничивает число записей. Например, укажешь 10 - и только 10 первых записей будут выбраны.

Никак нет. В этом то я чуть чуть разбираюсь. "LIMIT 0,9" означает, что будут выбраны первые 9 записей, подходящие под условия, начиная с 0-ой. Если указать "10,9", то будут выбраны 9 записей, начиная с 10-ой.
Нужен принципиально другой подход... а какой - не знаю...

Насчет синтаксиса сорри, погорячился я немного Я подразумевал LIMIT в PostgreSQL, а не в MySQL. А у них есть различия.
Ты написал "Скрипт top.php делает следующий запрос (привожу уже с подставленными параметрами переменных):" - а этот запрос действительно в таком виде формируется? Ты делал его контрольный вывод или только предполагаешь, что он такой должен быть после подстановки?

Да, в таком виде. Да, делал контрольный вывод. Более того, я взял конкретный пример (но он не единственный), который предъявляет мне хостер в специальном присланном сообщении мне.

Тут по-моему без упрощения структуры БД не обойтись, вариант который мне представляецца: отказацца от записи IP'а в этой таблице, вынести защиту от накрутки в отдельную, также в таблицу load_logs добавить числовой параметр count, и добавлять записи в таблицу только через какой-то определенный интервал, иже раз в минут, 5 минут, час... в остальных случаях увеличивать count текущего временного интервала, просто с твоими нагрузками - у тебя выходит:

24 часа * 60 минут * 60 секунд = 86400 секунд / 15000 загрузок = 5.76 секунд на одну загрузку

Тоесть новая запись появляется в среднем раз в 5 секунд. Надо-ли оно?
Если сделать интервал по-крайней мере минуту - это уже 1,440 записей в БД, вместо 15,000, и 43,200 записей за месяц, вместо 450,000... согласись, разница в 406,800 записей - это уже неплохо, а это всего-лишь обновление картинок раз в минуту а не раз в 5 секунд, а если поставить 5 минут - это уже 288 записей в день, и 8,640 записей в месяц, это уж любой хостинг потянет. Не думаю что для отображения популярных картинок нужна такая уж запредельная динамичность, какая стоит сейчас.

Зачем? Каждая картинка имеет параметр count_download. При скачивании это поле увел. на 1. Запрос получиться на ТОП очень простой.

Проверку на IP ... надо подумать другое решение....

2LoneCat
Большое спасибо, мне нравится твоя идея Именно так и сделаю! Отпишусь, как получилось. По идее все верно и динамичность останется довольно большой, раз в 5-10 минут вполне достаточно. А при последующем увеличении посещаемости можно будет просто увеличить интервал.

То есть делать так:
1. Ищем запись в логах с "`stamp` > (NOW() - INTERVAL 5 MINUTE) and `id_pic`='$id'".
2. Если есть, то увеличиваем параметр count.
3. Если нет, то добавляем новую запись со значением count=1.
Ок. С этим все понятно. А что делать с выборкой? В моем запросе просто считается количество записей. А тут каждая запись получается имеет свой "вес" - картинку могут скачать и 2 раза за 5 минут, и 5 раз, и 1 раз. Каким образом это учесть? Если можно, помогите с перестройкой запроса. Вот это мне не понятно.

И еще. Нужно ли здесь расставлять индексы? Если нужно, то на какие поля?

2Sylex
Если вы внимательно прочитали мою тему, то наверняка должны были заметить, что этот способ мне не подходит:

Сижу, думаю. И вот, неувязочка, однако! Смотри: самая популярная картинка обычно не имеет более 100-150 загрузок. Поэтому твои расчеты не будут работать. К примеру, чел скачал одну картинку, затем вторую, затем третью (разные) за 1 минуту. И эти записи будут все добавлены, несмотря на то, что будет стоять интервал. А расчеты работают только если идут запросы к одной и той же картинке. Так у меня и так стоит антинакрутчик на минуту где то.

Вот... только если сделать обновление раз в несколько часов ... и то ... должного эффекта могу и не добиться. Но надо попробовать.

Вопрос открыт, жду предложений.

Мне так кажется... Надо переделывать сам алгоритм. Чтобы БД меньше росла. И чтобы увеличить производительность.

Например, делаешь в БД запись для каждой картинки. Одну уникальную на один день (для каждой картинки). В этой таблице нужны будут такие поля: дата, идентификатор картинки, количество загрузок за текущий день, время последней загрузки. И по мере обращения к картинке апдейтишь количество и время (или создаешь новую запись, если это первое за день обращение). Прибавка записей в день не будет превышать общего количества картинок.
Насчет "антинакрутки" не понял... Кто-то специально может вызывать определенную картинку неадекватно большое число раз? Если это так, то делаем еще одну таблицу. С полями дата, IP компьютера, идентификатор картинки. При обращении проверяем, есть ли уже запись этого пользователя в БД, для данной картинки. Если есть (было обращение данного юзера к данной картинке) - то ничего не делаем. Если такого обращения не было, то делаем дополнения как к данной таблице, так и к первой таблице (предыдущий абзац). Максимально возможное количество новых записей за день равно произведению количества пользователей на количество картинок... Но реально будет меньше И уж точно не превысит твои 15000 ежедневных обращений.

И еще... Я так понял, что ты не используешь встроенные в БД функции? Если это так, то в данном случае их как раз стоит использовать, т.к. это уменьшит количество внешних запросов к БД и уменьшит время обработки. Т.е. то, что я описал в предыдущем абзаце (про 2 разные таблицы) лучше бы делать через встроенную функцию. Передал ей идентификатор картинки и IP юзера - а дальше уже сама БД (ее функция) будет решать, что и куда добавлять. А твой скрипт будет только брать данные у БД.

Собственно говоря... Формирование списка "ТОП 10" ты можешь делать также во встроенной функции и потом забирать его оттуда. При правильной организации работы на этом тоже можно время съэкономить.

Ну... А уж как с этим всем работать, мне так сдается, ты и сам разберешься Я только про идею сейчас говорил. "Моцик не мой, я только разместил объяву" (С)

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

Устанавливает всем записям старше дня - одинаковую временную метку, обрезая время - иже дата остаецца прежней, а время ставицца в 00:00:00


Прописываем всем рядам с одинаковой меткой времени в count сумму всех значений count группы


Итого у нас получаецца что

id / stamp / count
1 / 25.03.2008 13:00 / 5
2 / 25.03.2008 14:00 / 7
3 / 25.03.2008 14:30 / 10

Мы преобразуем в:

id / stamp / count
1 / 25.03.2008 00:00 / 22
2 / 25.03.2008 00:00 / 22
3 / 25.03.2008 00:00 / 22

И вот с удалением дубликатов я повис, толи с помощью PHP их сначала читать, а-ля



А потом каждый полученный ряд удалять через



Или что-то с MySQL'ем поумнее намудрить, но сама суть в чем - ты-же не собираешь статистику какая картинка была самой популярной 45 дней назад, с 13:00 до 15:00, соот-но данными о времени можно пренебречь, собрав несколько полей в одно, из минусов - обновление будет грубо говоря раз в сутки, потому как если был скачок посещений одной картинки 17-го, то как только наступит 26-ое 00:00 - недельная статистика картинки резко упадет на значение этого скачка. Хотя если уж действительно нашаманить с базой данных - можно сделать таких операций несколько, сжимая статистику предыдущего дня - до раз в 15 минут, предпредыдущего - до раз в час и т.п., иже поступенчато.

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

2sergeiss

Да, может. Кто нибудь загрузит картинку и начинает тыкать на нее, она и висит в топе целые сутки, пока эта срань не опустится Либо еще и скрипт как напишет, что как вылезет в топ! Поэтому организовал защиту. И она уже есть, для этого и записывается у меня IP в логах загрузок.


Чем отличается это от того, чтобы создать поле в записях картинок `loads_today` и обнулять его просто каждый день? Этот вариант не подходит опять же из за столь редкого обновления.


Что за встроенные функции? Нет, не использую. Где про это прочитать можно и какая от них польза? Это что то вроде функций в PHP? Я создаю функцию, а она потом работает, так что ли?

Может это и не имеет значения, но на всякий случай скажу, что у меня не топ 10, а полноценный топ многостраничный по всем картинкам.



2LoneCat

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

Вообще недельной и месячной статистикой я могу пренебречь, так как она пользуется ничтожной популярностью. Особенной популярностью пользуется почему-то именно дневная и "за все время". "За все время" щас и так работает тупо по общему кол-ву загрузок. А дневная отключена щас, а ведь был самый популярный раздел на сайте.


В любом случае ваши рассуждения натолкнули меня на одну очень, на мой взгляд, неплохую мысль, что то вроде симбиоза ваших мыслей. В общем, оцените, вроде просто и действенно.
Что если тупо создать отдельную таблицу с id картинки и 24 полями, означающих соответствующую часть суток. Ну или хотя бы 12. И в каждый временной интервал инкременировать соответствующее поле. При наступлении каждого часа CRON'ом обнулять новый час.

Что это дает? Да это дает все! Автоматически данные, записанные сутки назад, стираются и записываются новые. Думаю, 12 или 24 поля это не очень много. Как идея? По-моему, должно отлично работать. И кол-во просмотренных строк вообще не будет превышать 9 ти (если запрашивать 9 самых популярных и так далее на каждой странице далее тупо использую LIMIT), верно же? И обновление раз в час вполне норм. Ну как раз в час .. даже чаще, просто уменьшаться будет только раз в час.

Но для этого по ходу надо сделать 26-е, последнее поле, которое будет являться суммой все полей. Это случайно нельзя сделать как нибудь автоматически средствами MYSQL? Еще и индекс сделать по id картинки, так вообще конфетка будет. Только попробуйте сказать, что такая схема работать не будет! С нетерпением жду ваших дальнейших рекомендаций

Ищи в хэлпе (или в и-нете) по словам Stored Routines, Stored Procedures, Stored Functions, Triggers. Это программы, функции, триггеры, которые работаютс с БД вне зависимости от того, через какую программу ты обращаешься к БД. Нормальная БД поддерживается серверной программой, которая как раз и работает с этими объектами.
Например, твой скрипт может поддерживать целостность данных. Но другой скрипт или программа, обратившись к той же БД, могут эту целостность нарушить. Но: при использовании хранимых (встроенных) процедур эта проблема исчезает. Потому что вне зависимости от того, откуда приходит запрос сделать то-то и то-то, будут выполнены определенные дополнительные действия.
Также, вместо организации сложного запроса (на много связанных таблиц) можно эту задачу переложить на встроенные процедуры. Ты один раз ее отлаживаешь, а потом запрашиваешь данные как через простой запрос. И тогда из разных частей одного скрипта или из разных скриптов ты можешь вызывать эти данные и быть уверенным, что полученные данные достоверны. А второй раз ты потратишь на организацию запроса очень мало времени.

Говоря "ТОП 10" я условно имел ввиду


Да, можно и такое поле создать.
И я не понял - где тут редкое обновление? Я же говорил о том, что эти записи обновляются при каждом обращении к определенной картинке.
Отличие от твоего первоначального варианта в том, что при обращении не делается уникальная запись, а обновляется существующая (если она уже была создана). НО!!! Я говорил про проверку того, что какой-то юзер уже "втыкал" в эту картинку. В этом случае также вовсе не обязательно делать запись в БД, а можно только обновить запись для данного юзера и для данной картинки (во второй таблице).

А насчет алгоритма... Да, описанный тобой алгоритм будет работать. Только я не до конца понял логику. Ну хорошо, ты видишь сумму обновлений каждый час. Но в начале каждого часа все равно происходит обнуление данных!!!
Да и вообще, тогда уж лучше создать 24 записи, с полями "дата", "час", "количество". И тогда вопросы суммирования за день решаются легко и просто. Но чем это принципиально отличается от того, что говорил я ? Только уменьшением интервала до одного часа? Но только все равно в начале каждого часа будет неопределенность, т.к. на первое место будут выходить картинки, которые первыми посмотрели. Можно, конечно, в течение некоторого времени (например, минут 15) с начала часа текущего показывать статистику часа предыдущего, пока копятся данные.

И еще... Я бы, мне кажется, ограничил этот ТОП одной страничкой или каким-то разумным количеством. Какая разница, какая картинка находится например, на сотом или 150-м месте? Более интересно, какие картинки возглавляют список популярных.