Использование Dbreplication При Свертывании Баз Данных На Microsoft Sql Server

Системы корпоративного учета характеризуются постепенным увеличением объема баз данных за счет накопления исторической информации.

Со временем размер базы данных может достичь таких размеров, что провоцирует ряд проблем с производительностью, обслуживанием, доступным дисковым пространством и так далее.

Сегодня мы рассмотрим два подхода к решению этой проблемы: увеличение аппаратных ресурсов и свертывание исторических данных.

Введение

Проблемы

Например, в системах на платформе 1С возникают проблемы с такими рутинными операциями, как обновление конфигурации, обновление платформы 1С.

По мере роста базы данных ситуация постепенно ухудшается, и рано или поздно придется принимать меры.

Подход №1: Аппаратное обеспечение

Это может быть как покупка более мощных серверов, дискового хранилища и т. д., так и аренда более мощного оборудования в стороннем дата-центре или облаке.

Если вы пойдете по этому пути, хорошим вариантом будет размещение базы данных в облаке Microsoft Azure. Azure предоставляет несколько вариантов архитектуры размещения базы данных: MS SQL на виртуальной машине Azure и три варианта базы данных SQL Azure в облаке.

Поэтому можно подобрать наиболее оптимальный вариант размещения в зависимости от особенностей конкретной базы данных и условий ее эксплуатации.

Azure имеет ряд преимуществ перед покупкой собственного оборудования.

Одним из главных является огромная аппаратная мощность, которую может предоставить Azure. А также гибкий подход к использованию этих мощностей в зависимости от фактической нагрузки.

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

А в остальное время используйте более бюджетную конфигурацию ресурса.

Таким образом, с одной стороны, вы в нужный момент имеете доступ к огромному ресурсному потенциалу Azure (который, кстати, все время растет), а с другой стороны, вам не придется переплачивать за излишки.

емкость, когда она вам не нужна.

Однако, несмотря на относительную простоту, увеличение аппаратных ресурсов не является универсальным решением.

Во-первых, положительный эффект зачастую далеко не пропорционален финансовым вложениям (много вложений – мало эффекта).

Во-вторых, эффект временный, так как база продолжает расти и требует все больше ресурсов, все больше финансовых вложений.

В любом случае такой подход имеет право на жизнь и широко используется.

Но дальше мы на этом останавливаться не будем, так как основной целью статьи является не «аппаратный» подход, а «программный» подход, описанный ниже.

Подход №2: складывание основания

Свернутая база данных содержит данные лишь за сравнительно небольшой период эксплуатации, обычно не более 1-2 лет. Очевидно, что степень снижения в каждом случае разная, и какие-то конкретные цифры назвать сложно.

И все же за ориентир мы возьмем показатель уменьшения базы на 50 - 70%, то есть примерно в 2-3 раза, примерно именно это чаще всего и оказывается на практике меньше или наоборот. , больше - бывает редко.

Мы не будем подробно останавливаться на полученных выигрышах.

Очевидно, что при уменьшении базы в 2-3 и более раз эффект производительности будет очень мощным и долгосрочным, и дополнительных инвестиций в оборудование можно избежать.

А механизм складывания, однажды разработанный и испытанный, можно будет использовать повторно в будущем.

В целом, это отличное, эффективное решение, которое гарантированно дает результат.

Сложность реализации свертки

И дело даже не в разработке самого механизма свертки.

Да, это развитие тоже непростая задача, но так или иначе ее можно решить.

Дело в другом.

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

Неизбежно возникает целый комплекс взаимосвязанных трудностей; давайте посмотрим на них.

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

• Вмешательство в работу пользователей.
  • Выполнение агрегации непосредственно в производственной базе данных параллельно с работой пользователей крайне сложно или даже невозможно из-за высокой дополнительной нагрузки и блокировок, создаваемых процессом агрегации.

• Технологического окна нет.
  • Просто не существует технологического окна достаточной длины, когда пользователи не работают над объединением.

    Ведь процесс свертки для баз данных такого размера обычно занимает десятки часов или несколько дней.

• Высокие риски при обрушении непосредственно рабочей базы.
  • Подход, при котором алгоритм свертки применяется непосредственно к рабочей базе данных, сам по себе весьма рискован по ряду причин.

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

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

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

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

    И от них нужно как-то избавиться, чтобы файл данных стал меньше.

    В противном случае выигрыш в виде дискового пространства будет потерян.

    Один из вариантов — выполнить типичное SHRINK. А на таких объемах это очень длительная процедура (многие часы, а то и десятки часов).

Недостаточно разработать механизм свертки; его также необходимо применить.

Более того, именно приложение часто становится узким местом.

Примечание.

Далее мы оставляем за скобками разработку самого механизма свертки (иными словами, алгоритма удаления исторических данных), какими бы средствами он ни был создан.

