ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Нужна консультация по очень большой нагрузке
74 сообщений из 74, показаны все 3 страниц
  все  
Нужна консультация по очень большой нагрузке
    #37712706
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
Попытаюсь обьяснить суть задачи.
Около 150-200кк запросов к серверу в сутки
Это около 1700-2300 запросов в секунду.
Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?
...
Рейтинг: 0 / 0
20.03.2012, 02:59
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37712773
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Задача не для СУБД. Копайте в сторону ферм.
...
Рейтинг: 0 / 0
20.03.2012, 08:37
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37712781
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
авторЭто около 1700-2300 запросов в секунду.

Код: sql
1.
SELECT 1



тоже запрос.
...
Рейтинг: 0 / 0
20.03.2012, 08:54
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37712791
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
SERG1257Задача не для СУБД.

Да ну?!
...
Рейтинг: 0 / 0
20.03.2012, 09:07
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37712888
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?Сколько раз вообще или сколько раз за последние 24 часа? С какой точностью это нужно делать? Как часто это "определить" должно происходить? Как долго/быстро оно должно происходить?
...
Рейтинг: 0 / 0
20.03.2012, 10:21
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37713058
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
Stinger03Попытаюсь обьяснить суть задачи.
Около 150-200кк запросов к серверу в сутки
Это около 1700-2300 запросов в секунду.
Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?

По сути задача сводится к работе с таблицей из двух полей, одно из которых уникальный ключ из целочисленного представления IP-адреса (IPv4 - 4 байта, IPv6 - максимум 16 байт), а вторая - время последнего обращения... Чтобы прикрутить "сколько раз" - ну, добавь еще одно поле с накоплением количества обращений.
В итоге - с этой задачей вполне справится ЛЮБОЙ SQL сервер. Выбирать, естественно, лучше из тех, которые "лучше знаешь"...
...
Рейтинг: 0 / 0
20.03.2012, 11:37
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37713290
AlexKB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexKB
Участник
Stinger03Попытаюсь обьяснить суть задачи.
Около 150-200кк запросов к серверу в сутки
Это около 1700-2300 запросов в секунду.
Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?

Добрый день.
Довольно-таки примитивная задача для СУБД CACHE.
Даже если все это будет установлено на обычный ПК совресенной косплектации
Нагрузка на процессор будет 1-3%.
Проверено опытом.
...
Рейтинг: 0 / 0
20.03.2012, 12:57
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37713925
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Кто бы спорил что запросы на статических данных будут делатся быстро. А как ТС собирается базу обновлять?
...
Рейтинг: 0 / 0
20.03.2012, 16:58
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714042
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
SERG1257Кто бы спорил что запросы на статических данных будут делатся быстро. А как ТС собирается базу обновлять?

Вы полагаете, что 2300 модифицирующих запросов для СУБД - это нереальные цифры? Автору надо быстро вставлять...
...
Рейтинг: 0 / 0
20.03.2012, 17:33
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714200
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
сори, возможно немного не точно обьяснил.
На вебсервер приходит запрос. Мне надо проверить был ли уже запрос с таким ИП в течении суток и сколько раз.
Плотность запросов - 1700-2300 в секунду.

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

Всем отписавшимся спасибо.
...
Рейтинг: 0 / 0
20.03.2012, 18:44
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714233
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Stinger03На вебсервер приходит запрос. Мне надо проверить был ли уже запрос с таким ИП в течении
суток и сколько раз.
Плотность запросов - 1700-2300 в секунду.

И как тебе уже сказали: СУБД тут ни к чему. То, что тебе нужно, это простейшее in-memory
key-value хранилище.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.03.2012, 18:55
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714287
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Dimitry SibiryakovИ как тебе уже сказали: СУБД тут ни к чему. То, что тебе нужно, это простейшее in-memory key-value хранилище.Можно подумать, что "in-memory key-value хранилище" - это не СУБД :)
...
Рейтинг: 0 / 0
20.03.2012, 19:14
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714610
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
pkarklin Вы полагаете, что 2300 модифицирующих запросов для СУБД - это нереальные цифры? Автору надо быстро вставлять...Одиночными инсертами с коммитом? Нет я верю, что вы можете этого добится, я сомневаюсь что РСУБД для этого предназначена.

