Привет! Я Владимир Колосков, ведущий разработчик в Softpoint. Сегодня я хочу поделиться своими соображениями по поводу миграции больших и огромных БД с MSSQL Server на PostgreSQL: зачем это делать, стоит ли это делать сейчас и как я вижу такой переход.

Сразу пару слов про «Почему с SQL Server?» и «Почему на PostgreSQL?».

Самая распространенная в России платформа для бизнес-систем – это 1С:Предприятие 8. Причем в компаниях любого размера. Исторически платформа работала всегда с MS SQL Server. Есть, конечно, инсталляции и на других СУБД, но их крайне мало в общей массе. А связке 1С+MSSQL Server уже не один десяток лет, она отлажена, понятна и более-менее предсказуема. На основании собственного опыта и опыта Softpoint могу уверенно утверждать, что если в компании есть крупная ИТ-система, то она почти всегда на MSSQL Server (даже если это не 1С). И чем больше база данных, тем сложнее компании решиться на миграцию, т.к. это длительный процесс, с серьезным функциональным и нагрузочным тестированием, не укладывающийся ни в одно технологическое окно. А перспектива простоев ИТ-систем в бизнесе – такое себе.

Что касается вопроса «Почему на PostgreSQL?», то на данный момент других вариантов просто нет, ниже по тексту я разверну это утверждение.

Одна из целей статьи – показать, что использование гетерогенной информационной системы как инструмента перехода с одной СУБД на другую – это очень оправданный шаг как с экономической точки зрения, так и с учетом возможных рисков. Это позволит, с одной стороны, пользоваться и хранить данные в привычной СУБД, которая годами и десятилетиями оттачивалась крупным вендором, и которая имеет минимальные нарекания в производительности, в поддержке, в ошибках. А, с другой стороны, параллельно пользоваться СУБД с открытым исходным кодом, анализировать ее поведение при таком же профиле нагрузки, плавно увеличивать нагрузку, проводить тестирование столько времени, сколько нужно.

Зачем переходить на PostgreSQL и какие риски, если оставить всё как есть

Я вижу две причины, по которым многим организациям следует взять курс на миграцию СУБД с MS SQL Server на PostgreSQL: законодательство и уход иностранных вендоров.

Причина 1: Законодательство

Эта причина объективная. Особенно для госсектора.

В июне 2015 года был принят закон о создании реестра отечественного ПО, и осенью того же года вышло постановление о запрете закупки ПО из иностранных государств для госзаказчиков. Это был не полный запрет, а скорее, ограничение, к которому прилагался порядок подготовки обоснования невозможности соблюдения запрета. Чем все и пользовались. Иногда действительно обоснованно, т.к. аналогов среди отечественного ПО просто не было. Но, в целом, с 2016 года государство взяло курс на импортозамещение. А в марте 2022 года вышел указ Президента РФ, где дедлайны стали вполне себе четкими и обозримыми – с 1 января 2025 госсектору запрещается использование иностранного ПО на объектах критической инфраструктуры. Кстати, как раз с прошлого года у многих наших клиентов появился активный, а не гипотетический, интерес к процессу миграции с MSSQL Server на PostgreSQL.

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

Причина 2: Уход иностранных вендоров с рынка

В 2022 г. IT-подразделения российских компаний оказались в ситуации, когда иностранные вендоры ПО перестали оказывать поддержку, продавать лицензии, закрыли доступ к обновлениям. Таким образом, даже если компания не аффилирована с государством, и на нее не распространяются ограничения на закупку иностранного ПО, сделать это официальным путем становится с каждым разом всё сложнее. Конечно, в арсенале остаются методы получения софта, распространенные в 90-х и 00-х годах, но здесь не про это. Чем крупнее компания, тем больше у нее пользователей и тем больше вероятность словить очередную порцию исключительных ситуаций, которые можно решить, зачастую, только с помощью вендора. Естественно, поддержка вендора нужна далеко не всегда, но, учитывая, что любой продукт вендора – это черный ящик, порешать некоторые проблемы без его участия практически невозможно.

В качестве спойлера. В одной из следующих статей будет разбираться как раз такой пример, где ошибка в СУБД (не хочется думать, что это фича или целенаправленное вредительство) появилась в обновленной версии MSSQL Server и в определенных условиях замедляет работу пользователей.

 Альтернатива – ничего не трогать, оставить все как есть. Оно ж работает.

Компании будут продолжать работать на том же самом софте, потому что у них просто имеется такая возможность. Если она не относится к госсектору, и бизнес устраивает текущая инфраструктура, то зачем что-то менять? Ведь переход на новую СУБД, новую архитектуру – это очень высокорискованное мероприятие.

В любом случае все «За» и «Против» миграции каждый составляет для себя сам. Я лишь хочу сказать, что сейчас все обстоятельства подталкивают организации всё чаще рассматривать импортозамещение ПО, в частности, СУБД, как основной сценарий продолжения функционирования ИТ-систем. И это совсем неплохо. Это развитие и конкуренция )).

Сценарии перехода на другие СУБД