И мы ориентируемся только на использование в бою уже реализованного механизма.

Решение с использованием DBREPLICATION

Но выходы еще есть.

Существует эффективная методика, позволяющая распутать весь клубок трудностей, убрать риски и гарантировать достижение цели.

Он предполагает использование технологии обмена данными DBREPLICATION. Решение подходит как для традиционного варианта инфраструктуры, так и для облака Microsoft Azure. Вкратце, суть вот в чем.

• Создается клон базы данных, настраивается односторонний обмен данными между клоном и основной базой данных с помощью DBREPLICATION. Допускается размещение основной базы данных и/или ее клона (обеих или одной) в облаке Microsoft Azure.
• Пользователи не работают в клоне; процесс сокращения начинается там.

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

  Таким образом, пропадает привязка к длительности технологического окна!

• Пользователи работают без вмешательства в основную базу данных.

  А технология DBREPLICATION автоматически переносит все изменения из основной базы данных в разборную на высокой скорости.

  Таким образом, клон актуален с точки зрения эксплуатационных данных.

• После завершения накрутки, как правило, проводится детальная проверка результата с привлечением технических специалистов и бизнес-пользователей Заказчика.

  И этот процесс может длиться довольно долго (несколько часов или дней).

  В рассматриваемой методике ограничения по времени практически нет, поэтому на проверку можно выделить столько времени, сколько необходимо.

• После завершения свертки и проверки все пользователи переходят на обрезанный клон, и с этого момента он становится основной базой.

  А исходная необрезанная база данных служит архивом исторических данных.

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

    Это обеспечивает дополнительную безопасность, ведь если «что-то пойдет не так», вы сможете быстро переключить пользователей обратно на неразрезанную базу данных, не потеряв введенные данные.

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

2. Возможность размещения складной базы данных в облаке MS Azure.



Таким образом, описанный метод свертки в базе данных клонов устраняет все узкие места.

Устраняет зависимость от технологического окна.

В клоне пакет никого не беспокоит и никто ему не мешает. Вы можете спокойно использовать максимум ресурсов клона, а также уделить достаточное внимание финальной проверке.

Осталось разобраться, какую технологию обмена можно использовать в этой схеме? Почему DBReplication?

Почему DBReplication?

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

• Совместим с платформой бизнес-приложений, база которой свернута.

Пример: Если свернуть базу данных 1С, то не каждая технология обмена совместима со структурой базы 1С, в частности, классическая Репликация транзакций MS не совместима, так как вносит изменения в структуру таблиц.

• Производительность.

  Технология обмена должна гарантированно справляться с потоком изменений, происходящим в рабочей базе данных во время свертывания.

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

Свертка будет длиться десятки часов, возможно, несколько дней, и может быть даже более одной итерации свертки.

За это время пользователи внесут огромные изменения.

Многие технологии обмена просто не справляются с этим.

И нужно не просто справиться, желательно справиться с резервом.

• Фундаментальная применимость к условиям задачи.

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

А именно: не забывайте, что наши данные в исходной базе и в клоне не равны друг другу! Этот факт автоматически отбрасывает целый класс мощных и производительных технологий, основанных на синхронизации журналов транзакций — Always On, доставке журналов, зеркалировании и т. д.

• Надежность и автономность работы.

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

• Высококачественные пользовательские интерфейсы для контроля и управления.

• Легко развернуть и настроить.

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

Однако технология DBReplication, безусловно, отвечает всем требованиям и обеспечивает успех проекта сокращения.

Отметим основные факторы, благодаря которым DBReplication достигает успеха в этой задаче:

• Очень высокая скорость передачи.

  Отметим некоторые особенности, обеспечивающие скорость:

  • DBReplication — репликация транзакций, каждое изменение начинает передаваться сразу после фиксации транзакции;
  • Во внутренней архитектуре транспортной подсистемы используются такие решения, как многопоточная параллельная обработка очередей, конвейерный подход, потоковое сжатие, пакетная обработка транзакций, использование Bulk Insert и другие.

• Транспорт реализован на базе служб Windows и оснащен множеством функций для обеспечения бесперебойной работы.

  К ним относятся: автоматическое восстановление обмена после прерываний связи, работа на слабых нестабильных каналах связи, автоматическая обработка конфликтов версий (для двустороннего обмена), автоматическая адаптация при изменении структуры таблиц бизнес-приложений и другие.

• Механизм гарантированной доставки данных.

  Строгое соблюдение транзакционной целостности и последовательности при передаче изменений.

• Не вносит изменения в структуру таблиц бизнес-приложения.

  Поэтому, в частности, его можно с успехом использовать при свертывании баз данных 1С.

• Развитый пользовательский интерфейс, позволяющий централизованно управлять системой обмена «из одного окна»; вся информация об услугах собирается и отображается в режиме онлайн.

• Простота развертывания и настройки.