miksoft Можно подумать, что "in-memory key-value хранилище" - это не СУБД :) Не РСУБД. Плюс, забив на ACID, ее можно легко кластеризовать (раскидать по нодам)
...
Рейтинг: 0 / 0
20.03.2012, 22:40
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714623
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Stinger03 Если не сложно - что это такое ? http://en.wikipedia.org/wiki/Server_farm
...
Рейтинг: 0 / 0
20.03.2012, 22:46
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714763
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
SERG1257Stinger03Если не сложно - что это такое ? http://en.wikipedia.org/wiki/Server_farm
это само-собой и так сейчас работает, ибо на каждый полученный запрос формируется 3-4 от нас, обрабатывается с них инфа и выдается наружу. Но вот с некоторыми вопросами статистики выходят затыки. поэтому решил у олла проконсультироватся. коллективный разум оно сподручнее :)
...
Рейтинг: 0 / 0
21.03.2012, 01:12
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37714808
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
ответьте на вопросы miksoft
...
Рейтинг: 0 / 0
21.03.2012, 03:25
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37715118
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
miksoftStinger03Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще ?Сколько раз вообще или сколько раз за последние 24 часа? С какой точностью это нужно делать? Как часто это "определить" должно происходить? Как долго/быстро оно должно происходить?
Сколько раз за последние 24 часа. если ИП за 24 часа не сделал ни одного запроса данных он считается уникальным. "Определить" должно происходить при каждом запросе данных. Т.е. если есть запрос данных есть надо определить - он уникальный или нет и сколько раз он уже был и от этого планируются дальнейшие действия с ним. Происходить должно очень быстро - время ответа сервера доли секунды ибо он должен дождатся ответов от других серверов и отдать данные обработки максимум за 2-3 секунды. лучше 1-1,5.
...
Рейтинг: 0 / 0
21.03.2012, 10:54
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37715744
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
miksoftМожно подумать, что "in-memory key-value хранилище" - это не СУБД :)

Массив в памяти это БД? А код, который с ним работает это СУБД? Тогда std::map это точно СУБД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.03.2012, 14:04
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37716122
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
2Stinger03
То есть по сути у вас есть
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
-- табличка
create table query (ip bigint, query_time datetime)
--запрос 
select count(*) from query where ip=:ip and :query_time-1<query_time
--после запроса 
insert into query values (:ip,:query_time)
commit
--когда нибудь по ходу работы очистка таблицы
delete from query where query_time<system_date-1


Вы не ответили за точность - произойдет ли большая беда если там будет плюс минус одна секунда в 24 часов.
Что будет если один (только один запрос, и очень редко будет забыт)
Нужна ли высокая доступность, что будет если ваша система уйдет в даун (потому как все это очень сильно пахнет кластерами)
Что будет если во время форс-мажора (все ноды были обесточены) ляжет весь кластер. (тут вопрос надо ли делать бакап свежевставленных записей на диск или можно просто поднять лишную ноду)
Если ошибки в принципе приемлимы (неприятно, но не смертельно) то дорога вам в NoSQL базы, кластеры, распределители нагрузки и бежнодовое взаимодействие.
...
Рейтинг: 0 / 0
21.03.2012, 16:34
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37716294
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
SERG1257Вы не ответили за точность - произойдет ли большая беда если там будет плюс минус одна секунда в 24 часов.
Нет, беды никакой не будет.
SERG1257Что будет если один (только один запрос, и очень редко будет забыт)
Тоже не смертельно.
SERG1257Нужна ли высокая доступность, что будет если ваша система уйдет в даун (потому как все это очень сильно пахнет кластерами)
Вряд ли уйдет - сервера стоят в разных странах, не то что в разных ДЦ. Выход 1 сервера не ложит систему - нагрузка распределяется между живыми. Запас пока есть.

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

SERG1257Если ошибки в принципе приемлимы (неприятно, но не смертельно) то дорога вам в NoSQL базы, кластеры, распределители нагрузки и бежнодовое взаимодействие.
Ошибки (небольшие) приемлемы. Система по сути работает и без этого, но это очень не оптимальный вариант работы.
...
Рейтинг: 0 / 0
21.03.2012, 17:30
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37717069
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
SERG1257Вряд ли уйдет - сервера стоят в разных странах, не то что в разных ДЦ. Выход 1 сервера не кладет систему - нагрузка распределяется между живыми. Запас пока есть.

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

