Попытаюсь обьяснить суть задачи.
Около 150-200кк запросов к серверу в сутки
Это около 1700-2300 запросов в секунду.
Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?

сори, возможно немного не точно обьяснил.
На вебсервер приходит запрос. Мне надо проверить был ли уже запрос с таким ИП в течении суток и сколько раз.
Плотность запросов - 1700-2300 в секунду.

SERG1257Задача не для СУБД. Копайте в сторону ферм.
Если не сложно - что это такое ?

Всем отписавшимся спасибо.

SERG1257Stinger03Если не сложно - что это такое ? http://en.wikipedia.org/wiki/Server_farm
это само-собой и так сейчас работает, ибо на каждый полученный запрос формируется 3-4 от нас, обрабатывается с них инфа и выдается наружу. Но вот с некоторыми вопросами статистики выходят затыки. поэтому решил у олла проконсультироватся. коллективный разум оно сподручнее :)

miksoftStinger03Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?Сколько раз вообще или сколько раз за последние 24 часа? С какой точностью это нужно делать? Как часто это "определить" должно происходить? Как долго/быстро оно должно происходить?
Сколько раз за последние 24 часа. если ИП за 24 часа не сделал ни одного запроса данных он считается уникальным. "Определить" должно происходить при каждом запросе данных. Т.е. если есть запрос данных есть надо определить - он уникальный или нет и сколько раз он уже был и от этого планируются дальнейшие действия с ним. Происходить должно очень быстро - время ответа сервера доли секунды ибо он должен дождатся ответов от других серверов и отдать данные обработки максимум за 2-3 секунды. лучше 1-1,5.

SERG1257Вы не ответили за точность - произойдет ли большая беда если там будет плюс минус одна секунда в 24 часов.
Нет, беды никакой не будет.
SERG1257Что будет если один (только один запрос, и очень редко будет забыт)
Тоже не смертельно.
SERG1257Нужна ли высокая доступность, что будет если ваша система уйдет в даун (потому как все это очень сильно пахнет кластерами)
Вряд ли уйдет - сервера стоят в разных странах, не то что в разных ДЦ. Выход 1 сервера не ложит систему - нагрузка распределяется между живыми. Запас пока есть.

SERG1257Что будет если во время форс-мажора (все ноды были обесточены) ляжет весь кластер. (тут вопрос надо ли делать бакап свежевставленных записей на диск или можно просто поднять лишную ноду)
выше ответил.

SERG1257Если ошибки в принципе приемлимы (неприятно, но не смертельно) то дорога вам в NoSQL базы, кластеры, распределители нагрузки и бежнодовое взаимодействие.
Ошибки (небольшие) приемлемы. Система по сути работает и без этого, но это очень не оптимальный вариант работы.

DPH3SERG1257Вряд ли уйдет - сервера стоят в разных странах, не то что в разных ДЦ. Выход 1 сервера не кладет систему - нагрузка распределяется между живыми. Запас пока есть.

Т.е. для сервиса "контроля IP" тоже нужно обеспечивать синхронизацию между ДЦ хотя бы на уровне logshipping?

что то будем изобретать наверное... отельно пасиб за то что сразу обратили на это внимание.


DPH3А сколько вообще, в среднем, IP в сутки? А сколько в пике? И какая нагрузка в пике?
Основная сложность - синхронизация между ДЦ и автоматическое управление при падении.
Какая сейчас РСУБД используется в системе?
В среднем около 150кк в среднем и до 360кк в пиках в сутки. в сукунду до 10к в пиках, но это редко. среднее что то около 2-3к в секунду.
Вобщем то запросы идут относительно ровно.
При этих расчетах не используется никакая. Пока для всего что нужно хватает текстовых файлов для расчетов - они небольшие и в основном все считается в памяти со сбросом изредка на диск. Но этой информации очень нехватает, надо проводить более сложные статистические расчеты по этому трафику.