Комментарии 7
Интересует несколько моментов:
1. Зачем перехваченные сообщения писать в БД?
— Это как минимум увеличит затраты на хранение данных, поскольку место отъедаемое СУБД под хранения BLOB (например, для перехваченного VoIP звонка) всегда больше чем сам BLOB.
— А также не дает возможность (вернее сильно усложняет) применения внешнего сжатия, например банального архивирования перехваченных текстовых данных.
2. Есть ли опыт использования NoSQL решения для этих целей?
Существуют апологеты от разработчиков SIEM, которые утверждают что для SIEM SQL это зло.
В DLP хранимых данных очевидно меньше будет чем в SIEM, но если говорить о масштабируемости то мысль может быть и правильная.
1. Зачем перехваченные сообщения писать в БД?
— Это как минимум увеличит затраты на хранение данных, поскольку место отъедаемое СУБД под хранения BLOB (например, для перехваченного VoIP звонка) всегда больше чем сам BLOB.
— А также не дает возможность (вернее сильно усложняет) применения внешнего сжатия, например банального архивирования перехваченных текстовых данных.
2. Есть ли опыт использования NoSQL решения для этих целей?
Существуют апологеты от разработчиков SIEM, которые утверждают что для SIEM SQL это зло.
В DLP хранимых данных очевидно меньше будет чем в SIEM, но если говорить о масштабируемости то мысль может быть и правильная.
Добрый день, спасибо за интересные вопросы. По пунктам:
1. На продуктивах система настраивается так, что исходники сообщений сохраняются в так называемое Файловое Хранилище, которое представляет собой дерево каталогов (по дате – времени), внутри которых в сжатом виде (gzip) хранятся исходники сообщений. Так что обычно в БД BLOB – отсутствуют.
2. Система хранения данных у нас состоит из 3-х компонент. Это реляционная БД (PostgreSQL или Oracle), Файловое хранилище и индекс Elasticsearch. Собственно последний и есть noSQL решение, которое мы используем. При помощи elastic-а мы индексируем наиболее часто используемые при поисках метаданные, события, все тексты. Полнотекстовый поиск в Solar Dozor 6 производится только через Elasticsearch. Поиски производятся очень быстро + полезная функция прогноза наличия результата поиска.
1. На продуктивах система настраивается так, что исходники сообщений сохраняются в так называемое Файловое Хранилище, которое представляет собой дерево каталогов (по дате – времени), внутри которых в сжатом виде (gzip) хранятся исходники сообщений. Так что обычно в БД BLOB – отсутствуют.
2. Система хранения данных у нас состоит из 3-х компонент. Это реляционная БД (PostgreSQL или Oracle), Файловое хранилище и индекс Elasticsearch. Собственно последний и есть noSQL решение, которое мы используем. При помощи elastic-а мы индексируем наиболее часто используемые при поисках метаданные, события, все тексты. Полнотекстовый поиск в Solar Dozor 6 производится только через Elasticsearch. Поиски производятся очень быстро + полезная функция прогноза наличия результата поиска.
Как давно вы внедряли это решение? Если недавно, не рассматривали ли вы расширение pg_pathman для PostgreSQL? Оно позволяет более эффективно секционировать таблицы чем в нативном постгресе.
Мы изучали данное решение. В целом для наших целей все равно бы пришлось много дополнительной обвязки дописывать для наших задач. Плюс самое большое его преимущество в улучшении построения плана запроса, где видно большое преимущество на большом кол-ве секций, а у нас редко когда нужно в онлайне держать более 30-40 секций.
Укладывание данных в нужный набор таблиц производится по триггеру, который создается отдельно под каждую секцию.
а как на счет балковой операций? с построчными операциями нет вопросов, но как на счет апдейта, ну скажем, одного миллиона строк? Триггеру построчно придется разруливать в какую «секцию» податься за поиском той или иной строки. Вы решили очень узкую задачу и говорить о «замене» не приходится
Ненагруженная система, по большому счёту. Потому и устроила имитация партиционирования. Имитация, настаивают. Раскладывание триггером по партициям — очень смешно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Замена Oracle на PostgreSQL и возможности работы с секционированием внутри DLP-системы