А сколько вообще, в среднем, IP в сутки? А сколько в пике? И какая нагрузка в пике?
А то есть у меня подозрение, что при таком сценарии работы любая СУБД будет, де-факто, in-memory и справится с легкостью. Нужно только каким-то образом (специфичном для БД) указать, что локи при update делать не нужно (или, по крайней мере, не нужно их писать на диск). Ну, еще можно включать write cache на дисках (потери при падении, как уже говорилось, не существенны).
Основная сложность - синхронизация между ДЦ и автоматическое управление при падении.
Какая сейчас РСУБД используется в системе?
...
Рейтинг: 0 / 0
22.03.2012, 03:36
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37717856
Берешь любую СУБД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Берешь любую СУБД
Гость
Берешь любую СУБД. Создаешь таблицы: Unlogged Tables. Отключаешь у СУБД синхронные commit и flush на диск. Выставляешь в СУБД побольше размеры буфера. Включаешь на диске cache на запись и отключаешь flush.
И используешь параметризованные запросы и пулы конектов в php.

Ну и используй особенности каждой СУБД. Если допустим используешь PostgreSQL, то используй хэш-индекс.
...
Рейтинг: 0 / 0
22.03.2012, 13:59
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721286
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
DPH3SERG1257Вряд ли уйдет - сервера стоят в разных странах, не то что в разных ДЦ. Выход 1 сервера не кладет систему - нагрузка распределяется между живыми. Запас пока есть.

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

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


DPH3А сколько вообще, в среднем, IP в сутки? А сколько в пике? И какая нагрузка в пике?
Основная сложность - синхронизация между ДЦ и автоматическое управление при падении.
Какая сейчас РСУБД используется в системе?
В среднем около 150кк в среднем и до 360кк в пиках в сутки. в сукунду до 10к в пиках, но это редко. среднее что то около 2-3к в секунду.
Вобщем то запросы идут относительно ровно.
При этих расчетах не используется никакая. Пока для всего что нужно хватает текстовых файлов для расчетов - они небольшие и в основном все считается в памяти со сбросом изредка на диск. Но этой информации очень нехватает, надо проводить более сложные статистические расчеты по этому трафику.
...
Рейтинг: 0 / 0
24.03.2012, 14:11
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721475
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Stinger03При этих расчетах не используется никакая. Пока для всего что нужно хватает текстовых файлов для расчетов - они небольшие и в основном все считается в памяти со сбросом изредка на диск. Но этой информации очень нехватает, надо проводить более сложные статистические расчеты по этому трафику.А расчёты нужны сразу? А то может просто импортитовать раз в сутки данные и уже потом считать аналитику.
...
Рейтинг: 0 / 0
24.03.2012, 19:10
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721541
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
В среднем около 150кк в среднем и до 360кк в пиках в сутки. в сукунду до 10к в пиках, но это редко. среднее что то около 2-3к в секунду.

Я плохо выразился. А сколько разных IP в сутки и сколько, например, в секунду в пике.
Именно "разных" (по которым аггрегацию и нужно проводить).
...
Рейтинг: 0 / 0
24.03.2012, 21:39
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721592
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
авторЯ плохо выразился. А сколько разных IP в сутки и сколько, например, в секунду в пике.
Именно "разных" (по которым аггрегацию и нужно проводить).
И инфа нужна именно оперативная? С точностью до последнего запроса последней секунды?
...
Рейтинг: 0 / 0
24.03.2012, 22:46
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721667
Берешь любую СУБД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Берешь любую СУБД
Гость
Сколько разговоров о элементарной задаче :)
...
Рейтинг: 0 / 0
25.03.2012, 01:31
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721685
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
DPH3В среднем около 150кк в среднем и до 360кк в пиках в сутки. в сукунду до 10к в пиках, но это редко. среднее что то около 2-3к в секунду.

