Сегодня мы хотели бы затронуть очень важную тему для DLP-решений – выбор СУБД для хранения данных.
Исторически сложилось так, что большинство российских DLP используют для этих целей базу данных Oracle. Это накладывает на заказчиков определенные финансовые ограничения: стоимость лицензий Oracle включена в стоимость DLP-системы.
Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle не всем по карману как технически, так и финансово.
Сейчас, когда импортозамещение шагает по стране, госсектор (и не только) создает спрос на DLP, поддерживающие бесплатные СУБД.
Это очень ощутимый импульс, но, устремившись в сторону бесплатных СУБД, важно сохранить удобство, производительность и функциональность продукта.
В этой статье речь пойдет о том, как мы решили эту проблему, реализовав поддержку PostgreSQL и разработав схему секционирования в Solar Dozor. 
Oracle против PostgreSQL
В качестве основной системы хранения данных в системе Solar Dozor используется реляционная СУБД.До недавнего времени критерии выбора СУБД были довольно простыми: объём и возможность разделить архив на оперативный и «по требованию».
Существовали определенные ограничения на объем базы данных, выведенные опытным путем: он не должен превышать 3-4 ТБ (это около 5 миллионов перехваченных сообщений).
Выше этих значений наблюдалась значительная деградация системы: нагрузка на IO из-за необходимости регулярного выполнения запросов на удаление старых данных, очистка и снижение скорости выполнения запросов (на больших выборках фактически выполнялось полное сканирование таблицы).
).
Поэтому, если оценка необходимого объема выходила за пределы этих цифр, для хранения данных всегда использовалась СУБД Oracle. Второй критерий — возможность разделения архива на оперативный и «по требованию» — можно прочитать как необходимость реализации секционирования на СУБД.
До 2016 года DLP-система Solar Dozor поддерживала секционирование исключительно на СУБД Oracle.
Мы понимали, что бюджеты клиентов ограничены, и иногда они просто не могут себе позволить приобрести лицензии Oracle. Поэтому в некоторых проектах с объемом хранилища 10-15 ТБ мы стали использовать PostgreSQL.
Как мы реализовали секционирование в PostgreSQL
Архитектура и возможности системы Solar Dozor позволяют подключать к ней любое количество баз данных, как Oracle, так и PostgreSQL. При этом для каждой базы данных можно указать, возможен ли в ней поиск или архивирование сообщений.Поэтому сначала мы решили создать несколько экземпляров СУБД PostgreSQL на одном или разных серверах и поочередно записывать в них данные с периодом 1 месяц.
По истечении срока хранения самая старая база данных создавалась заново — и так по кругу.
Но это решение было достаточно дорогим в плане поддержки и подходило лишь для очень узкого круга клиентов.
Следующая реализация секционирования данных также была построена на идее «один раздел — одна база данных», но теперь все базы данных создавались внутри одного экземпляра PostgreSQL. Для всех операций с разделами были написаны соответствующие утилиты, и эта схема вполне хорошо работала у нескольких заказчиков.
Исходя из этого, некоторые даже мигрировали с Oracle. Однако данная реализация все же имела ряд проблем, связанных с особенностями работы ряда сервисов в Solar Dozor. При большом количестве разделов приходилось одновременно поддерживать более 1000 подключений на каждый экземпляр.
Кроме того, было не очень удобно обновлять схему данных при выходе новых релизов.
В результате мы решили использовать то разбиение, которое предлагает нам сам PostgreSQL. То есть для всех таблиц, содержащих ключ, ссылающийся на дату размещения сообщения, создаются наследуемые таблицы с ограничением по этому ключу.
Данные помещаются в необходимый набор таблиц с помощью триггера, который создается отдельно для каждого раздела.
Такая схема дает нам весь необходимый функционал: при выполнении запросов с диска извлекаются только те участки данных на время выполнения запроса; если необходимо вывести раздел из обращения, таблицы выводятся из базового наследования, после чего они сбрасываются.
Для всех подобных разделов написаны утилиты управления: перевод в оффлайн/онлайн, добавление, удаление, сброс и т.д. Данная реализация стала настоящей заменой Oracle, позволяя хранить десятки терабайт данных в оперативном доступе и еще десятки в архиве на более медленных системах хранения.
Всем новым клиентам мы предлагаем выполнить секционирование в PostgreSQL. Если существующий клиент с секционированием Oracle хочет перейти на PostgreSQL, мы предлагаем ему записать новые данные в PostgreSQL и оставить старые данные в Oracle до тех пор, пока они не устареют. Мы посчитали нецелесообразным писать специальные процедуры миграции данных из Oracle в PostgreSQL, поскольку как сама их разработка, так и сама работа по миграции очень дороги, особенно если заказчик отключил данные из каких-либо старых версий продукта.
И таких запросов очень мало.
Чего удалось добиться с помощью секционирования базы данных в DLP-системе
Увеличение производительности
Все перехваченные сообщения сохраняются в DLP-системе.Для задач DLP важно знать, когда информация была передана и перехвачена.
Таким образом, все перехваченные сообщения имеют четкую привязку к временной шкале.
Поэтому мы используем секционирование RANGE по дате перехвата, а точнее, по дате поступления сообщения на обработку в DLP-систему, как ближайшую к моменту перехвата.
Итак, при использовании секционирования данные разбиваются на части по периодам времени.
Обычно используется период времени в одну неделю.
Какие преимущества может дать такая разбивка данных? Чаще всего запросы внутри DLP-системы выполняются на очень ограниченные и короткие периоды времени.
Таким образом, если мы храним данные 3-6 месяцев и запрашиваем информацию за 1-2-4 недели вперед, мы существенно увеличиваем скорость решения за счет того, что с дисковой системы считывается меньше данных.
Понятно, что как на секционированной, так и на несекционированной схеме параллельно строится значительное количество различных индексов, которые позволяют не выполнять полную проверку таблиц и читать с диска меньший объем данных.
Но здесь мы во многом оставляем на усмотрение оптимизатора базы данных, нужно ли делать полное сканирование или лучше использовать индекс.
Если используется секционирование, мы всегда получаем достаточно четкий фрагмент данных, занимающий ограниченный объем дискового пространства.
Снижение нагрузки на администраторов
Скорость выполнения запросов — лишь одно из преимуществ использования секционирования.Еще один плюс – возможность значительно упростить управление хранением данных.
Если секционирования нет, приходится делать ежедневный или еженедельный запрос на удаление старых данных, иначе при достижении определенного объема базы данных начинаются проблемы с ее работоспособностью и обслуживанием.
Разбиение на разделы позволяет свести удаление старых данных к более простой операции удаления определенного раздела.
В Oracle для этого достаточно удалить с дисковой системы два табличных пространства разделов и их файлы данных.
В PostgreSQL необходимо удалить базы данных, созданные для этого раздела.
В следующем релизе Solar Dozor секционирование в PostgreSQL будет реализовано стандартным методом с использованием наследуемых таблиц.
Таким образом, в новой версии удаление раздела будет сведено к удалению таблиц, отвечающих за этот раздел.
Сократите затраты на хранение
Большим преимуществом секционирования данных в DLP является возможность разделить архив данных на оперативный и так называемый «архив по требованию».В чем суть этого разделения? Для большинства клиентов важно иметь прямой/онлайн-доступ к перехваченным данным за последние 3-6-12 месяцев.
Некоторые люди готовы удалить все, что старше этого срока.
Однако многие хотят сохранить эти данные, чтобы проводить расследования на основе всего объема перехваченных сообщений.
Это может быть продиктовано либо внутренними стандартами безопасности компании, либо требованием соблюдения ряда стандартов.
Длительные сроки хранения требуют дисковой системы с объёмами в десятки терабайт. Кроме того, диски SAS 10k обычно предназначены для оперативных архивов, и заполнять ими эти десятки терабайт довольно дорого.
В секционированной конструкции данные, срок доступности которых превышает период онлайн-доступности, можно легко отключить от поисковой системы и поместить в более медленные и дешевые системы хранения.
Часть клиентов покупают SATA-диски для автономного архивного хранения, другие используют ленточные библиотеки, что особенно важно, когда необходимо хранить 200-300 терабайт данных, которые понадобятся всего несколько раз за весь период хранения.
Это реализуется следующим образом: Оракул Табличные пространства устаревшего раздела выводятся в автономный режим, после чего файлы данных этого раздела передаются в подготовленное для них хранилище.
При необходимости поиска периода, относящегося к отключенному разделу, файлы данных передаются обратно, раздел подключается и по нему можно делать любые запросы.
После этого раздел отключается и удаляется обратно.
PostgreSQL Устаревший раздел выводится в оффлайн, затем мы дамп (pg_dump) отвечающих за этот раздел таблиц (или базы данных) и удаляем эти таблицы из базы данных.
Дамп сохраняется в подготовленное автономное хранилище.
Далее по аналогии с Oracle, когда эти данные востребованы, удаленные таблицы восстанавливаются из дампа (pg_restore).
Разделы передаются в онлайн, после чего их можно искать.
По окончании расследования раздел переводится в офлайн, таблицы удаляются, а место освобождается.
Чтобы выполнить все эти операции отключения/подключения, вам не нужно быть квалифицированным администратором СУБД Oracle или PostgreSQL. Для этого существуют специализированные утилиты, позволяющие просматривать состояние разделов, подключать, отключать, удалять их и т.д. В случае с Oracle некоторые операции по отключению/подключению разделов и перемещению разделов в другой каталог доступны непосредственно из каталога.
веб интерфейс.
Автоматизация создания и отключения разделов внутри СУБД исключает вопрос трудозатрат на обслуживание.
Остаются только операции по копированию отключенных разделов в подготовленные хранилища, но они не требуют особой квалификации администраторов.
Полученные результаты
В результате, благодаря секционированию в СУБД Solar Dozor, мы добились повышения производительности продукта и скорости поиска.Архивом стало проще управлять — перехваченные данные можно легко выгрузить, освободив дисковые ресурсы, и при необходимости загрузить обратно.
Все это делается автоматически, поэтому нет необходимости нанимать отдельного квалифицированного специалиста для управления СУБД.
Наконец, клиент может хранить данные в течение любого периода времени, не тратя много денег на систему хранения.
Теги: #информационная безопасность #открытый исходный код #база данных #postgresql #oracle #база данных Oracle #Solar Security #dlp #dlp #solar dozor #разделение
-
Различные Аспекты Поискового Маркетинга
19 Oct, 24 -
Как Я Вернул 530 Долларов
19 Oct, 24
