Какой способ менее ресурсоёмкий?

[jo0o00nyy]

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

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

 

[yeaahhh]

Спасибо большое, ребят. Всё-таки сделал через создание файлика:
Привязал ip к названию txt файла. (Оборот таких файлов планируется в размере 2-3 тысяч для начала..)
При добавлении записи, идёт проверка на наличие файла(ip) в папке, если такого файла нет, то создаётся файлик, где название файла = ip.
Поставил чистку папки по Cron'y..

Прочитал внимательно рекомендации.. Ещё раз спасибо. К сожалению, я пока только начинающий самоучка в php.. Так что пока прибегаю к методам, которые со стороны могут показаться смешными)

Чтобы не создавать новую тему, не могли бы Вы дать ссылочку или же вкратце написать способ снижения нагрузки на БД со стороны запросов?

Я так понимаю, что снижение делается через кэш? Т.е. непосредственно на запрос(Select) нужно будет вешать какой-то обработчик, который будет держать кеш, верно? И при запросе (Insert/Update будет происходить очистка кэша?).. так?)

 

[Virtual]

По файликам - у меня отложилось стойкие рекомендации одного серьезного админа. И звучит примерно так: не больше 2к записей на каталог. Тоесть, либо 2000 каталогов, либо 2000 файлов в каталоге. Таким образом, если планируется скажем 10к уникальных ип - то лучше все это распихивать по 5 папкам.
Оборот для начала... )) Напомнило пословицу: никогда нет времени сделать нормально и сразу, зато всегда есть время 10 раз переделывать потом. ) По проверке уникальности - если не обходить все папки для удаления файликов, то настанет момент времени, когда место на жестком диске может кончиться. Либо количество этих файликов побьет все мыслимые и не мыслимые рекорды... Т.к. реально - файлы не будут удаляться вообще. Т.к. пользователь зашел => проверили, файл есть, дата старая, => удалили (или обновили дату) => создали новый,такой же. (пользователь ведь зашел). А если пользователь не зайдет больше никогда? Файл останется.
поэтому, обходить время от времени придется...

Не надо изобретать велосипед с кэшем. Кэш отличный есть в самих базах данных. В некоторых случаях можно использовать таблицы с типом HEAP. А вообще - грамотное проектирование БД - и нагрузка минимальна. А это и индексы, и структура, и продумывание ключевых запросов, чтобы не дрючить лишний раз ничего, либо наоборот, сделать лишних 2-5 запросов бывает куда быстрее, чем 1 объемный запрос..

Почитать стоит о типах баз, и об индексах. Индексы - в обязательном порядке. google.com, "оптимизация запросов mysql" вот эту ссылку, топ5 или даже 10, даже если речь не о mysql, даст общее понятие.

 

[venetu]

Чтобы не создавать новую тему, не могли бы Вы дать ссылочку или же вкратце написать способ снижения нагрузки на БД со стороны запросов?

Тебе ж писали выше

 CREATE TABLE `myglam`.`ips` (
`ip` INT NOT NULL ,
`time` TIMESTAMP NOT NULL ,
PRIMARY KEY ( `ip` )
) ENGINE = MYISAM;

$query = "SELECT 1 FROM ips WHERE `ip`=" . ip2long($_SERVER['REMOTE_ADDR']) . " AND `time` > DATE_SUB(NOW(), INTERVAL 3 HOUR)" ;
list($found) = mysql_fetch_array(mysql_query($query));
if ($found) {
  // ..  уже недавно был замечен
}

// добавление
$query = "INSERT INTO ips SET `ip`=" . ip2long($_SERVER['REMOTE_ADDR']) . ", `time`=NOW();"
mysql_query($query);

// очистка
$query = "DELETE FROM ips WHERE `time` < DATE_SUB(NOW(), INTERVAL 3 HOUR)" ;
mysql_query($query);

По таймстампу я бы ключ не делал (там 99% записей будут разные, т.е. индекс по размерам окажется не меньше самой таблицы), но это лучше протестить на реальных данных, так и так.

Я так понимаю, что снижение делается через кэш? Т.е. непосредственно на запрос(Select) нужно будет вешать какой-то обработчик, который будет держать кеш, верно? И при запросе (Insert/Update будет происходить очистка кэша?).. так?)

Mysql сам отлично все кеширует. Убери в запросах WHERE `time` > DATE_SUB() - и все великолепно будет в кеше. Но тогда и базу нужно будет чистить не когда придется, а более-менее часто, раз в час хотя бы, чтобы у тебя таймаут был +- полчаса. Ну а значит все квери старше 1 часа будут сбрасываться, при почистке базы.

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