Наиболее вероятным кандидатом сейчас является PostgreSQL. Это достаточно популярный и развивающийся продукт с открытым исходным кодом и множеством сборок, в том числе и отечественных. И в этом огромный плюс. Но необходимо отметить, что MSSQL Server за 20 лет прошел огромную трансформацию и стала очень хорошей СУБД. И во многом сравнение PostgreSQL и MSSQL будут не в пользу первой. Поэтому гарантировать работу вашей большой/высоконагруженной/с множеством интеграций системы на PostgreSQL хотя бы с таким же уровнем комфорта как на MS SQL Server я бы не стал. Сразу не стал. К сожалению, без перехода и проверки на реальной нагрузке не обойтись.

Какие существуют выходы из сложившейся ситуации?

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

Далее не будет какой-то пошаговой инструкции. Чудес не бывает, это всё сложные и длительные проекты, связанные со множеством рисков. Я покажу наш подход, сформировавшийся за многие годы и основанный на принципах репликации баз данных. Репликация не штатная, а собственный запатентованный продукт DB Replication с отдельным сервером дистрибуции, отдельной служебной базой данных, агентами, службами, утилитами настройки для осуществления сложной логики обмена.

Методика и продукт постепенно совершенствовалась и теперь позволяют решать задачи обмена и синхронизации данных не только в уже достаточно «простых» проектах типа «MS SQL Server v1 – MS SQL Server v2», но и «MS SQL Server – PostgreSQL».

Хочу заметить, что наш подход в корне отличается от существующих сценариев, рекомендуемых 1С: «миграция через выгрузку базы в dt-файл» и «миграция при помощи планов обмена 1С». В платформе 8.3.23 планируется еще третий сценарий – конвертация при помощи утилиты ibcmd сразу из одной СУБД в другую, минуя dt-файл – это определенно более интересный и удобный сценарий, предполагающий заметно ускорить процесс и снизить количество ошибок конвертации. Но это в будущем. А пока в случае с dt-файлом потребуется остановка работы продуктивной базы, и не факт, что терабайтная база удачно выгрузится и/или загрузится. А в случае с планом обмена, во-первых, возникнет значительная дополнительная нагрузка на систему (не всегда есть возможность проводить выгрузку в период низкой активности пользователей) и дополнительные блокировки, мешающие пользователям, во-вторых, требуются значительные ресурсы разработчиков для реализации и отладки этого обмена, в-третьих, в системах с высоким объемом изменений в единицу времени возможна проблема пропускной способности планов обмена (справится ли он вообще с синхронизацией оперативных изменений?), в-четвертых, это долго. И после перехода на новую СУБД исправить обнаруженные вдруг ошибки может быть довольно сложно, так как ВСЁ – пользователи работают в новой базе уже Х дней, обратного пути нет, все исправления – «на горячую».

Данная методика позволяет конвертировать базу любого размера в формат PostgreSQL без прерывания работы пользователей и без значимой дополнительной нагрузки на ресурсы сервера!

Ниже я описал два общих подхода использования репликации для создания гетерогенной системы (= для миграции) со своими особенностями.

Подход 1. Односторонняя репликация

Основная идея – это онлайн асинхронная репликация данных из MSSQL в PostgeSQL, при которой первоначальный перенос данных может занимать сколь угодно долгое время. Но! Все инкрементальные изменения, возникшие за период переноса, потом докачаются из очереди, и система репликации переходит в режим работы online. То есть достигается ситуация, когда исторические данные в базах MSSQL и PostgeSQL идентичны, а оперативные изменения синхроннизируются в режиме реального времени. Сам же переход потом будет выполнен практически моментально – пользователи переключатся с одной БД на другую.

При этом на целевой БД в PostgreSQL (а её копий можно сделать сколь угодно много) можно заранее отрабатывать проверку функциональности и производительности, имея возможность в полуавтоматическом режиме сравнивать результаты работы одного и того же функционала и сравнивать результаты производительности (например, по APDEX).

На рисунке схематически представлен процесс конвертации базы данных в формат PostgreSQL с применением DB Replication:

План перехода выглядит следующим образом:

1. К платформе DB Replication подключаются две базы: рабочая БД MS SQL и целевая база данных в формате PostgreSQL, данные в которой отсутствуют (загружается CF‑файл).

2. Между рабочей MS SQL базой и целевой PostgreSQL базой посредством DB Replication настраивается однонаправленный обмен данными. Это важная часть проекта, которая подразумевает:

   • Развертывание отдельного сервера дистрибуции.

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

   • Установку и настройку транспортных агентов (служб) репликации для исходной и целевой баз.

   • Настройку мэппинга по таблицам с учетом особенностей структуры БД и соответствия типов данных в различных СУБД.

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

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

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

   • По мере появления пакетов данных в исходящей очереди базы MS SQL транспортная подсистема DB Replication (агенты) доставляет их во входящую очередь репликации целевой базы и далее применяет эти данные непосредственно к таблицам 1С в формате PostgreSQL.  Таким образом база на PostgreSQL постепенно наполняется данными с учетом всех особенностей совместимости MS SQL и PostgreSQL.

   • Одновременно с передачей исторических данных DB Replication передаёт и все оперативные изменения, которые формируются пользователями в базе MS SQL.

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

