Поляков С. Н. «Современные технологии обработки больших объемов данных в решениях PKI компании «Сигнал-КОМ»»

Какой удостоверяющий центр (УЦ) выбрать для поддержки своих защищенных систем или приложений? Будет ли решение масштабируемым? Сколько пользователей в состоянии обслужить УЦ? Сто тысяч? Пятьсот тысяч? А если их окажется миллион?

Эти и подобные вопросы в первую очередь интересуют клиентов при построении инфраструктуры открытых ключей (Public Key Infrastructure – PKI).

Уже более 15 лет компания «Сигнал-КОМ» занимается проектированием PKI-решений и для этой цели разработала и сертифицировала в ФСБ РФ программно-аппаратный комплекс УЦ Notary-PRO, обеспечивающий управление полным жизненным циклом цифровых сертификатов. В настоящей статье будут рассмотрены проблемы эксплуатации Notary-PRO в больших географически распределенных системах с количеством пользователей свыше 250 тыс.

Понятно, что чем больше пользователей обслуживается в УЦ, тем более жесткие требования по производительности, надежности, устойчивости к отказам предъявляются к его отдельным элементам и особенно к базе данных (БД). При этом, как показывает практика, с увеличением объемов записей в БД «узким» местом в работе УЦ становится время отклика системы на интерактивные запросы операторов, связанные обычно с поиском и анализом учетных данных зарегистрированных пользователей. Причем при достаточно большом размере БД некоторые вполне безобидные запросы операторов начинают инициировать перекачку довольно большого объема данных, который может привести к перегрузке сетевых ресурсов и оказать влияние на производительность УЦ в целом.

Чтобы решить эту проблему, специалисты «Сигнал-КОМ» пересмотрели подход к методам оптимизации СУБД, реализованным в ранних версиях УЦ Notary-PRO, и при разработке последней версии 2.6.8 решили ввести принудительное ограничение на максимально допустимый объем передаваемых персоналу УЦ данных, руководствуясь универсальным принципом Парето (20/80) и результатами наблюдений за работой служб администрирования УЦ:

  • обычно для пользователя представляют интерес только 20% данных, а остальные 80% оказываются избыточными;
  • не все хранимые данные требуются одновременно;
  • чтобы получить необходимую запись, пользователь скорее предпочтет итеративный сужающийся поиск, а не долгие перемещения по бесконечным строкам длинного списка;
  • большую часть времени пользователь тратит не на изменение, а на изучение данных.

Применительно к проблеме оптимизации производительности БД в части уменьшения времени отклика при больших объемах запрашиваемой информации реализация принципа Парето в УЦ Notary-PRO свелась к следующим решениям.

  1. Для выборок, представляющих собой скролируемый список строковых элементов, введено настраиваемое пороговое значение, ограничивающее размер данных, передаваемых оператору УЦ, количеством записей в диапазоне от 1000 до 5000, и добавлен указатель, определяющий, откуда должны браться данные – с начала или с конца полной выборки. В случаях, когда необходимые данные не попадают в заданный ограничительный интервал, первоначальный запрос требует уточнений, сокращающих объем полной выборки путем установки дополнительных фильтров.

    Ограничение размера выборки в запросе обеспечивается использованием технологии хранимых процедур на языке PL/SQL Oracle 11g и встроенным оператором TOP в MS SQL Server.

  2. Реализован новый механизм буферизации выборок: SQL-запрос формируется только для группы записей, визуально ограниченной рамками текущего списка строковых элементов. При этом используется механизм поэтапного заполнения визуального элемента. Такая усовершенствованная процедура заполнения буфера значительно сокращает время отклика и экономит ресурсы сервера базы данных.
  3. Дополнительно к имевшемуся ранее фильтру по дате добавлен глобальный фильтр для поиска объектов по атрибутам уникального имени, существенно увеличивший эффективность поиска и навигации в БД с числом зарегистрированных уникальных имен, превышающим 250 тыс. записей.

Внедрение новых принципов обработки данных наряду с использованием последних версий промышленных СУБД – Oracle 11g и MS SQL Server версий 2005–2008 позволяет на порядок уменьшить время отклика УЦ на запросы операторов.