Хранить логи посещений в БД.

поэтому для идентификации решено использовать куки

Ага, особенно когда других вариантов нет.

планирую на одно открытие станицы делать одну запись в таблице

При 100 000 в месяц, хоть по 100 sql запросов.

Спасибо за поддержку :)

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

Использую Rails, здесь сессия чистится после закрытия браузера. А у меня борьба с злостными риэлторами-спамерами :)

Использую Rails, здесь сессия чистится после закрытия браузера. А у меня борьба с злостными риэлторами-спамерами :)

А сохранять сессию/куку на месяц нельзя что ли?

Уточним:

Я делаю куку на 20 лет, в ней хранится уникальный uuid.

Дальше записываю в БД этот uuid и начинаю писать (ссылающиеся на него) записи о посещённых страницах.

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

Плохая идея.

Какой смысл хранить ВСЕ посещения, если достаточно только помнить, сколько объявок у каждого (псевдо)юзера за последние сутки?

Но на самом деле, это тоже не нужно. Достаточно в куках хранить количество объявок за сутки. Время жизни куки, разумеется, — сутки.

Ещё быстрее и ещё удобнее.

Твоё мнение не учитывается. Плохо себя вёл последние три года.

Но в Blackened хоть можно поиграть? ТТ

пользователи незарегистрированные, поэтому для идентификации решено использовать куки.
борьба с злостными риэлторами-спамерами :)

Не взлетит. У тебя будут потоянно появляться новые пользователи, постить по три сообщения и пропадать.

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

Злостные риэлторы-спамеры используют специализированное ПО

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

Уточним:
Я делаю куку на 20 лет, в ней хранится уникальный uuid.
Дальше записываю в БД этот uuid и начинаю писать (ссылающеся на него) записи о посещённых страницах.
Хранить страницы удобно тем, что можно будет построить некие правила открытия/закрыти доступа после.

Сделай сессию на 20 лет. Только не понятно зачем 20 лет? Время жизни обновляется при каждом запросе, тут и месяца хватит. Основная задача отсеить пользователей, которые сильно много публикуют объявления, а значит они часто пользуются сервисом (несколько раз в месяц) и сессия будет каждый раз обновляться и никогда не умрет.

На сервере механизм сессий должен сам генерировать уникальные UUID и писать куки с этим UUID пользователю в браузер. На сервере сессии можно хранить где угодно (как настроишь). В сессию можно также записывать ID объявлений и даты. Через месяц неиспользования сервиса кука и сессия сами удалятся и не будут засирать БД. Можно сделать время жизни год, если за год пользователь не воспользуется сервисом, то данные удалятся. Думаю этого вполне достаточно для отсеивания спамеров. Сессии на сервере можно хранить в Redis (СУБД ключ-значение в памяти), тогда работать будет быстро (быстрее схемы с PostgreSQL). Но также сессии можно хранить и в PostgreSQL.

сайт на город с населением 40 тысяч

У нас было голосование на сайте за главу соседнего района. Население 15 тысяч, в голосовании у каждого из трёх кандидатов были пятизначные цифры уже после 45 минут. Так что кол-во населения не показатель.

Ботов отслеживать надо по логам. Например, они тупо дёргают одну страницу, в отличие от браузера, который тянет всё: картинки, CSS-файлы и прочую мешуру. Чем дороже бот, тем он максимально имитирует «человека с браузером», но практика показывает, что в основном верх совершенства это перебор проксей и смена юзерагента.

Поэтому нужно сначала проанализировать поведение на ресурсе, а потом в зависимости от этого строить преграды. Либо поменять условие «всё анонимно и посетитель размещает только три сообщения в день».

Не, ботов нет. Есть 20 тёток, которые по 3 раза в день дублируют свои 2 объявления. Бездельники, им не сложно. Плюс я думаю, что заказывать бота им будет дороже, чем заплатить мне за расширенный аккаунт (ололо, 200 рублей).

А чистить куки им бесплатно и они это уже наверняка умеют. Но тебе виднее, конечно.

Тогда без всякой БД. Проверяешь наличие куки, если её нет, создаёшь и пишешь в куку счётчик постов. Если она есть, проверяешь счётчик на допустимость постинга, если всё ОК, разрешаешь размещение на сайте и после него увеличиваешь счётчик в куке.

Это всё будет работать пока кто-нибудь из них не сообразит использовать несколько браузеров, или вообще тереть куки (например дети, племянники, внуки подскажут).

А что насчёт создания связок «ip + ua + разрешение экрана»?

Тогда можно при отсутствии кук сверяться с БД насчёт этого компютера, ip, браузера и т.д. Нужен способ за всеми следить :)

Типа того.

Кажется, ETag может быть постоянным.

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

Нужен способ за всеми следить :)

Делай авторизацию через соцсети же:)

Коррективы:

1) Вместо ID человека можно попробовать связку IP-адрес/юзерагент/сессия. Если два из трёх совпадают - это наш клиент. 2) использовать дополнительную key=>value базу данных, хоть memcache/redis/хрен-его-кеш, в который будет записываться значение IP-адрес/юзерагент/сессия, в виде ключа. В значение писать массив со всем что тебе нужно. 3) если происходит ключевое событие - +1 пост - обновлять это в базе данных. 4) создавать первую запись в большой базе только с первого поста.

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

Обычно, в таких случаях уже об нагрузке не думаешь.

Сделал с ETag. Пришлось написать отдельный сервер, отдающий правильный etag для каждого клиента и сообщающий об этом основному %)

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

Манул читаю, н там 2814 страниц, а я тлько на трёхсотых.

Непонятно, зачем предлагают способы, которые можно легко обойти. Агенты же сами себя как-то идентифицируют? Оставляют телефон, сайт, название компании, адрес? Можно же по этим данным как-то учитывать?

Потереть куки в браузере или воспользоваться прокси проще чем сменить телефон или морочиться с обфускацией

Дружище, пойми, потребность прыгать выше головы жжёт зад.

Просто пиши в куку 3 числа - таймстемпы последних 3-х объявлений и проверяй, что текущая дата больше, чем первая из этих 3-х на сутки. Никакой БД не надо. Проверку можно в жаваскрипте на клиенте делать.

Будут чистить куки. Строго говоря, задача дошла до такого: Передать данные в HTTP-заголовках с 302 Moved Temporarily.