Я плохо выразился. А сколько разных IP в сутки и сколько, например, в секунду в пике.
Именно "разных" (по которым аггрегацию и нужно проводить).
Они все разные. повторения достаточно редки. редко когда будет больше 10 повторений в сутки. поэтому в таблице будет около 150-300кк записей
...
Рейтинг: 0 / 0
25.03.2012, 03:28
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721686
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
SERG1257авторЯ плохо выразился. А сколько разных IP в сутки и сколько, например, в секунду в пике.
Именно "разных" (по которым аггрегацию и нужно проводить).
И инфа нужна именно оперативная? С точностью до последнего запроса последней секунды?
инфа нужна крайне оперативно. от нее зависит по какому алгоритму обрабатывать запрос. ответ должен быть в доли секунды - был ли такой ип и сколько раз
...
Рейтинг: 0 / 0
25.03.2012, 03:31
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721837
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
Stinger03SERG1257пропущено...

И инфа нужна именно оперативная? С точностью до последнего запроса последней секунды?
инфа нужна крайне оперативно. от нее зависит по какому алгоритму обрабатывать запрос. ответ должен быть в доли секунды - был ли такой ип и сколько раз
Если смысл анализа статистики количества запросов с какого-то отдельно взятого IP-адреса за определенный период времени еще как-то просматривается (сам сталкивался), то изменение алгоритма обработки запроса в зависимости от количества ранее сделанных запросов (ака, номера текущего запроса с конкретного IP-адреса) для СУБД - как-то не очень...
...
Рейтинг: 0 / 0
25.03.2012, 13:13
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37721843
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Stinger03Они все разные. повторения достаточно редки. редко когда будет больше 10 повторений в
сутки. поэтому в таблице будет около 150-300кк записей

Обращения с двухсот миллионов уникальных IP-адресов в сутки... Гугль? Скайп? Аська?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.03.2012, 13:17
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37722271
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
Dimitry Sibiryakov,

Нет, реклама и трафик.
Просто я правда говорю, что задача достаточно нетривиальная и нагрузка идет высокая.
Иногда упираемся даже в физические ограничения протоколов и железа.
...
Рейтинг: 0 / 0
25.03.2012, 22:03
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37722318
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Stinger03Нет, реклама и трафик.
Просто я правда говорю, что задача достаточно нетривиальная и нагрузка идет высокая.

300 миллионов адресов IPv4 это массив размером в гигабайт. Всё пространство адресов у IPv4
- четыре гигабайта. Оно целиком влезает в память. Что нетривиального в том, чтобы
построить в памяти дерево и повесить ему на листья счётчики? Или даже простейший массив.
16 гигабайт ОЗУ хватит чтобы посчитать по четыре миллиарда подключений в сутки с каждого
из возможных и невозможных адресов. А у тебя, как ты говоришь, количество повторных
подключений не превышает десятка.

В какие ограничения вы там упираетесь?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.03.2012, 22:46
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37782940
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
Стебелек бери.
Вставляет 20 млн в секунду
на Икор7. В 20 раз быстрее
чем стд::мап
...
Рейтинг: 0 / 0
04.05.2012, 23:15
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37782943
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
сегодня был тест
80 миллионов вставок за 4 секунды.
...
Рейтинг: 0 / 0
04.05.2012, 23:16
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37782979
ДохтаР
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ДохтаР
Участник
sphinx_mvStinger03пропущено...

инфа нужна крайне оперативно. от нее зависит по какому алгоритму обрабатывать запрос. ответ должен быть в доли секунды - был ли такой ип и сколько раз
Если смысл анализа статистики количества запросов с какого-то отдельно взятого IP-адреса за определенный период времени еще как-то просматривается (сам сталкивался), то изменение алгоритма обработки запроса в зависимости от количества ранее сделанных запросов (ака, номера текущего запроса с конкретного IP-адреса) для СУБД - как-то не очень...

Нормальная и правильная постановка задачи для автоматического контроля ДДОС .
Отсуюда и разный алгоритм , что бы ненапрягаясь отдавать дедосящим факоФФ или редирект наюх
ничего другого не делая.

Stinger03, угадал ?
...
Рейтинг: 0 / 0
05.05.2012, 00:21
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37783299
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
ДохтаРsphinx_mvпропущено...

Нормальная и правильная постановка задачи для автоматического контроля ДДОС .
Отсуюда и разный алгоритм , что бы ненапрягаясь отдавать дедосящим факоФФ или редирект наюх
ничего другого не делая.

