Вообще все это велосипед имхо.
Есть известный формат базы у maxmind, придумать что-то более правильное малореально. К этому формату есть готовые библиотеки для работы и множество различных скриптов заточены уже под нее.
Так что задачка сводится к конвертированию базы из текста в бинарный формата maxmind. Причем хоть на си под виндой, хоть на перле под чем угодно ибо операция редкая. И дело в шляпе.
PS: вообще даже странно что руцентр не делает базу в том же формате😕 .
kostich,
Речь несколько не об этом. Флуд тоже разный бывает. Один из вариантов - нужна защита от избыточной нагрузки. Простой пример – на хосте несколько тысяч простых сайтов и на них иногда наваливаются боты спамеры, боты ищущие уязвимости и т.д. Т.е. это не ДОС, а паразитная нагрузка, которую гораздо удобнее решать средствами ядра. Тот же самый RSS... у клиентов чтонт заклинит - и они тоже могут много лишей загрузки сделать. Банить их не нужно, а надо тайм-ауты увеличивать.
Отсюда и возникают вопросы – как работает система. Поскольку надо и паразитный трафик отсекать и в тоже время клиентские службы не резать, которые могут тоже много нагрузки создавать. Т.е. нужна гибкость в настройках фильтров, тайм-аутов и прочего.
Когда тебя «тупо» досят – с этим все ясно. Но бывают разные ситуации.
Вот такого рода моменты и хочется понять. Фильтрация на аплинках в данном случае мало волнует. Теоретически нужно нечто вроде apach_bandwith но на порядок шустрее и корректнее работающее, с возможностью банов (в т.ч. и временных) и с большой гибкостью настройки.
Грубо говоря описание может быть такого рода: трафик завернут на сервис, который по набору правил (а насколько они гибкие и какие могут быть фильтры?) с использованием БД (какой? В оперативке, в файловой Бд с кешем в оперативке?) либо пропускает пакеты (опять же на каком уровне идет срезка… пакеты, коннекты?) либо выдает такие-то коды ошибок (мы же о http говорим…) либо делает задержки на ответы…
Никаких великих секретов такое описание не откроет, но даст понимание – о чем идет речь. Также не помешают циферки – сколько чисто софтовый сервис скушает ресурсов и сколько при этом сможет удержать паразитов (речь не о гигабитах, а о коннектах, размере стека адресов и т.д.)
Ну и для данного вида защиты управление правилами желательно на стороне клиента, соответственно абон. плата нежелательна.
Нам по идее интересен подобный продукт, но уж не кот в мешке. Логику надо понимать.
А так... купи то - не знаю что... кхе. Ктож так товар продает.
Как настраивается - что считать атакой..?
Т.е. например кто-то телепорт натравили на большой сайт, много запросов с одного адреса - это атака?
А если с кучи разных адресов идут запросы GET (не HEAD) это атака?
А если сайт - донор RSS и другого контента для кучи реципиентов... это атака?
Покажите настройки системы, поясните логику/архитектуру. У вас нечто вроде ipfw только с оперативной БД или что?
И, кстати, полезно смотреть explain - иногда там можно много интересного увидеть и про использование индексов в том числе.
Каждый индекс должен создаваться только если он реально используется, поскольку:
-каждый индекс элементарно занимает место на диске;
-каждый индекс существенно замедляет операции модификации данных, ибо каждая из них, которая его затрагивает - будет требовать перестройки индекса. По этой же причине рекомендуется при групповой обработке данных отклбючать индексы и затем их создавать. При больших объемах это ускоряет обновление на порядки.
Также можно использовать insert delayed, low priority и т.д. Но нужно понимать как сие работает - это хорошо в документации описано.
Таким образом, если в той же статистике есть временная таблица, в которую идут одни вставки, а чтение идет просто вподряд с удалением обработанного - то индекс и не нужен (но нужно периодически запускать optimize table 🚬 ).
Shtogrin, Про индексы понятно, а много или мало 30% - это можно решать в частном порядке (но три джойна - это уже вдвое медленнее и может оказаться критичным моментом), как и остальные вещи касаемо архитектуры. Вариантов много.
Будет!
В mySQL каждый join увеличивает время выполнения запроса примерно на 30%.
Проверено неоднократными тестами.
Оптимальная структура скорее зависит от частоты обновлений\добавлений данных. Разумное дублирование значительно ускоряет чтение, но изменения будут сложнее и тяжелее.
Ну работа в веб-панели по https - это муторно, думаю достаточно авторизацию делать по https, а далее уже по обычному каналу. Формально можно и тут напакостить, но вероятность этого уже чисто гипотетическая :)
Есть бооольшое подозрение что никакие способы хранения паролей вообще не помогут. Поскольку пароль можно перехватывать в момент передачи его по сети, это универсально и независимо от способа хранения.
Видимо единственная панацея в этом случае - криптованный доступ SFTP и т.п.
