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

Введение

В настоящей статье рассматривается проблема свёртки особо крупных баз данных на платформе MS SQL Server. Описывается решение этой задачи с применением технологии репликации DBREPLICATION от компании Softpoint.

Проблематика

У каждого типа учетных систем могут начать проявляться и свои специфические особенности. Например, в системах на платформе 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 автоматически с высокой скоростью передаёт все изменения из основной БД в сворачиваемую. Таким образом, клон находится в актуальном состоянии с точки зрения оперативных данных.
• После завершения свёртки, как правило, проводится детальная верификация результата с привлечением технических специалистов и бизнес-пользователей Заказчика. И этот процесс может продлиться достаточно долго (несколько часов или дней). В рассматриваемой методологии ограничения по времени практически нет, поэтому на верификацию можно выделить столько времени, сколько потребуется.
• После завершения свёртки и верификации все пользователи переключаются в обрезанный клон, и с этого момента он становится основной базой. А исходная необрезанная база служит архивом исторических данных.
  
  • Дополнительным преимуществом является возможность переключить репликацию в обратную сторону в момент перехода пользователей в свёрнутую базу. Это дает дополнительную безопасность, т.к., если «что-то пойдет не так», можно оперативно переключить пользователей обратно в необрезанную БД без потери введенных данных.
• Если есть необходимость поддерживать архивную БД в актуальном состоянии, можно переключить репликацию в обратную сторону, и передавать изменения уже из свёрнутой БД в архивную.

Рис.1. Принципиальная схема обрезки БД с применением технологии DBREPLICATION. 

Рис.2. Вариант с размещением сворачиваемой бд в облаке MS Azure.

Таким образом, описанная методика свёртки в базе-клоне расшивает все узкие места. Устраняет зависимость от технологического окна. В клоне свёртка никому не мешает, и ей никто не мешает. Можно спокойно задействовать максимум ресурсов клона, а также уделить достаточное внимание финальной верификации.

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

Почему именно DBReplication?

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

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

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

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

Пояснение: в этой статье мы подразумеваем прежде всего высоконагруженные базы с большой интенсивностью изменения данных. Свёртка будет длиться десятки часов, возможно несколько дней, возможно, даже будет не одна итерация свёртки. За такое время пользователи внесут огромные изменения. Многие технологии обмена просто не справиться. А нужно не просто справиться, желательно справиться с запасом.

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

Пояснение: возможно, этот пункт выглядит самоочевидным, но всё же выделим и его. А именно: не забываем о том, что у нас данные в исходной базе и в клоне не равны друг другу! Этот факт автоматически отметает целый класс мощных и производительных технологий, основанных на синхронизации журналов транзакций — always on, log shipping, mirroring и др.

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

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

Без этих качеств технология обмена грозит превратиться из спасительного ключевого элемента методики в её «слабое звено», привносит серьёзные риски и угрожает всему проекту. И тогда исходная идея теряет смысл.

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

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

• Очень высокая скорость обмена. Отметим некоторые особенности, обеспечивающие скорость:
  
  • DBReplication — это транзакционная репликация, каждое изменение начинает передаваться сразу же после фиксации транзакции;
  • Во внутренней архитектуре транспортной подсистемы применяются такие решения как многопоточная параллельная обработка очередей, конвейерный подход, потоковое сжатие, пакетная обработка транзакций, использование Bulk Insert и другие.
• Транспорт реализован на основе служб Windows, оснащен множеством функций обеспечения бесперебойности работы. К их числу относятся: автоматическое восстановление обмена после обрывов связи, работа на слабых неустойчивых каналах связи, автоматическая обработка конфликтов версионности (для двустороннего обмена), автоматическая адаптация в случае изменений в структуре таблиц бизнес-приложения, и другие.
• Механизм гарантированной доставки данных. Строгое соблюдение транзакционной целостности и последовательности при передаче изменений.
• Не вносит изменений в структуру таблиц бизнес-приложения. Поэтому, в частности, может успешно применяться при свёртке баз 1С.
• Развитый пользовательский интерфейс, позволяющий централизованно управлять системой обмена «из одного окна», вся служебная информация собирается и отображается онлайн.
• Простота разворачивания и настройки.
• Адаптировано под платформу 1С. Пользователь работает не с таблицами, а с привычными объектами метаданных 1С.
• Любые версии MS SQL, начиная с 2005, от Standard до Enterprise, как локально развёрнутые, так и находящиеся в облаке MS Azure; с точки зрения Azure допускается как размещение на виртуальных машинах, так и варианты размещения Azure SQL DB, в том числе и управляемый экземпляр базы данных SQL Azure (Managed Instance).
• DBReplication – это уже готовое надёжное решение, проверенное множеством проектов в самых разных условиях и задачах.
• Если DBREPLICATION используется в режиме одностороннего обмена, то направление обмена можно переключать.

Дополнительно отметим еще одну важнейшую особенность:

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

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

В крупной российской компании имеется прикладная учетная система на платформе 1С 8 + MS SQL Server. Основная оперативная база уже давно перешагнула через 2 терабайта и продолжает расти. Одновременно всё больше увеличивается нагрузка: как транзакционная, так и аналитическая. В конечном итоге сформировался ряд оснований к тому, чтобы выполнить свёртку базы. Было решено обрезать исторические данные по начало 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 им полностью удовлетворяет. Решает свою задачу надёжно и эффективно, обеспечивая тем самым успех проекта в целом.  

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

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

• Резервирование и отказоустойчивость баз данных.
• Балансировка нагрузки: перераспределение ее между 2мя и более синхронными экземплярами бд.
• Контролируемый переход на новые версии ПО (MS SQL, 1C), методика похожа на методику свёртки.
• Построение распределенной информационной системы с высокоскоростным обменом на основе DBReplication. В частности, замена имеющейся компании технологии обмена на более производительную и эффективную — DBREPLICATION.