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

[yeaahhh]

Друзья. Встала необходимость записи ip адресов пользователей, которые добавляют записи на сайт. Как лучше сделать? Записывать в БД или в файл txt?
Я склоняюсь к записи в txt файл. Просто не имел опыта с записью в txt.. И решил у Вас узнать, практикуется ли такой метод записи в похожих ситуациях?
А ситуация такая:
После того, как пользователь добавит "комментарий", его ip будет записываться для запрета публикации..(будет стоять проверка на наличие его ip в этом файлике.)
К слову: файлик будет чиститься каждые 24 часа..
(Т.е. пользователь может добавить 1 комментарий в 24 часа)
Очень уж не хочется нагружать БД дополнительными запросами..
Как думаете, разумная идея?

 

[diavolic]

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

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

 

[CrashX]

в бд...
я бы завел доп поле в нужном моедуле и при добавлении проверял бы вложеным запросом или дополнительным есть ли такой ип скажем за 30 минут и все...

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


тк скажем я дома разраю инет на 5 квартир, а ип на всех один))))))

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

 

[venetu]

Вообще-то в продвинутых системах антифлуда это делается и не через базу, и не через файлик, а через тысячи файликов в разных папках.
Структура типа такой:

/192
   /168
      /0
         192.168.0.1
         192.168.0.3
      /5
         192.168.5.10
/193
....

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

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

В твоем случае я бы делал через один файл. Во-первых, потому что больше нескольких тысяч IP в нем не будет, а значит file_get_contents() элементарно все выгребет в память. Во-вторых, потому что файлы и память в юнихе - вещь довольно относительная, обращение к дисковой системе на деле далеко не всегда вызывает физическое к ней обращение, добрая половина всяких таких часто используемых файлов навечно сидят в кеше. А эначит и твой файл будет в кеше.

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

Через базу конечно проще, но и нагрузки будут посерьезнее. Хотя в твоем случае что так, что так - один хрен не заметишь, скорее всего.

 

[diavolic]

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

ты только что описал работу индекса в БД может все таки БД а не ФС?

 

[Yaggi Jah]

Если только log, то пиши в файл. Если нужно при каждом запросе искать ip, то лучше через "тысячи файликов в разных папках" или пиши в БД, но предварительно делай ip2int.

 

[Virtual]

Я бы делал в базе, а не в файликах. И уж тем более, не в "тысячах файликов в разных папках".. ) Таблица из двух полей, оба типа инт, в первом - уникальный индекс ип, во втором - индекс время захода.
Запросы - простейшие. нагрузки - ноль. Если трафика не много, то тип таблице вообще можно поставить heap. Тогда она физически будет находиться в оперативке.
Итого, вся нагрузка - это 2 запроса к базе. Один - при добавлении комента, второй - при чистке таблицы, который запускать можно скажем раз в пару часов. Нагрузки - фактически никакой, даже при трафике в 200к уников в сутки, на каком-нибудь древнем p4.

 

[venetu]

Я бы делал в базе, а не в файликах. И уж тем более, не в "тысячах файликов в разных папках".. ) Таблица из двух полей, оба типа инт, в первом - уникальный индекс ип, во втором - индекс время захода.

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

Про "тысячу файликов в разных папках" - это я не сам придумал, это реально так делается. Не знаю, зачем. Честно. )

 

[jo0o00nyy]

Про "тысячу файликов в разных папках" - это я не сам придумал, это реально так делается. Не знаю, зачем. Честно. )

Если складывать все файлы в одну папку, то при больших кол-вах (10к+) файлов скорость доступа к файлу увеличивается и скорость работы скрипта падает... + если понадобится удалить, скачать пару файлов через ФТП, то можно уснуть, пока откроется эта папка.

 

[Virtual]

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