Всем доброго дня,

FB2.5.9
есть таблица с 2мя проиндексированными полями (IP и Time).
В таблице регистрируются IP обращения к сервису и время этих обращений.
Если в единицу времени происходит слишком много обращений с определённого IP доступ с этого IP блокируется.
Возник вопрос:
Чтобы таблица не разрасталась разумно старые зарегестририванные IP/Записи использовать снова и перезаписывать их новыми данными (дабы не удалять итп). Как должен выглядеть такой запрос с точки зрения скорости выполнения. Т.е. найти устаревшую запись и если нашел перезаписать её а если не нашел то добавить новую запись. Можно ли это красиво реализовать одной коммандой?
UPDATE OR INSERT ... MATCHING .... тут вроде не прикрутить? или?

Если использовать поле типа Time 23:59:59.9999 и CURRENT_TIME дабы сохранение происходило с миллисекундами надо что то делать? Не будут ли миллисекунды отбрасываться при сохранении?

Спасибо.

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

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

Всем спасибо, в принципе понятно.

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

да, это первое что я сказал заказчику. Но он хочет дополнительную защиту.....

от DDoS атаки. Сервис используется не у всех кто имеет админа способного настроить файрвол.
От инъекций, переполнения и прочей фигни уже защитили. Осталась только DDoS атака.
Хотя, конечно, учитывая что для отпинывания надо всё равно сделать селект защита получается тоже частичная. Но селект быстрый потому можно закрыть на это глаза.

Обломись, эта таблица не поможет. DDoS атака вообще до базы обычно не доходит, а
работает на сетевом уровне. Даже если дойдёт, встроенная защита Firebird
сработает раньше, надёжнее и эффективнее, чем твоя.


а в чём выразится это срабатывание?

сервис имеет различные URL по которым возвращает данные в виде xml через https. Доступ осушествляется на основе токенов итп.
Защита будет реализована не в виде триггера а в виде прослойки стоящей между базой и поступающим запросом.
Функция проверки сначала проверяет не заблокирован ли этот IP и если да до какого времени и отпинывает назад код ошибки. Если не заблокирован тогда проверяет количество обращений в единицу времени с этого IP и если предел превышен производит блокировку. Далее, если IP не заблокирован сохраняет его в базе и время когда это произошло.
Понятно что это от настоящей DDoS не защитит но от бота конкурентов работающего с 3-10 IP вполне спасёт. Опять же, можно анализировать общий траффик (со всех IP) и в случае перегрузки временно отказывать в обслуживании (т.к. в нормальной обстановке количество запросов не превышает 100 в минуту. Основная задача защиты не столько предотвратить отказ в обслуживании сколько не допустить повыщенную нагрузку на SQL сервер.
Лучше уж так чем никак.
п.с. Только что имел разговор с их админом, говорит в Firewall у них никакой зашиты от DDoS нет, и скорее всего не будет.