Ни к нормальной, ни, тем более, к правильной постановке задачи ЭТО никакого отношения не имеет.
По простой причине - решение задачи защиты сетевых ресурсов к задачам СУБД не относится...
...
Рейтинг: 0 / 0
05.05.2012, 11:15
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37786829
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
Redis - самое то
...
Рейтинг: 0 / 0
09.05.2012, 14:13
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37786964
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
вот думаю: может банить тех кто пишет "ХХХ - самое то" ? если человек ничего умного больше не в состоянии написать - стоит ли ему писать?
...
Рейтинг: 0 / 0
09.05.2012, 18:02
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787682
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
Stinger03Попытаюсь обьяснить суть задачи.
Около 150-200кк запросов к серверу в сутки
Это около 1700-2300 запросов в секунду.
Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз.
Хранить данные более 24 часов ненужно.
Что потянет подобную задачу и потянет ли вообще?

авторвот думаю: может банить тех кто пишет "ХХХ - самое то" ? если человек ничего умного больше не в состоянии написать - стоит ли ему писать?


Уважаемый модератор, по-моему я точно и полно ответил на вопрос топикстартера. Разбираю по частям:
авторЧто потянет подобную задачу
Redis

автори потянет ли вообще

- самое то.

Или нужно мануал сюда вставить? Краткость - сестра таланта!
...
Рейтинг: 0 / 0
10.05.2012, 12:58
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787687
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
Такую задачу потянет обычная хештаблица.
Зачем Редис то ?
...
Рейтинг: 0 / 0
10.05.2012, 13:02
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787714
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
BazistТакую задачу потянет обычная хештаблица.
Зачем Редис то ?

Вы собираетесь одним вебсервером обойтись? По-моему, там без фермы никак, так что будете делать хештаблицу в отдельном процессе и соответственно заново откроете Редис :)
...
Рейтинг: 0 / 0
10.05.2012, 13:08
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787855
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
neoddd,

Гдеже вы такие беретесь. Какая ферма, что за бред.
Обычная хештаблица тянет 5-10 млн вставок / секунда.
Какой нибудь 286й или 386й, 90х годов завалявшийя на чердаке потянет с головой 2 тысчи вставок в секунду.
Можно взять Стебельковые алгоритмы, те 80 млн айпи адресов вставляют/апдейтят/ищут за 4,5 секунды на Икор7
в инмемори режиме. Но ТСу такая мощность просто не нужна ...
...
Рейтинг: 0 / 0
10.05.2012, 14:16
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787874
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
BazistГдеже вы такие беретесь. Какая ферма, что за бред.

Вежливо отвечаю: ферма для обработки веб-запросов. То есть несколько веб-серверов должны иметь доступ к общей хеш-таблице, которая, получается, должна находиться в отдельном процессе. К тому же это обеспечит сохранность данных на случай падения какого-то вебсервера в ферме. Основы основ, а вы все своими алгоритмами хвалитесь.
...
Рейтинг: 0 / 0
10.05.2012, 14:24
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787877
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
neoddd,

С чего вы взяли что у ТСа несколько вебсерверов и все не крутится на одной тачке ?
...
Рейтинг: 0 / 0
10.05.2012, 14:27
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787882
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
Stinger03Около 150-200кк запросов к серверу в сутки


Вижу единственое число.
Видимо один сервер, одна хештаблица, зачем ферма я так и не понял.
...
Рейтинг: 0 / 0
10.05.2012, 14:28
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787896
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
Bazist
Вижу единственое число.
Видимо один сервер, одна хештаблица, зачем ферма я так и не понял.

Это просто надо знать, что при такой нагруженности всегда несколько серверов в ферме стоит, даже если один справляется, есть fail-over.
...
Рейтинг: 0 / 0
10.05.2012, 14:34
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787910
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
neoddd,

2000 запросов это вообще порожняковая нагрузка.
На этот форум думаю поболее приходит в пик и не думаю что прямо у Джуджа ферма серверов стоит.
При нормальном посоле обычный веб сервер может до полумиллиона запросов держать.
Но конечно если там не такие "разработчики" которые вместо каждой хештаблицы в коде редис лепят
...
Рейтинг: 0 / 0
10.05.2012, 14:42
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787916
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
Stinger03SERG1257пропущено...
http://en.wikipedia.org/wiki/Server_farm
это само-собой и так сейчас работает, ибо на каждый полученный запрос формируется 3-4 от нас, обрабатывается с них инфа и выдается наружу. Но вот с некоторыми вопросами статистики выходят затыки. поэтому решил у олла проконсультироватся. коллективный разум оно сподручнее :)