5. Целевая база в формате PostgreSQL передаётся пользователям на проверку качества данных. При этом производить такую проверку можно сколь угодно долго, поскольку всё это время DB Replication продолжает фиксировать изменения данных базы MS SQL и доставлять их в базу PostgreSQL. То есть в течение всего периода проверки база PostgreSQL будет поддерживаться в консистентном и актуальном состоянии.

6. По завершении процедуры верификации данных PostgreSQL база вводится в промышленную эксплуатацию:

   • Выполняются работы, подготавливающие БД PostgreSQL к переключению (настройки фоновых заданий, интеграций с внешними системами, учетные записи, ярлыки для запуска и т.д. - всё прочее, что необходимо для полноценного функционирования информационной системы);

   • Весь массив пользователей 1С переключается в базу PostgreSQL.

Основные плюсы и возможности:

1. Работа пользователей в продуктивной системе на MS SQL не останавливается. Связанная с переносом данных дополнительная нагрузка на БД и сервер не значительна (в пиках - до 1,5-2 ядер CPU).

2. Постоянно работающая репликация позволяет тестировать перенесенную БД на PostgresSQL сколь угодно долго и перейти на новую СУБД в нужный момент. То есть подход с онлайн репликацией позволяет тестировать функционал на реальных данных, правильно подобранными фокус-группами, тщательно и по выверенным сценариям.

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

Основные риски:

1. Основной риск: тестирование, особенно нагрузочное, скорее всего будет не полным. А значит есть большая вероятность, что, казалось бы, обычная процедура, которая на раз-два отрабатывала на MS SQL может «уронить» весь сервер PostgreSQL или выполняться на нем непозволительно долго. И я встречался с такими примерами.

2. Можно с уверенностью утверждать, что пока оптимизатор запросов PostgreSQL проигрывает MSSQL. А оптимизацию не всегда можно выполнить быстро, что приведет к простоям и снижению качества работы ИТ-системы. Обратный откат на MSSQL приведет не просто к простоям, а еще и к потере данных (придётся заново вводить данные в MSSQL за тот период времени, когда пользователи работали в PostgreSQL).

Подход 2. Двусторонняя репликация

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

Двустороння репликация с трансформацией MSSQL – PostgreSQL позволяет иметь online копию данных в двух СУБД одновременно.

Схема очень похожа на схему из подхода 1, но обмен двусторонний:

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

В этом подходе можно выделить две ветки:

Сценарий внедрения 1. Единовременное переключение всех пользователей на новую СУБД с возможностью безболезненного отката на старую СУБД в случае сбоев.

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

Плюсы и возможности:

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

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

Риски, ограничения:

1)  Сохраняются риски, связанные с производительностью на стороне PostgreSQL, когда туда одномоментно переключаются все пользователи. В случае реализации этих рисков, переходы пользователей туда-сюда существенно увеличивают срок и стоимость проекта и несут определенный стресс для пользователей.

Сценарий внедрения 2. Постепенный перевод пользователей (группами, подразделениями или еще как-то) на новую СУБД.

В этом случае, при правильном проектировании, открываются самые большие перспективы для контролируемого и безопасного перехода. Часть пользователей переводится и начинает работать уже на новой СУБД, а часть продолжает работать на старой. И постепенно пропорция будет смещаться в пользу пользователей на PostgreSQL.

Основные плюсы и возможности:

1)  Управляемый переход – отсутствие взрывного характера проблем производительности или функциональности в БД PostgreSQL.

2)  Постепенное увеличение нагрузки на СУБД PostgreSQL по мере увеличения количества пользователей, а значит контролируемое потребление ресурсов сервера.

Основные риски, ограничения:

1)  На каждом этапе перевода пользователей в PostgreSQL требуется очень точно планировать распределение пользователей между базами MSSQL и PostgreSQL таким образом, чтобы минимизировать вероятность конфликтов, характерных для распределённых ИС. Имеются в виду ситуации, когда в двух БД одновременно меняются одни и те же данные, например, один и тот же документ проводится или элемент справочника записывается. Безошибочно спланировать такое распределение, а потом его выдерживать на практике может быть довольно непростой задачей.

2)  При одновременной работе пользователей в двух СУБД необходимо реализовывать разрешение конфликтов при обмене данными, как в прочем, для любой распределенной БД.

Заключение

В статье я описал придуманную нами концепцию миграции с MS SQL на PostgreSQL, она предполагает использование нашего инструментария DB Replication, который мы специально адаптировали под эту задачу. История инструмента насчитывает более десятка лет, он постоянно развивается, и сейчас с помощью него можно уже строить не только гомогенные системы (для задач свёртки баз, горячей резервной копии, построения распределенной системы и проч.), но уже и гетерогенные системы. И самая первая задача, которая решается нами в гетерогенной архитектуре – это конвертация и перенос данных из MS SQL базы в PostgreSQL базу без остановки работы пользователей.

Если вам интересно более детально погрузиться в процессы смены СУБД или рассмотреть реальные примеры таких переходов, то в одной из следующих публикаций мы обязательно это сделаем.