За последние несколько месяцев я написал серию статей, посвященных изменению размеров баз данных о финансовых услугах после применения средств сжатия таблиц, сжатия текстов на языке XML, а также технологии сокращения размеров текстов PDF. Я с успехом применял эти методы на многих сайтах, но недавно обнаружил сайт, где их использование приводит скорее к увеличению, а не к сокращению объема данных. И чем больше усилий я прилагал для улучшения результата, тем хуже он становился. Предлагаю вам вместе разобраться, в чем здесь дело.

Преобразование базы данных

Я уже писал о том, насколько важен такой метод обработки, как сжатие таблиц, а также о результатах, получаемых при его применении. Но надо сказать, что один из первых шагов, всегда совершаемых мною перед применением метода сжатия таблиц, состоит в определении, какие таблицы (а если они разделены, то какие разделы таблиц) следует сжимать с помощью алгоритма ROW или PAGE. В третьей статье серии «Сочетание разных типов сжатия по алгоритмам ROW и PAGE» (опубликована в Windows IT Pro/RE № 8 за 2016 год) я представил код, который можно использовать для определения подходящего способа сжатия. Применять метод ROW ко всем таблицам (или разделам), равно как и метод PAGE, нецелесообразно, так что предварительная классификация имеет большое значение. Но поскольку в ходе выполнения предложенного мною кода решения принимаются на базе динамических административных представлений, которые получают новые значения при каждом перезапуске системы, эти решения следует реализовывать лишь в тех системах, которые функционируют в течение некоторого времени без перезапуска.

Итак, перед нами база данных некоей крупной финансовой организации. По всем признакам к ней вполне можно применить предложенный мною метод и выяснить, какие алгоритмы подойдут для сжатия тех или иных таблиц. Обслуживающий базу данных сервер функционирует без остановок вот уже в течение семи месяцев, а ее таблицы приобрели достаточные размеры, чтобы представлять интерес для исследователя. Я выполнил свои сценарии и получил хороший набор объектов для сжатия по алгоритмам PAGE и ROW. Однако, зная, что таблицы имеют внушительные размеры, я понимал, что выполнить все необходимые операции по перекомпоновке таблиц и индексов в течение одного перерыва в работе невозможно. Поэтому мы запланировали целую серию сеансов, растянутую на несколько выходных дней.

Перед тем как затевать подобные мероприятия на крупных производственных системах, важно позаботиться о том, чтобы все сработало с первого раза. Для проведения испытаний мы получили копию производственной базы данных организации. Она была идентична оригиналу с одним исключением: все данные личного характера в копии были замаскированы.

Маскировка данных, идентифицирующих личность сотрудника, а также конфиденциальных сведений

Перед тем как продолжить обсуждение заданной темы, я считаю необходимым сделать несколько пояснений относительно маскировки производственных данных с целью удаления сведений, идентифицирующих личность сотрудников, а также конфиденциальной информации. Надо сказать, что задача формирования баз данных, которыми могли бы манипулировать разработчики и тестировщики, чрезвычайно сложна. По моим наблюдениям, организации обычно выбирают одно из перечисленных ниже решений.

  • Используют обычную копию производственной базы данных. Надеюсь, что сегодня такой подход применяется нечасто, ибо при этом полностью игнорируются все требования к защите конфиденциальных данных. Но, к сожалению, мне приходится сталкиваться с большим числом компаний, сотрудники которых поступают именно таким образом.
  • Передают испытателям и разработчикам базы данных, содержащие лишь ссылочные сведения, предоставляя им право ввода необходимых данных. В результате неизменно получаются базы данных, не имеющие ничего общего с реальными...
Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF