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

Меня зовут Алексей Чивтаев, я из компании Софтпоинт.

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

Бегло перечислю задачи, о которых идет речь. Это:

• обрезка исторических данных;

• оптимизация парка тестовых копий баз данных;

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

• и некоторые другие – все перечислять не буду.

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

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

• система обычно высоконагруженная;

• базы – терабайтные;

• работа бизнеса 24 на 7 или близко к тому, поэтому технологических окон нет;

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

Такая высокая нагрузка вызывает тяжелый клубок проблем.

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

• Как минимум, система обмена должна быть технически совместима с прикладной платформой (с Axapta или с 1С – мы в основном говорим об 1С). Например, стандартная репликация Microsoft (транзакционная или merge-репликация) в принципе не совместима с платформой 1С, поскольку меняет структуру прикладных таблиц и добавляет туда новые колонки.

• Система обмена в контексте наших задач должна не только позволять читать данные в узлах распределенной системы, но и позволять вносить изменения во всех узлах системы. Это важно. Например, такой замечательный инструмент, как Microsoft Always On, этому критерию не удовлетворяет, поскольку Always On и его родственники log shipping, mirroring, основаны на трансляции журнала транзакций, а эта технология подразумевает, что вторичные ноды могут быть только строго на чтение.

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

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

• Не должна создавать избыточных блокировок, чтобы не мешать пользователям.

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

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

• Можно какое-то коммерческое ПО найти – купить, настроить.

• Можно попытаться разработать какую-то систему для своих целей самостоятельно – средствами 1С или средствами SQL, если на это конечно хватает ресурсов, времени и компетенции команды.

В общем, выходы есть.

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

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

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

Технология DB Replication

Итак, в своем рассказе я буду подразумевать технологию DB Replication.

Это высокоскоростной обмен данными для гомогенных систем на MS SQL Server.

DB Replication – это разработка нашей компании, она запатентована и входит в реестр российского программного обеспечения.

Три ключевых особенности технологии.

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

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

• Третье – при внедрении DB Replication не требует изменения таблиц прикладной платформы. Если речь об 1С, значит, не требуется изменение конфигурации 1С. Логика прикладной системы остается без изменений, пользователи работают как обычно и внедрение DB Replication проходит незаметно для пользователей.

Основной принцип работы

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

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

• Москва – верхний большой прямоугольник;

• и Омск – нижний большой прямоугольник.

Допустим, в Москве пользователи вносят нового контрагента «Иваныч». Записали.

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

То есть у нас в «Очереди репликации» появляются все значения всех колонок контрагента «Иваныч».

Специальная транспортная служба, называемая «Агент репликации», контролирует эту очередь и как только видит, что там что-то появилось, прочитывает это, упаковывает и передает на «Дистрибутор» – это такой служебный сервер, который разворачивается при внедрении репликации.

На «Дистрибуторе» пакет подвергается проверке на возможные конфликты (если это двусторонний обмен) и к нему применяются правила фильтрации. В данном случае согласно правилам пакет доставляется в Омск и записывается там в таблицу «Очереди репликации» в качестве входящего сообщения.

В «Очереди репликации» этот пакет подхватывает местный агент, распаковывает его и применяет непосредственно уже к таблицам 1С.

На этом жизненный цикл транзакции завершен, базы синхронизированы – «Иваныч» появился в Омске.

Такая транзакция в нормальных условиях доставляется примерно за 5 секунд.

Особенности технологии

Еще немного о других особенностях технологии.

• DB Replication, по своей технологической сути – это транзакционная репликация, основанная на триггерах. Основной единицей передаваемой информации является транзакция – то есть вся совокупность изменений, которые были сделаны в единой транзакции.

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

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

• Применяется потоковое сжатие данных для экономии трафика, передаваемого по сети. Например, типичный 1С-трафик сжимается примерно в 10-70 раз, может быть больше. Естественно, тут все от специфики конкретных данных очень сильно зависит.

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

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

• Очень много оптимизации сделано для работы на слабых неустойчивых каналах связи. В частности технология успешно работает на спутниковом интернете. Такое нередко бывает в каких-то периферийных регионах, на производственных участках, где-нибудь далеко в тайге или в тундре, где трудятся наши сырьевики. Интернет неустойчивый, тарелка пропала, много часов нет связи. Очереди репликации накапливаются, как только связь появляется, пусть даже на несколько секунд, транспорт автоматически через эту связь прокачивает все, что успевает.

• В составе технологии также имеется очень мощный инструментарий для фильтрации данных. Он позволяет настраивать весьма изощренные схемы маршрутизации данных. В том числе есть возможность настраивать логику назначения маршрута каждой транзакции индивидуально в зависимости от содержимого этой транзакции. Т.е. назначать маршрут можно интеллектуально – в зависимости от прикладной логики того, что в транзакции есть. Можно сказать, что используется лозунг: «Каждому пакету – свой маршрут!».

• В рамках контура обмена можно комбинировать любые версии MS SQL Server. Например, в одном узле у нас может быть 2005 SQL Server Standard Edition, а в другом узле – SQL Server 2017 Enterprise Edition. Это очень удобно при внедрении, поскольку не требует избыточных инфраструктурных изменений и позволяет обойтись уже имеющимися лицензиями. Не докупать дополнительные ПО, а экономить на лицензиях.

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

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

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

• Про триггеры я уже сказал.

• И в недалеком будущем мы планируем научить репликацию передавать данные между однотипными базами из MS SQL в PostgreSQL и обратно.

Обрезка исторических данных (свёртка)

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

Первая задача – это обрезка больших баз данных.

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

С ростом базы такой клубок проблем постепенно проявляется все сильнее. И в какой-то момент уже нужно что-то делать. Варианты – это:

• тем или иным образом вертикально масштабироваться, например, докупать желез;

• или уходить в облака.

У каждого из этих вариантов есть свои плюсы, есть свои минусы.

• На облака не каждая компания готова в принципе – и по стоимости, и по каким-то идеологическим соображениям, и соображениям безопасности.

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

Допустим, мы подумали-подумали и решили, что вертикальное масштабирование – это не наш вариант. Решили, что пойдем по альтернативному пути и порежем рабочую базу – свернем в ней исторические данные.

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

• Бизнес работает 24 на 7, простой не допустим, технологических окон нет,

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

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

• Она будет создавать кучу блокировок – в общем, систему это положит, а мы этого допустить не можем.

Поэтому выводы из таких соображений:

• резать боевую рабочую базу нельзя;

• но можно резать копию;

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

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

Вот так простенько выглядит архитектура этого решения.

• Создаем копию рабочей базы данных,

• настраиваем односторонний обмен из рабочей в копию

• и в копии запускаем алгоритм обрезки и проверки данных.

Ключевая фишка в том, что:

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

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

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

• Такая методика сводит все риски обрезки фактически к нулю.

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

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

Следующая задача — это содержание парка тестовых копий.

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

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

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

Но есть альтернатива:

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

• В этой копии запускаем там вот ту самую грубую обрезку.

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

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

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

• Во-вторых, они за счет репликации синхронны по оперативным данным, поэтому данные не устаревают.

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

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

Следующий класс задач – это балансировка нагрузки.

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

Проблематику очень коротко напомню:

• У нас имеется очень нагруженный SQL-сервер, на нем крутится какая-то очень крупная база данных 1С.

• Обычно в таких обстоятельствах высока доля OLAP-нагрузки, то есть аналитические выборки какие-то или тяжелые отчеты – такая нагрузка зачастую десятками процентов измеряется. И неплохо было бы эту нагрузку как вариант куда-то отбалансировать.

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

Что же делать?

• у нас есть вариант вертикального масштабирования;

• и есть вариант горизонтального масштабирования.

Посмотрим на них чуть ближе.

С вертикальным масштабированием в принципе все понятно – это докупка железа.

Какие здесь особенности:

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

• Во-вторых, чтобы раскрыть весь потенциал железа, мы неизбежно вынуждены использовать лицензию типа Enterprise Edition, а это большая цена.

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

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

В чем плюсы такого подхода?

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

• Кроме того, поскольку оборудование уже такое послабее, можно обойтись лицензиями Standard Edition, а это тоже экономия по цене.

С помощью такого кластера можно:

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

• Также в балансировочные экземпляры можно вынести нагрузку не только на чтение, но и на чтение и запись. Например, можно вынести какой-то очень тяжелый изолированный функциональный блок прикладной системы, такой как МСФО, например. Мы выносили – очень эффективное решение получилось.

• И еще одна задача – это обслуживание индексов и статистики.

Расскажу подробнее по каждой из этих задач.

Рассмотрим технологию балансировки нагрузки с выносом данных в отдельную базу-копию на чтение и на чтение и запись:

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

• С того момента, как копия развернута, пользователи уже за аналитикой, за отчетами идут в эту самую копию. Тем самым OLAP-нагрузка на значительной степени из основного сервера уходит, остается только OLTP, и основной сервер разгружен. Что и требовалось доказать.

• То же самое с блоком МСФО, который я упоминал. Только в этом случае пользователи ходят в копию не за отчетами, а в принципе – пользователи, работающие с блоком МСФО, во всем, что касается формирования проводок МСФО-шных, отчетов и тому подобное, работают в копии. А репликация доставляет в эту копию первичку.

Обслуживание индексов и статистик

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

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

• бизнес 24 на 7, тех окна нет;

• на сервере постоянно высокая нагрузка;

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

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

Нужно как-то решать эту проблему.

Одним из решений тоже является кластеризация.

С помощью репликации настраиваем копию, репликация односторонняя:

• в одной базе работают пользователи;

• в другой производится обслуживание индексов.

Эти два процесса никак друг другу не мешают.

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

И вот так циклично можно этот процесс туда-сюда повторять сколько угодно раз.

Безопасная миграция баз данных

Следующий интересный сценарий – это безопасный переход на новые версии SQL сервера.

Проблема в том, что если нам нужно перейти с какого-то сравнительно старого MS SQL Server (например, с 2008 или 2012) на MS SQL Server 2017, возникают существенные риски, связанные с возможной потерей производительности. Они связаны с тем, что база данных у нас огромная, нагрузка высокая, запаса прочности нет, права на ошибку нет.

Брать эти риски на себя никто не хочет, и их как-то нужно купировать.

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

Я уже говорил, что мы можем в одном контуре обмена комбинировать различные версии SQL-сервера, поэтому в данном случае мы:

• разворачиваем целевой SQL сервер, настраиваем репликацию и после всех подготовительных мероприятий переключаем туда пользователей;

• репликацию перещелкиваем в обратную сторону;

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

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

И последняя задача – несколько слов о том, как перейти на PostgreSQL.

Эта задача в последнее время становится для многих компаний всё более насущной.

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

Здесь тоже можно применить кластеризацию с помощью системы обмена:

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

• репликацию перещелкиваем в обратную сторону;

• в PostgreSQL контролируем работу – если что-то пошло не так, всегда можно вернуться обратно на Microsoft SQL Server.

В недалекой перспективе мы планируем научить репликацию таким фокусам, чтобы она могла передавать данные из MS SQL Server в PostgreSQL и обратно.

Благодаря этому:

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

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

• Ну а в перспективе её же можно будет использовать уже в среде непосредственно PostgreSQL для горизонтального масштабирования, примерно по той схеме, как я рассказывал ранее для MS SQL.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.