Bazist, обьясните, вы предлагаете компании терять деньги и клиентов, если единственный сервер упадет или ваши сервера никогда не падают и в датацентрах электричество не пропадает?
...
Рейтинг: 0 / 0
10.05.2012, 14:45
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787936
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
neodddBazist, обьясните, вы предлагаете компании терять деньги и клиентов, если единственный сервер упадет или ваши сервера никогда не падают и в датацентрах электричество не пропадает?

Я не понимаю, вам что ТС подошел и начал плакатся в жилетку что у него падают сервера ?
У ТСа элементарная как 5 копеек задача. Откуда взялись фермы, откуда взялось решение тысячи непонятных проблем.
Все сервера падают конечно, и этот сайт раз другой лежит в дауне в месяц и ничего, живет както развивается.
...
Рейтинг: 0 / 0
10.05.2012, 14:51
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787942
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
BazistneodddBazist, обьясните, вы предлагаете компании терять деньги и клиентов, если единственный сервер упадет или ваши сервера никогда не падают и в датацентрах электричество не пропадает?

Я не понимаю, вам что ТС подошел и начал плакатся в жилетку что у него падают сервера ?
У ТСа элементарная как 5 копеек задача. Откуда взялись фермы, откуда взялось решение тысячи непонятных проблем.
Все сервера падают конечно, и этот сайт раз другой лежит в дауне в месяц и ничего, живет както развивается.

Bazist, я вам процитировал про ферму у ТС-ра. Как по-вашему, есть разница между sql.ru и компанией с обязательствами перед клиентами?
...
Рейтинг: 0 / 0
10.05.2012, 14:55
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37787950
Bazist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bazist
Участник
Ну тогда пардон,. Если на одном сервере потребность в этих данных то хештаблица,
если нужно шарить эту таблицу между несколькими серверами, то наверное редис или чтото в этом роде.
...
Рейтинг: 0 / 0
10.05.2012, 14:59
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37795811
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
Хм, а зачем какой-то редис для такой простой задачи?
Если нам нужна ненадежность редиса при его производительности - то можно просто включить кэширование на жестком диске или отключить логгирование при записи в эту таблицу (или воспользоваться еще кучей вариантов разменять производительность на надежность, имеющиеся в любой БД).
Вместо сложной фермы - просто поставить 2 (n) серверов и дублировать записывающий поток на все из них (впрочем, для БД есть и стандартные драйвера). Это вполне себе системными средствами можно сделать.

А так как сама табличка влезает в память, блокировки не нужны - то любая БД вполне себе справится :)
...
Рейтинг: 0 / 0
15.05.2012, 18:14
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37795883
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
DPH3...
А так как сама табличка влезает в память, блокировки не нужны - то любая БД вполне себе справится :)

Тут выбор прост: память (раз влазит)
А если память, зачем гнать через горлышко БД?
С Редисом сразу получаем гибкую систему, с примерно на порядок большей производительностью.
При этом меньше вероятность рассыпания диска, что тоже полезно для системы в целом.
...
Рейтинг: 0 / 0
15.05.2012, 18:55
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37796126
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
neoddd,

Ну, с точки зрения эксплуатации, лучше уж БД, для которой можно всегда найти специалиста, нежели фигня, которую придется поддерживать исключительно самостоятельно и набивать шишки тоже самостоятельно. Тем более что СУБД обычно уже есть :)

На порядок большая производительность - это вряд ли, с чего-бы. тут производительность зависит от скорости диска на потоковую запись, так что какая разница. Разве что СУБД обычно с диском поэффективнее работают.

А вот про рассыпание диска - тут поподробнее, почему это для Редиса вероятность будет меньше?
...
Рейтинг: 0 / 0
15.05.2012, 23:13
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37796775
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
DPH3, я считаю, что достаточно озвучил свои доводы. Реального желания спорить у меня нет.
...
Рейтинг: 0 / 0
16.05.2012, 12:17
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37799715
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
[quote ДохтаР]sphinx_mvпропущено...

