Куда вы складываете данные netflow, посоветуйте замену mysql

[disappointed]

На данный момент всё кладётся netflow2mysql в 5ую mysql базу,скорость выборки устраивает но хочется чего-то нового.

Что посоветуете, постгресс? оракл?

Какие коллекторы умеют писать в них напрямую, или киньте линки на перловые скрипты для этого.

[Ugnich Anton]

А зачем ложить сырые данные в БД ?

[jab]

Нечего в базе данных делать данным netflow, достаточно аггрегированных счетчиков.

[jab]

При этом подозреваю что постгресс и оракл на таких задачах и сопоставимом железе покажут такую же ( если не худшую ) скорость. Они выигрывают на большом количестве таблиц/потоков/транзакций, а bulk insers/select в пару потоков - это как раз mysql ублюдочный.

[balamutang]

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

[ram_scan]

По сырому нетфлоу клиенты имеют свойство заказывать детализацию. До пакета. Поэтому приходится таки держать в базе...

[Vovik]

По сырому нетфлоу клиенты имеют свойство заказывать детализацию. До пакета. Поэтому приходится таки держать в базе...

 

нафига? пусть такая выборка будет прямо с харда идти, скажем раз в 20 минут и отправляться на почту юзеру и только по его запроосу (например как в системе ИССА у МТС). если юзеров будет много, то онлайновые детализации в скором времени займут 100% cpu.

[ram_scan]

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

[balamutang]

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

а значит "грепать" мускулем сотенку гигов при таком раскладе - нормально?

а за детализацию деньги надо брать....

[disappointed]

Нетфлау кладётся в базу для того чтобы клиент мог у меня по клику в личном кабиненте подсмотреть детализацию с точностью до потока за любой промежуток времени (в разумных пределах)

Ну если нет смысла менять mysql на что-то другое то пусть работает дальше.

[Виктор С. Грищенко]

В БД - аггрегированное по 10 мин.

Логи - по запросу. Всё равно хрен угадаешь, что искать нужно будет.

Вариант: cgi-скрипт, который поднимает с диска файлики flow-tools с NetFlow, переводит в текстовый формат и отсылает клиенту по http. Пусть хоть гиг логов съест :)

[disappointed]

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

[Ugnich Anton]

Не надо приспосабливать СУБД там, где должны работать другие инструменты.

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

[Виктор С. Грищенко]

Не надо приспосабливать СУБД там, где должны работать другие инструменты.

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

Yep. Но grep - не гламурно, рекомендую flow-tools!

[ram_scan]

Не надо приспосабливать СУБД там, где должны работать другие инструменты.

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

 

Сомнительно что быстрее. Компактнее - да, но не быстрее. По крайней мере у меня греп работает медленнее. Оно кстати у меня еще и агрегируется. В этой же базе. И ротация таблиц/баз сделана, чтобы оно в архив отьезжало.

 

Зато я по этим сырым данным в любой момент могу сделать любую агрегацию. Не только потому что клиент просит, а для себя, тенденции посмотреть, аномалии выявить...

[Kuzmich]

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

 

А в Оракле есть еще очень много вкусных вещей для такого хранения - партиционированные таблицы, например....

[disappointed]

Пишите файлами на винт, по запросу клиента применяйте grep. Это будет однозначно быстрее, чем все вышеперечисленные СУБД.

У меня приличный обьём. греп не будет настолько быстро грепать как нужно.

[SergeiK]

Коллеги, это же какого размера должна быть БД, чтоб хранить NetFlow потока в 10 Терабайт/мес в БД в нежатом виде хотя бы с одного роутера хотя бы месяца за 3-4?!

А если накрутить индексов?

 

И кстати, по flow-tool. Он использует вполне себе эффективную БД - файловую систему, для разбора логов по времени.

Это же может сделать любой другой коллектор, и grep (или другие средства, не суть важно) по этим файлам будет бегать вполне даже шустро. И если процессор сервера хорош, то считать и "прогрепить" жатый файл за 15 минут будет быстрее, чем поднять файл индексов всех записей за 3 месяца.

[Ugnich Anton]

Коллеги, это же какого размера должна быть БД, чтоб хранить NetFlow потока в 10 Терабайт/мес в БД в нежатом виде хотя бы с одного роутера хотя бы месяца за 3-4?!

(Обьем переданых данных за месяц)/(средний размер сессии в байтах)*(размер записи в БД)*(количество месяцев)

[Ugnich Anton]

У меня приличный обьём. греп не будет настолько быстро грепать как нужно.

Какие данные из потока используете (названия полей netflow) ?

[disappointed]

rid

hid

ip_protocol_version

last_switched

first_switched

bytes

pkts

input_snmp

output_snmp

ipv4_src_addr

ipv4_dst_addr

prot tinyint(3)

src_tos

l4_src_port

l4_dst_port

tcp_flags

 

вторая

 

hid

version

system_uptime

unix_seconds

package_sequence

source_id

 

обычные две таблички netflow2mysql

есть способ проще?

[balamutang]

Нетфлау кладётся в базу для того чтобы клиент мог у меня по клику в личном кабиненте подсмотреть детализацию с точностью до потока за любой промежуток времени (в разумных пределах)

Ну если нет смысла менять mysql на что-то другое то пусть работает дальше.

видимо объем трафика небольшой раз устраивает объем базы и скорость записи/выборки.

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

 

по вопросу хранения нетфлоу в мускуле - представим пакет UDP (или ICMP) размером 10-20 байт. теперь представим поток из этих пакетов 10 мбит (контра например какая-нить из 30-40 человек). каждый пакет - одна запись в таблицу. объем данных прошедший через сеть - 15 байт, объем данных прошедшик от коллектора к мускуль-серверу - 100-150 байт. при этом по 10 мбитам в секунду может проскочить грубо говоря 60000 пакетов, в мускуль-сервер за эту секунду зальется примерно 9 метров запросов (требуемая скорость гдето 65 мбит).

 

вопрос - а если канал будет не 10 мбит, а 1 гигабит? придется покупать десятигигабитные сетевухи и ведро ксеонов?

[jab]

прошу прощения, сам я не местный, но про какую версию netflow идет речь ?

[disappointed]

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

отнюдь не пиковые, да и не клацает кто попало просто так по кнопкам в личном кабинете.

[Ugnich Anton]

отнюдь не пиковые, да и не клацает кто попало просто так по кнопкам в личном кабинете.

Просто скажите, сколько у вас пользователей и все вопросы отпадут. :)