NA
Нет, не кидал.
C 21 слайда история про оптимизацию. Презентация 2014 года, если что, пять лет назад.
https://www.slideshare.net/JamesSirota/cisco-opensoc
Size: a a a
2019 November 20
RI
Без SSD и прочих чит-кодов (ну NapaTech они для анализа PCAP на лету использовали, ок)
NA
Ага, т.е. референс на опенсок и обработку и так уже структурированных сетевой телеметрит
NA
Что ж, пойду читать. Тезисно тут отвечу.
RI
А зачем заниматься тупой работой? Или стоит задача копать от забора и до обеда? ;)
NA
Эммм, а сиемы теперь только сетевую телеметрию анализируют?
NA
Это крайне редкий кейс.
RI
Эммм, а сиемы теперь только сетевую телеметрию анализируют?
А какая разница, вот серьёзно? Или опять данные не той системы завезли?
NA
Разница очень существенная. На уровне нормализации - катастрофическая. Ибо иметь 1 регулярку и 30-50 одновременно работающих - существеенно по ьакьам процессора
NA
На уровне хранения - индексировать 20 полей от телеметрит и 100 - существенно
NA
Я не хочу сейчас вдаваться в детали. Завтра - послезавтра от меня будет pdf с разбором вашего кейса
NA
Благо я смотрел на Метрон и знаю, где у него болит
RI
Разница очень существенная. На уровне нормализации - катастрофическая. Ибо иметь 1 регулярку и 30-50 одновременно работающих - существеенно по ьакьам процессора
Может быть, вы просто что-то делаете не так на уровне логики?
RI
На уровне хранения - индексировать 20 полей от телеметрит и 100 - существенно
Это говорит об неудачно подобранной системе хранения данных
RI
Разница очень существенная. На уровне нормализации - катастрофическая. Ибо иметь 1 регулярку и 30-50 одновременно работающих - существеенно по ьакьам процессора
Современные процессоры легко обрабатывают сотни регулярок в многопотоке. То, о чём вы говорите - это явные архитектурные ошибки, либо неоптимальная обработка
NA
Нет, просто я ставлю вопрос шире, так как ставится перед продуктами класса СИЕМ, а не анализаторами сетевой телеметрит
NA
Ruslan Ivanov
Современные процессоры легко обрабатывают сотни регулярок в многопотоке. То, о чём вы говорите - это явные архитектурные ошибки, либо неоптимальная обработка
Скажу вам по секрету, регулярки - не самый быстрый способ разбора текста
MA
Скажу вам по секрету, регулярки - не самый быстрый способ разбора текста
а NoSQL очень херовый на реально больших объемах.)
DG
Рус об этом говорил ещё когда шёл срач бинарные данные VS plaintext по скорости разбора