• Адаптирован для платформы 1С.

  Пользователь работает не с таблицами, а со знакомыми объектами метаданных 1С.

• Любые версии MS SQL, начиная с 2005 года, от Standard до Enterprise, как локально развернутые, так и находящиеся в облаке MS Azure; С точки зрения Azure разрешены как хостинг виртуальных машин, так и варианты размещения базы данных SQL Azure, включая Управляемый экземпляр базы данных SQL Azure ( Управляемый экземпляр ).

• DBReplication — готовое надежное решение, проверенное на множестве проектов в самых разных условиях и задачах.

• Если DBREPLICATION используется в режиме одностороннего обмена, то направление обмена можно переключить.

• DBREPLICATION может работать в режиме двустороннего обмена, когда вы можете вводить/изменять данные одновременно во всех базах данных, участвующих в обмене.

  Количество оснований, которые могут быть включены в схему обмена, не ограничено.

Практический пример применения

При этом все больше увеличивается нагрузка: как транзакционная, так и аналитическая.

В конечном итоге сформировался ряд причин для проведения свертки базы.

Было решено сократить исторические данные до начала 2017 года.

Была выбрана описанная здесь методика с использованием DBReplication. Сам алгоритм свертки было решено реализовать преимущественно с использованием TSQL с небольшими включениями стандартных инструментов 1С.

Задача осложнялась тем, что не все объекты приложения (таблицы) могли быть свернуты к запланированному сроку, так как специфика бизнеса требовала, чтобы ряд крупнейших подсистем имел исторические данные в полном объеме на глубину до 5-ти.

7 лет. Поэтому с точки зрения объема базы данных эффект от свертки оказался не таким большим, как хотелось бы.

Был проведен предварительный анализ, который показал, что с учетом объективных ограничений будет урезано около 33% первоначального объема.

Но и это было оценено Заказчиком как хороший результат, ведь выигрыш идет не только в объеме базы данных как таковой, но и в производительности отдельных таблиц, а таблицы свернутых подсистем уменьшились в объеме более чем на 33 % - с 46% до 77% (в 2-3 раза).

Приведем подробно некоторые показатели и факты реального применения свертки.

Продолжительность прямой обработки данных составила около 12 часов.

Синхронизация накопленных изменений с помощью DBREPLICATION заняла около 1 часа.

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

Особо стоит отметить его продолжительность – этот процесс занял около 1 недели.

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

Все это время свернутая база автоматически синхронизировалась с текущей боевой базой с помощью DBREPLICATION. Проверка прошла успешно.

И пользователи были переведены на рухнувшую базу данных.

Предыдущая база данных переведена в статус архива, с доступом только для чтения.

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

Результаты проекта:

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

• Свертка завершена успешно:
  • Общий объем оперативной базы данных уменьшился на 33%.

    Большего эффекта по объёму базы данных добиться не удалось по объективным причинам, из-за ограничений на свёртку некоторых крупных подсистем.

  • Объем активно используемых таблиц свернутых подсистем уменьшился на 46-77% (в 2-3 раза).

Заключение

В рассматриваемой методике сокращения DBReplication полностью берет на себя одну из ключевых подзадач — синхронизацию базы данных.

В случае особо крупных баз данных к системе обмена предъявляются очень жесткие требования, и DBReplication полностью им удовлетворяет. Решает свою задачу надежно и эффективно, тем самым обеспечивая успех проекта в целом.

Для каких еще задач вы можете использовать DBREPLICATION?

Перечислим их в порядке ссылки.

• Резервное копирование базы данных и отказоустойчивость.

• Балансировка нагрузки: перераспределение ее между двумя или более синхронными экземплярами базы данных.

• Контролируемый переход на новые версии ПО (MS SQL, 1С), методика аналогична методике сокращения.

• Построение распределенной информационной системы с высокоскоростным обменом на базе DBReplication. В частности, замена существующей в компании технологии обмена на более производительную и эффективную – DBREPLICATION.

• Депутаты Обязали Работодателей Сообщать В Письменной Форме За Семь Дней О Причинах Отказа В Приеме На Работу

  19 Oct, 24

• 10 Самых Высокооплачиваемых Ит-Руководителей — Исследование Ap И Equilar

  19 Oct, 24

• Как Построить Беспилотный Гоночный Автомобиль: Истории Участников Bauman Racing Team

  19 Oct, 24

• Космические Масштабы

  19 Oct, 24

• Android Предложит Европейским Пользователям Выбор Браузера И Поисковой Системы

  19 Oct, 24

• Slideshare Отказался От Flash Для Html5

  19 Oct, 24

• О Двух Разных Способах Получения Денег

  19 Oct, 24

• Гендерные Различия На Поисковых Сайтах

  19 Oct, 24

• Анализатор Успеха Идей

  19 Oct, 24

• Реализация Алгоритма Евклида В Шекспире

  19 Oct, 24