LINUX.ORG.RU

Подтолкните в нужном направлении...


0

0

Люди! Столкнулся со следующей темой. Нужна некая система, которая будет заниматься переработкой бинарных пакетов размером в пределах 8-12 килобайт. Суть переработки в сортировке по типам, возможно изменение содержания, отклонение, и передача далее (не важно куда), при невозможности передачи - организация очередей, ограниченных кол-венно эдак в 100-200 тысяч пакетов. При этом транспортная часть получение/передача не проблема. Основной упор - потеря пакетов весьма критична.

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

anonymous

Ответ на: комментарий от K_X_XyHTA

> А зачем для очередей Postgres? Самому никак не сделать?

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

> Благо в ресурсах ограничен не сильно.

Если все лезет в память, то глянь в сторону erlang его для похожей задачи проектировали (АТС). Там многое из того что ты перечислил решается на раз. Если надо делать что-то сложное по вычислениям, С прога лепится на ура через stdio.

yuriy123
()
Ответ на: комментарий от anonymous

базу юзать помоему для этой задачи не имеет смысла, если же ты часть ответсвенности(за проеб данных например) хочешь спихнуть на поставщика базы то не получится, все равно отвечать будешь ты

проще всего огранизовать распределенное хранилище в памяти и на внешнем носителe .. релевантные данные(или предполагаемо релевантные [которые станут релевантными не более чем за определенный период времени]) храни в памяти .. те данные которые теряют релевантность(или предполагаемо потеряют релевантность за период времени не больше оговоренного) складывай на внешние хранилище, может даже в там же формате как они и в памяти (чистый думп), при этом имея некоторую мета информацию о задумпченных данных (что бы потом быстрее выгребать данные из думпа) ..

это будет работать на порядок(?) быстрее любой базы

lg ★★
()
Ответ на: комментарий от lg

по моему наоборот.. Если пакет потеряет свою релевантность то его можно без опаски в памяти держать, а если пакет не теряет релевантность, то держа его в памяти можно про*бать его при крэше..

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

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

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

так же никто тебя не спасет если переглючит железо .. такие продукты проходят жесткое тестирование и оценку (может даже стороннюю) .. как только продукт принимают к использованию такие ситуации как сдохла память, свалилась операционка, свалился сам продукт - априорно считаются несчастным случаем, .. ну конечно если проблема в продукте то разработчик обязуется исправить это ..

в этом то и большая проблема, что нормального crash dumpа нельзя записать, к тому моменту когда ты готов сбросить думп процесса (то есть сначала ты скидываешь важные данные куда-то, а *только потом* записываешь думп) на винт для дальнейшего исследования, у тебя контекст краша уже утерян и это делает процесс дебага достаточно сложным перефразируя тебя можно сказать что "лучше релевантные данные в памяти хранить, потому что, что будет если внешнее хранилище начнет таймаутить на read реквесты? - все релевантные данные будут потеряны" ..

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

при твоем подходе очень вероятно что у тебя через какой-то промежуток времени после начала работы системы - релевантных данных вообще не будет

lg ★★
()
Ответ на: комментарий от lg

> базу юзать помоему для этой задачи не имеет смысла, если же ты часть ответсвенности(за проеб данных например) хочешь спихнуть на поставщика базы то не получится, все равно отвечать будешь ты.

Это не новость. Тем кто спрашивать будет за проеб вообще глубоко фиолетово до реализации. Просто помимо реализации хранилища есть еще реализация транспортной подсистемы и подсистемы переработки / распределения. Есть риск затянуться по срокам, поскольку реализация JMDB может пожрать кучу времени, проект рискует выйти однобоким.

Хотя в принципе, можно попробовать предложенный вариант с кэшированием горячих данных в памяти и отложенных на внешнем носителе... Просто если писать релевантные данные на носитель - получается та же бадяга что и с БД - любой успешно проработанный пакет вызовет "холостую" запись на носитель, что само по себе будет скорее напоминать "тупой" дамп траффика и ограничивать общую пропускную способность скоростью накопителя.

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

Ладно мужики! Спасибо за советы! Видимо легкого пути тут нет... Впереди месяц на эксперименты , если что-то пойдет не так прийдется покупать коммерческое решение...

anonymous
()

Oracle AQ (Advanced Queueing)

интерфейсы: SQL, JMS
internet propagation особенно порадовал.
рулез.

male
()

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

Военные как правило идут похожим путем кстати - все жизненно важные вещи считаются на 2-3-х машинах независимо, а результаты сравниваются...

AIv ★★★★★
()
Ответ на: комментарий от AIv

обычно так и делают кстати .. вон например google - у них текучка - каждый день компы сгорают или ломаются ..

lg ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.