Нормальная и правильная постановка задачи для автоматического контроля ДДОС .
Отсуюда и разный алгоритм , что бы ненапрягаясь отдавать дедосящим факоФФ или редирект наюх
ничего другого не делая.

Stinger03, угадал ?
Нет, совсем не угадал. К ддосу мы не имем никакого отношения, но сами испытывали что это такое. Так что тех кто занимается - очень-очень сильно не любим.

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

Сейчас перевалило за 200кк входящих запросов в сутки (соответственно это около 500-600кк исходящих получается).

По поводу redis - сайчас нам мемкешед лучше подходит так как получается быстрее.

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

Так что кто обсуждает - всем спасибо большое. Помогаете смотреть на задачу со стороны и смотреть те варианты над которыми не задумывались или не знали.
...
Рейтинг: 0 / 0
17.05.2012, 18:30
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37799730
neoddd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
neoddd
Участник
Stinger03...
Сейчас перевалило за 200кк входящих запросов в сутки (соответственно это около 500-600кк исходящих получается).
...


Еще есть, куда расти. Например:

Stats:
The firehose is at 250 million tweets a day.
936 CPU Cores
Supports 16,000 Data Streams Per Server
Processes Whole Twitter Firehose 250+ million Tweets per day. As a comparison, Visa says in 2007 they processed 27.612 billion transactions, which this paper estimates is 2100 transactions per second during the busiest 8 hours of the day. Those are complete transactions however.
Current Peak Delivery of 120,000 Tweets Per Second (260Mbit bandwidth)
Performs 250+ million sentiment analysis with sub 100ms latency
...
Рейтинг: 0 / 0
17.05.2012, 18:43
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37854158
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
Stinger03Задача - определить было ли уже в течении 24 часов обращение с одного и того же ИП и желательно сколько раз
Товарищи, это полный пи#$ец, как говаривал один мой друган.
Эту процитированную задачу решает простой тупой прокси-сервер, который тупо и просто гадит в локальный файл, что любой студень напишет на любом перле\пхп на любой переменке между любыми лабами.
Определение было ли обращение - постфактум по этим файлам.
При чём в процитированной постановке СУБД вообще?
...
Рейтинг: 0 / 0
26.06.2012, 01:59
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895746
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
Не вникнув в суть задачи делать заявления о п#$це по меньшей мере не красиво.
Тупой прокси-сервер ляжет через 0,1 секунду после включения и утянет за собой всю структуру.
За вчера обработано 1 017 929 064 запросов. Это где то 12к входящих запросов в секунду. И обрабатывать их надо в рилтайме. Перл/пхп банально не имеют многопоточности и впадают в ступор тут же, точнее сказать мгновенно, как собственно и студенты которые просто не поймут что делать.
Собственно по сути вопрос не решился - точность определения повторов сейчас страдает, но пока в допустимых пределах.
...
Рейтинг: 0 / 0
27.07.2012, 16:29
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895807
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
Stinger03Тупой прокси-сервер ляжет через 0,1 секунду
Ну используйте не тупой, или тыщу штук запустите.
Должно быть принципиальное понимание, что если сейчас некая сущность в состоянии принимать запросы и в принципе работает, то заведомо более легковесная сущность с меньшим лагом - тем более будет работать.

Stinger03И обрабатывать их надо в рилтайме
Это ещё зачем вдруг понадобилось?
...
Рейтинг: 0 / 0
27.07.2012, 17:00
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895866
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
Повторю задачу для тех кто читает с конца топика.
Есть ферма. На нее приходит запрос на данные. В зависимости от уникальности ИП формируется ответ на этот запрос и отдается. Если этот ИП уже запрашивал данные, то ответ должен быть уже другим.
Т.е. мне надо не просто отсеять уники от неуников, но и учитывать уникальность при выдаче информации.
Причем отдать эту информацию надо тоже как можно быстрее, хотя бы по причине того, что в случае задержек все просто заткнется из-за количества запросов.

