Сегодня мы хотели бы затронуть очень важную для DLP-решений тему – выбор СУБД для хранения данных. Так исторически сложилось, что большинство российских DLP используют для этих целей Oracle Database. На заказчиков это накладывает определенные финансовые ограничения: стоимость лицензий Oracle закладывается в стоимость DLP-системы. Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle могут позволить себе не все – как в техническом, так и в финансовом плане.
Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.
Система Solar Dozor в качестве основной системы хранения данных использует реляционную СУБД. Критерии выбора СУБД до недавнего времени являлись довольно простыми: объем и возможность разделить архив на оперативный и «до востребования».
В отношении объема БД существовали определенные ограничения, выведенные эмпирически: он не должен был превышать 3-4 ТБ (это порядка 5 млн перехваченных сообщений). Выше этих значений наблюдалась значительная деградация работы системы: нагрузка на IO из-за необходимости регулярно запускать запросы на удаление старых данных, вакуминг, снижение скорости выполнения запросов (на больших выборках фактически производилось полное сканирование таблиц). Поэтому если оценка необходимого объема выходила за эти цифры, для хранения данных всегда использовалась СУБД Oracle.
Второй критерий – возможность разделить архив на оперативный и «до востребования» – можно прочитать как необходимость реализовать секционирование на СУБД. Вплоть до 2016 года DLP-система Solar Dozor поддерживала секционирование исключительно на СУБД Oracle.
Мы понимали, что бюджеты заказчиков ограничены, и иногда они просто не могут позволить себе покупку лицензий Oracle. Поэтому в некоторых проектах с объемом хранения в 10-15 Тб мы стали использовать PostgreSQL.
Архитектура и возможности системы Solar Dozor позволяют подключать к ней любое количество баз данных как Oracle, так и PostgreSQL. При этом для каждой базы можно указать, можно ли производить по ней поиск или архивировать в нее сообщения. Поэтому сначала мы решили создавать несколько инстансов СУБД PostgreSQL на одном или разных серверах и поочередно записывать в них данные с периодом в 1 месяц. По истечении срока хранения самая старая база пересоздавалась – и так далее по кругу. Но это решение было довольно дорогим с точки зрения поддержки и подходило только очень узкому кругу заказчиков.
Следующая реализация секционирования данных тоже была построена на идее «одна секция – одна БД», но теперь все БД создавались в рамках одного инстанса PostgreSQL. Для всех операций работы с секциями были написаны соответствующие утилиты, и такая схема вполне неплохо работала у нескольких заказчиков. Опираясь на нее, некоторые даже мигрировали с Oracle.
Однако у этой реализации все же был ряд проблем, связанных с особенностями работы ряда сервисов в Solar Dozor. При большом количестве секций необходимо было держать одновременно более 1000 соединений на инстанс. Кроме того, было не очень удобно производить обновление схемы данных при выходе новых релизов.
В итоге мы решили использовать секционирование, которое предлагает нам сам PostgreSQL. То есть для всех таблиц, в которых присутствует ключ, ссылающийся на дату укладки сообщения, создаются наследованные таблички с ограничением по этому ключу. Укладывание данных в нужный набор таблиц производится по триггеру, который создается отдельно под каждую секцию. Такая схема дает нам весь необходимый функционал: при запросах поднимаются с диска только те секции данных, на период которых идет запрос; если необходимо вывести секцию из обращения, таблицы выводятся из наследования базовой, после чего делается их дамп. Для всех таких секций написаны утилиты для управления: перевод в оффлайн/онлайн, добавление, удаление, дамп и т.д.
Эта реализация стала реальной заменой Oracle, позволяя держать десятки терабайт данных в оперативном доступе и еще десятки – в архиве на более медленных системах хранения. Всем новым заказчикам мы предлагаем делать секционирование на PostgreSQL. Если уже существующий заказчик с секционированием на Oracle хочет перейти на PostgreSQL, мы предлагаем ему записывать новые данные в PostgreSQL, а старые оставить в Oracle до момента их устаревания.
Писать специальные процедуры миграции данных с Oracle на PostgreSQL мы сочли не целесообразным, потому что и сама их разработка, и непосредственно работы по миграции обходятся очень дорого, особенно если у заказчика есть отключенные данные каких-либо старых версий продукта. Да и запросов таких очень мало.
В DLP-систему сохраняются все перехваченные сообщения. Для задач DLP важно знать, когда информация передавалась и была перехвачена. Таким образом, все перехваченные сообщения имеют четкую привязку к линии времени. Поэтому у нас используется RANGE-секционирование по дате перехвата, точнее, по дате поступления сообщения на обработку в DLP-систему как наиболее приближенного к моменту перехвата. Итак, при использовании секционирования данные разбивается на куски по временным периодам. Обычно используется период времени в одну неделю.
Какие преимущества может дать такая разбивка данных? Чаще всего запросы в рамках DLP-системы делаются в отношении весьма ограниченных, небольших периодов времени. Таким образом, если мы храним данные в течение 3-6 месяцев и запрашиваем информацию за 1-2-4 недели, мы существенно увеличиваем скорость работы решения уже за счет того, что с дисковой системы читается меньше данных. Понятно, что как на секционированной, так и на несекционированной схеме параллельно строится значительное количество разнообразных индексов, которые позволяют не производить полное сканирование таблиц и читать меньший объем данных с диска. Но здесь мы во многом оставляем на усмотрение оптимизатора БД, надо ли делать полное сканирование или лучше использовать индекс. Если же используется секционирование, мы всегда попадаем в довольно четкий кусок данных, занимающий ограниченный объем на диске.
Скорость выполнения запросов является только одним из преимуществ использования секционирования. Еще один плюс – это возможность в разы упростить управление сроком хранения данных. Если секционирования нет, приходится ежедневно или еженедельно делать запрос на удаление старых данных, иначе при достижении определенных объемов БД начинаются проблемы с ее производительностью и обслуживанием. Секционирование позволяет свести удаление старых данных к более простой операции удаления конкретной секции. В Oracle для этого достаточно удалить с дисковой системы два табличных пространства секции и их файлы данных. В PostgreSQL необходимо удалить базы данных, созданные под эту секцию.
В ближайшем релизе Solar Dozor секционирование на PostgreSQL будет реализовано стандартным методом с использованием inherit-таблиц. Таким образом, в новой версии удаление секции будет сводиться к удалению таблиц, отвечающих за эту секцию.
Большим преимуществом секционирования данных в DLP является возможность разделить архив данных на оперативный и так называемый «архив до востребования». В чем суть этого разделения?
Для большинства заказчиков важно иметь в прямом/оперативном доступе перехваченные данные за последние 3-6-12 месяцев. Все, что старше этого периода, некоторые вообще готовы удалять. Однако многие хотят сохранить эти данные, чтобы иметь возможность проводить расследования, опираясь на полный объем перехваченных сообщений. Это может быть продиктовано как внутренними стандартами безопасности компании, так и требованием соответствия ряду стандартов. Большие сроки хранения требуют от дисковой системы объемов в десятки терабайт. К тому же, для оперативного архива обычно проектируются SAS 10k диски, и набирать ими эти десятки терабайт довольно дорого. В секционированной схеме данные, которые выходят за период оперативной доступности, можно легко отключить от поисковой машины и разместить на более медленных и дешевых системах хранения. Ряд заказчиков покупает под хранение offline-архива SATA-диски, другие используют ленточные библиотеки, что особенно актуально при необходимости хранить 200-300 терабайт данных, которые понадобятся всего несколько раз за все время хранения. Реализовано это следующим способом:
Oracle:
Табличные пространства устаревшей секции переводятся в offline, после чего файлы данных этой секции переносятся на подготовленное для них хранилище. Когда возникает необходимость в поиске за период, относящийся к отключенной секции, файлы данных переносятся обратно, секция подключается, и можно производить по ней любые запросы. После этого секция отключается и убирается обратно.
PostgreSQL:
Устаревшая секция переводится в offline, далее делаем дамп (pg_dump) таблиц (или базы данных), отвечающих за данную секцию, и удаляем эти таблицы из БД. Дамп сохраняется в подготовленном offline-хранилище. Далее, по аналогии с Oracle, при востребованности этих данных производится восстановление удаленных таблиц из дампа (pg_restore). Секции переводятся в online, после чего можно делать по ним поиск. По окончании расследования секция переводится в offline, таблицы удаляются – место освобождается.
Чтобы осуществлять все эти операции отключения/подключения, не надо быть квалифицированным администратором СУБД Oracle или PostgreSQL. Для этого есть специализированные утилиты, которые позволяют смотреть состояние секций, подключать, отключать, удалять их и т.д. В случае с Oracle часть операций по отключению/подключению секций и переноса секций в другой каталог доступны непосредственно из веб-интерфейса. Автоматизация создания и отключения секций внутри СУБД снимает вопрос трудозатрат на обслуживание. Остаются только операции по копированию отключенных секций на подготовленные хранилища, но они не требуют специальной квалификации администраторов.
В результате, благодаря секционированию в СУБД Solar Dozor, мы добились повышения производительности продукта и скорости поиска. Архив стал проще в управлении – перехваченные данные легко выгружать, освобождая дисковые ресурсы, и при необходимости загружать обратно. Все это делается в автоматическом режиме, поэтому нанимать отдельного квалифицированного специалиста для управления СУБД не нужно. Наконец, заказчик может хранить у себя данные за какой угодно период времени и при этом не сильно тратиться на систему хранения.
Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.
Oracle vs 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 будет реализовано стандартным методом с использованием inherit-таблиц. Таким образом, в новой версии удаление секции будет сводиться к удалению таблиц, отвечающих за эту секцию.
Сокращение затрат на хранение данных
Большим преимуществом секционирования данных в DLP является возможность разделить архив данных на оперативный и так называемый «архив до востребования». В чем суть этого разделения?
Для большинства заказчиков важно иметь в прямом/оперативном доступе перехваченные данные за последние 3-6-12 месяцев. Все, что старше этого периода, некоторые вообще готовы удалять. Однако многие хотят сохранить эти данные, чтобы иметь возможность проводить расследования, опираясь на полный объем перехваченных сообщений. Это может быть продиктовано как внутренними стандартами безопасности компании, так и требованием соответствия ряду стандартов. Большие сроки хранения требуют от дисковой системы объемов в десятки терабайт. К тому же, для оперативного архива обычно проектируются SAS 10k диски, и набирать ими эти десятки терабайт довольно дорого. В секционированной схеме данные, которые выходят за период оперативной доступности, можно легко отключить от поисковой машины и разместить на более медленных и дешевых системах хранения. Ряд заказчиков покупает под хранение offline-архива SATA-диски, другие используют ленточные библиотеки, что особенно актуально при необходимости хранить 200-300 терабайт данных, которые понадобятся всего несколько раз за все время хранения. Реализовано это следующим способом:
Oracle:
Табличные пространства устаревшей секции переводятся в offline, после чего файлы данных этой секции переносятся на подготовленное для них хранилище. Когда возникает необходимость в поиске за период, относящийся к отключенной секции, файлы данных переносятся обратно, секция подключается, и можно производить по ней любые запросы. После этого секция отключается и убирается обратно.
PostgreSQL:
Устаревшая секция переводится в offline, далее делаем дамп (pg_dump) таблиц (или базы данных), отвечающих за данную секцию, и удаляем эти таблицы из БД. Дамп сохраняется в подготовленном offline-хранилище. Далее, по аналогии с Oracle, при востребованности этих данных производится восстановление удаленных таблиц из дампа (pg_restore). Секции переводятся в online, после чего можно делать по ним поиск. По окончании расследования секция переводится в offline, таблицы удаляются – место освобождается.
Чтобы осуществлять все эти операции отключения/подключения, не надо быть квалифицированным администратором СУБД Oracle или PostgreSQL. Для этого есть специализированные утилиты, которые позволяют смотреть состояние секций, подключать, отключать, удалять их и т.д. В случае с Oracle часть операций по отключению/подключению секций и переноса секций в другой каталог доступны непосредственно из веб-интерфейса. Автоматизация создания и отключения секций внутри СУБД снимает вопрос трудозатрат на обслуживание. Остаются только операции по копированию отключенных секций на подготовленные хранилища, но они не требуют специальной квалификации администраторов.
Итоги
В результате, благодаря секционированию в СУБД Solar Dozor, мы добились повышения производительности продукта и скорости поиска. Архив стал проще в управлении – перехваченные данные легко выгружать, освобождая дисковые ресурсы, и при необходимости загружать обратно. Все это делается в автоматическом режиме, поэтому нанимать отдельного квалифицированного специалиста для управления СУБД не нужно. Наконец, заказчик может хранить у себя данные за какой угодно период времени и при этом не сильно тратиться на систему хранения.
Поделиться с друзьями
Комментарии (7)
ildus
23.03.2017 18:16+1Как давно вы внедряли это решение? Если недавно, не рассматривали ли вы расширение pg_pathman для PostgreSQL? Оно позволяет более эффективно секционировать таблицы чем в нативном постгресе.
alexeyyp
24.03.2017 11:01Мы изучали данное решение. В целом для наших целей все равно бы пришлось много дополнительной обвязки дописывать для наших задач. Плюс самое большое его преимущество в улучшении построения плана запроса, где видно большое преимущество на большом кол-ве секций, а у нас редко когда нужно в онлайне держать более 30-40 секций.
vladimirpen
24.03.2017 11:01Укладывание данных в нужный набор таблиц производится по триггеру, который создается отдельно под каждую секцию.
а как на счет балковой операций? с построчными операциями нет вопросов, но как на счет апдейта, ну скажем, одного миллиона строк? Триггеру построчно придется разруливать в какую «секцию» податься за поиском той или иной строки. Вы решили очень узкую задачу и говорить о «замене» не приходитсяalexeyyp
24.03.2017 11:02+1Наше API не использует балковые операции + нет таких задач, где бы потребовался апдейт 1 миллиона строк.
Brass_nn
28.03.2017 11:02Ненагруженная система, по большому счёту. Потому и устроила имитация партиционирования. Имитация, настаивают. Раскладывание триггером по партициям — очень смешно.
imbasoft
Интересует несколько моментов:
1. Зачем перехваченные сообщения писать в БД?
— Это как минимум увеличит затраты на хранение данных, поскольку место отъедаемое СУБД под хранения BLOB (например, для перехваченного VoIP звонка) всегда больше чем сам BLOB.
— А также не дает возможность (вернее сильно усложняет) применения внешнего сжатия, например банального архивирования перехваченных текстовых данных.
2. Есть ли опыт использования NoSQL решения для этих целей?
Существуют апологеты от разработчиков SIEM, которые утверждают что для SIEM SQL это зло.
В DLP хранимых данных очевидно меньше будет чем в SIEM, но если говорить о масштабируемости то мысль может быть и правильная.
alexeyyp
Добрый день, спасибо за интересные вопросы. По пунктам:
1. На продуктивах система настраивается так, что исходники сообщений сохраняются в так называемое Файловое Хранилище, которое представляет собой дерево каталогов (по дате – времени), внутри которых в сжатом виде (gzip) хранятся исходники сообщений. Так что обычно в БД BLOB – отсутствуют.
2. Система хранения данных у нас состоит из 3-х компонент. Это реляционная БД (PostgreSQL или Oracle), Файловое хранилище и индекс Elasticsearch. Собственно последний и есть noSQL решение, которое мы используем. При помощи elastic-а мы индексируем наиболее часто используемые при поисках метаданные, события, все тексты. Полнотекстовый поиск в Solar Dozor 6 производится только через Elasticsearch. Поиски производятся очень быстро + полезная функция прогноза наличия результата поиска.