Ну если сильно упростить всю задачу и на пальцах:
Надо по каждому клиенту показать уникальный банер. Если он этот видел - надо показывать другой. Этот банер формируется при запросе на лету. Вся информация для построения банера берется с компьютеров вне фермы, поэтому надо еще учесть время на запрос информации извне, построение банера и отдачи на запрос.
...
Рейтинг: 0 / 0
27.07.2012, 17:29
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895888
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Ничего оперативнее уже предложенного - 12311559 , имхо, вряд ли что придумаешь.
...
Рейтинг: 0 / 0
27.07.2012, 17:40
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895899
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
в том что ферма состоит из нескольких десятков машин. а считать уникальность надо в пределах всей фермы.
выделить машину под такую базу в памяти и обращатся к ней ? так количество запросов не протиснется в интерфейс помоему
...
Рейтинг: 0 / 0
27.07.2012, 17:49
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895912
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03выделить машину под такую базу в памяти и обращатся к ней ? так количество запросов не протиснется в интерфейс помоему12к входящих запросов в секунду - протиснется. Потенциальная подстава будет, если в другой ДЦ обращаться придется.

А не протиснется - шардить. Благо, что задача легко шардится хоть на миллион серверов.
...
Рейтинг: 0 / 0
27.07.2012, 17:54
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895921
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03,

Кстати, если хранить не линейным массивом, а деревом, то время обработки несколько возрастет (вряд ли заметно по сравнению с сетевыми задержками), а расход памяти резко снизится.
Тогда, возможно, можно будет даже не выносить на отдельный сервер. Хотя, конечно, синхронизация от этого не упростится...
...
Рейтинг: 0 / 0
27.07.2012, 17:58
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895922
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03,

А есть ли четкая зависимость, что какие-то ip-адреса обычно обращаются в один ДЦ, другие - в другой, третьи - в третий?
...
Рейтинг: 0 / 0
27.07.2012, 18:00
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895970
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
miksoft12к входящих запросов в секунду - протиснется
Проблема в том, что в начале топега было 2k запросов в секунду.
В ноябре чел зашьётся на 100k записей в секунду, или придётся всё переделывать опять.

Stinger03Ну если сильно упростить всю задачу и на пальцах:
Надо по каждому клиенту показать уникальный банер
Гы 100500 раз. Любому очевидно, что гарантировать уникальность в этом деле - себе дороже. Достаточно с вероятностью близкой к 1 это делать.
...
Рейтинг: 0 / 0
27.07.2012, 18:43
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895981
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
нет. несколько машин стоят под распределение нагрузки и они раскидывают запросы в зависимости от нагрузки на рабочие сервера. поэтому одини тот же ИП может появится на разных машинах.
сейчас как раз решаем вопросы синхронизации данных используя мемкешед.
от разных датацентров кстати пришлось отказатся - все сейчас в одном.
...
Рейтинг: 0 / 0
27.07.2012, 18:47
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895983
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03,

Кстати, а почему вы не решаете задачу хранением этого флага/счетчика на клиенте? в куках, например.
...
Рейтинг: 0 / 0
27.07.2012, 18:48
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37895998
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
у клиентов нету куков :)
это не конечные пользователи
...
Рейтинг: 0 / 0
27.07.2012, 18:56
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37896007
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Stinger03у клиентов нету куков :)
это не конечные пользователидесятки или сотни миллионов клиентов, которым показывают рекламные баннеры - не конечные пользователи???
...
Рейтинг: 0 / 0
27.07.2012, 19:02
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37896363
Stinger03
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stinger03
Гость
Банеры это всеже слегка притянутый за уши пример, хотя суть отражает полностью.
Мы даем информацию, которая в конечном счете доходит до компьютеров пользователей, но мы никакого доступа к этим компьютерам не имеем.
...
Рейтинг: 0 / 0
28.07.2012, 13:58
| Ответить | Цитировать | Написать  
Нужна консультация по очень большой нагрузке
    #37929775
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
Stinger03нет. несколько машин стоят под распределение нагрузки и они раскидывают запросы в зависимости от нагрузки на рабочие сервера. поэтому одини тот же ИП может появится на разных машинах.
сейчас как раз решаем вопросы синхронизации данных используя мемкешед.

Это как?
Если, например, четные адреса обрабатываются одной подсистемой, а нечетные - другой, то один конкретный IP будет только в одной подсистеме.
...
Рейтинг: 0 / 0
24.08.2012, 18:11
| Ответить | Цитировать | Написать  
74 сообщений из 74, показаны все 3 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Нужна консультация по очень большой нагрузке
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552527]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 30ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 91ms
get tp. blocked users:
 2ms
others: 13ms
total:  177ms
созд. / загр.: 177ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]