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

Зачем переходить

Действительно, зачем переходить, если и так всё работает?

Этот вопрос сейчас выглядит скорее риторическим, хотя еще пару лет… Но текущие реалии в России диктуют свои сценарии организации ИТ-ландшафта на всех предприятиях, особенно на государственных. Кроме того, многие отрасли в России, и IT – не исключение, движутся семимильными шагами в сторону импортозамещения. Причём не на бумаге.

Вот три наиболее распространённые причины миграции баз данных на PostgreSQL (далее просто PG), которыми руководствуются компании.

  1. Законодательство РФ. Для многих предприятий перевод ИТ-системы на PG является процессом неизбежным, т.к. согласно Указу Президента РФ от 30.03.2022 № 166 с 1 января 2025 г. «органам государственной власти, заказчикам запрещается использовать иностранное ПО на принадлежащих им значимых объектах критической информационной инфраструктуры». А значит ИТ-подразделения этих государственных и окологосударственных организаций вынуждены озаботиться процессом миграции, чтобы уложиться в обозначенный срок.

  2. Геополитика и санкции. Введение санкций против России или отдельных компаний, а также уход с российского рынка многих зарубежных вендоров привели к тому, что и коммерческие организации стали всерьез рассматривать российский софт как альтернативу MSSQL или Oracle – отсутствие поддержки, отсутствие обновлений может привезти как к проблемам совместимости, так и к проблемам информационной безопасности из-за возможных уязвимостей в ПО. Если вопросы обновлений еще можно порешать, то отсутствие поддержки вендора может стать критичным.

  3. Стоимость владения. «Ванильная» PG вообще бесплатна и для некоторых коммерческих организаций этот вариант вполне возможен. Но мы его не будем рассматривать, т.к., во-первых, в единый реестр российских программ и баз данных «ванильный» PostgreSQL не может быть включен. А во-вторых, многие коммерческие сборки имеют сразу на борту наиболее оптимальные настройки и модули для повышения производительности 1С:Предприятие, что для больших систем очень важно. Ну и поддержку вендора никто не отменял. Поэтому рассматриваем какие-то коммерческие сборки, но с более гуманным ценником, нежели MS SQL.

Может быть как комбинация причин, так и доминирование только одной. Но это не важно. Важно, что тренд на миграцию виден уже невооруженным взглядом.

Нюансы перехода на PostgreSQL крупных баз данных

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

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

Важно понимать некоторые нюансы и обеспечить себе на любом этапе возможность анализа: что было сделано не так, почему не взлетает. И, в свою очередь, обеспечить гарантированный и поэтапный переход на новую архитектуру с PG. Кроме того, следует помнить, что систему нужно дальше сопровождать и решать задачи роста нагрузки –обеспечивать масштабируемость системы 1С.

1. Выбор платформы

Под платформой я имею в виду версию PG, версию Linux, архитектуру и аппаратные ресурсы.

Версии ПО обычно выбирается из соображений требований информационной безопасности предприятия, совместимости и возможности поддержки со стороны вендора.

Аппаратные ресурсы необходимо рассчитать для всех звеньев информационной системы 1С: сервер БД, сервер приложения 1С, сервер терминалов. Но можно сразу сказать, что они должны быть не хуже текущих ресурсов.

Для более точной оценки следует провести небольшое нагрузочное тестирование ряда основных операций в вашей ИС – в текущей и предполагаемой архитектуре. Причем, это не обязательно должен быть полноценный сервер. Можно в однопользовательском режиме снять нужные метрики и дальше экстраполировать их на требуемое количество пользователей/сеансов/документов и прочее. Таким образом, вы получите необходимые ресурсы будущих серверов в «идеальных» условиях – это отправная точка, ниже которой лучше не опускаться.

2. Настройка PG

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

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

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

3. Миграция без остановки системы

Сам подход к миграции платформы без остановки работы пользователей, а значит без простоев системы востребован и даже необходим, во-первых, для больших и очень больших систем, а во-вторых, для предприятий непрерывного цикла, где система работает 24/7 и нет даже намека на технологические окна. То есть, для них смена платформы (версии 1С, редакции СУБД, или целиком СУБД – не важно) очень рискованное мероприятие, которое грозит остановками работы информационной системы, а значит торможением бизнеса и убытками.

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

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

  1. Переход пользователей без остановки или с минимально-допустимой остановкой системы.

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

Для решения этих двух вопросов мы рекомендуем нашу технологию репликации DBReplication, которая обеспечивает обмен и синхронизацию данных между разными СУБД MS SQL и PG.

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

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

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

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

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

Как только пользователи переходят на новую архитектуру, репликация включается в обратную сторону:

Это позволит в случае форс-мажора переключить пользователей на старую архитектуру MS SQL до устранения сбоев в новой PG.

4.      Мониторинг PostgreSQL

Инструмент мониторинга производительности нужен, во-первых, на этапе функционального и нагрузочного тестирования, а во-вторых, уже в продуктиве. Обязательно! Must have! Как бы тщательно не проводилось тестирование, выбор настроек серверов и т.д., реальная пользовательская нагрузка может и будет создавать прецеденты, которые нужно расследовать, понимать причины и методы исправления. Понимать критичность просадки в тех или иных запросах. Например, вы запустили пользователей в новую систему и поняли, что длительность некоторых операций/запросов стала хуже. Хотя ничего такого на тестовом стенде не предвещало. Нужно оперативно понять количество таких запросов, разброс метрик, блокировочную картину, потребление ресурсов запросами, а не севером в целом. Одно дело если таких запросов единицы, а другое дело, если их сотни тысяч за день и что сразу критично для всех бизнес-процессов.

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

В качестве инструмента многие годы мы используем и рекомендуем к использованию мониторинг производительности Perfexpert.

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

5.  Прогноз роста нагрузки: горизонтальное масштабирование

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

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

На борту PG есть штатная кластеризация. Мы со своей стороны тоже предлагаем свои модули, адаптированные к системам на базе 1С:Предприятие, которые позволяют:

  • Оптимизировать «на лету» запросы от сервера 1С, которые нельзя оптимизировать средствами 1С.

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

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

Комментарии (17)


  1. mlnw
    08.04.2024 10:21

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


    1. VenbergV
      08.04.2024 10:21

      Субъективная метрика - размер премии за переход на PostgreSQL.
      Объективная метрика - хронометраж типовых действий каждого пользователя.
      Иногда эти метрики меняются местами. ;-)


    1. koloskovv Автор
      08.04.2024 10:21

      Оценивать в среднем по больнице тут будет неверно. Есть пример, когда в первое время после перехода значительно просела производительность одного-двух функциональных блоков, при этом остальной функционал системы прекрасно работал на том же уровне, что и до миграции. Но PG уже не такой черный ящик как MS SQL и там есть что подкрутить, дописать. В этом его большой плюс. Главное правильно увидеть причину.


      1. mlnw
        08.04.2024 10:21
        +1

        Ну то есть нет такого, что при переходе на постгре быстрее точно не будет, будет медленнее, вопрос лишь в том, насколько?


        1. koloskovv Автор
          08.04.2024 10:21

          Нужно рассматривать каждый блок или операцию в отдельности, а не всю систему в целом. При этом использовать метрики, позволяющие оценить отдельные операции, отдельные запросы, например, APDEX. И только на основе этого делать какие-то заключения. Субъективное мнение пользователей конечно тоже важно (это не сарказм), но вместе с тем я бы настоятельно рекомендовал сделать замеры по ключевым операциям ДО и ПОСЛЕ, чтобы было к чему апеллировать.


        1. 1CUnlimited
          08.04.2024 10:21

          Вот пример распространенной операции (перепроведение) Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С Postgres даже немного выигрывает, за счет большей утилизации проца


        1. oller
          08.04.2024 10:21

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

          Можно построить множество теорий, оправдать кеши и прочее, просчитать и т.д, но это синтетические тесты

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

          Стоит ли говорить, что у каждого своя нагрузка и свои числа "попугаев"


          1. mlnw
            08.04.2024 10:21

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


  1. mixsture
    08.04.2024 10:21
    +2

    Стоимость владения

    Поэтому рассматриваем какие-то коммерческие сборки, но с более гуманным ценником, нежели MS SQL

    И какая стоимость владения выходит? Я смотрю на лицензии pgPro, на обязательную доработку нагруженных баз, на снижение производительности (и как компенсацию - более мощное железо, наличие хороших dba). Точно ли выходит "гуманный" ценник? По моим ощущениям - если в ту же стоимость как с ms sql уложимся, то уже хорошо.


    1. koloskovv Автор
      08.04.2024 10:21

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


  1. firstmixon
    08.04.2024 10:21
    +1

    В статье не раскрыт процесс переноса бизнес логики, это вообще возможно или весь функционал на уровне СУБД предлагается переписывать под реальности PG?


    1. koloskovv Автор
      08.04.2024 10:21

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

      А так-то да. Всё что написано на уровне MS SQL нужно правильно сконвертировать на PG.


  1. 1CUnlimited
    08.04.2024 10:21
    +1

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

    1. Переход пользователей без остановки или с минимально-допустимой остановкой системы.

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

    Для решения этих двух вопросов мы рекомендуем нашу технологию репликации DBReplication, которая обеспечивает обмен и синхронизацию данных между разными СУБД MS SQL и PG.

    И как запускается этот процесс репликации? ведь для того чтобы запустить репликацию в базе которая 24х7 и

    и нет даже намека на технологические окна

    нужно получить копию в формате другой СУБД. Например - при переходе с MS SQL нужно сделать копию в формате Postgres.

    Допустим Вы быстро получили бэкап MS SQL до нужной точки восстановления или репликой в MS SQL .

    Если перекидывать это через Dt то я посчитал - у меня получилось где-то сутки для базы 1.7 терабайт в MS SQL, без пересчета итогов.

    Как великану из страны 1С пересесть на слона?

    т.е. отставание двое суток с накладными расходами. И сколько будет эта DBReplication догонять целевую копию? Если база реально большая то несколько перепроведений могут создать объем равный трети ИБ (это же изменения)

    Есть практические метрики - объем, сколько догоняли, сколько держали мораторий на изменение метаданных?

    P S Недавно заработал вариант через автономный сервер - тестировали?


    1. koloskovv Автор
      08.04.2024 10:21
      +1

      Если перекидывать это через Dt то я посчитал - у меня получилось где-то сутки для базы 1.7 терабайт в MS SQL, без пересчета итогов.

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

       

      Вопрос «сколько времени DBReplication будет догонять продуктивную базу» конечно правомерен. Тут четкие цифры дать трудно. Зависит от специфики и состава транзакций в конкретной ИС, от производительности оборудования на стороне сервера PG, где обрабатывается и применяется входящая очередь, от особенностей структуры некоторых таблиц 1С и их индексов и распределения данных по ним.

      Поэтому в разных случаях скорость прокачки одного и того же объёма изменений может отличаться довольно сильно - в 2-3 раза и более. Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.

      Таким образом, «держать мораторий» не требуется. Через несколько часов или дней (у кого как) базы будут полностью синхронизированы и можно просто переключить пользователей на другую БД.

       


      1. 1CUnlimited
        08.04.2024 10:21

        Здесь можем апеллировать только к конкретным примерам. Например, в нашей практике за 5 суток был синхронизирован объем изменений 1 ТБ.

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

        Как Вы синхронизируете Lob обьекты ? по ним же нет открытых форматов


        1. koloskovv Автор
          08.04.2024 10:21

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

          Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.


  1. NitroJunkie
    08.04.2024 10:21

    Самая веселая часть такого перехода, что в PostgreSQL очень тупой оптимизатор. Например он не поддерживает Predicate Push Down:

    https://habr.com/ru/companies/lsfusion/articles/463095/#jppd

    А MS SQL поддерживает (пусть и не до конца).

    При этом тот же 1С (в отличии скажем от lsFusion) Predicate Push Down тоже не поддерживает:

    https://habr.com/ru/companies/lsfusion/articles/468415/#opt

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

    И это только Predicate Push Down. У Postgres'а еще очень много веселых косяков с неправильной статистикой в подзапросах, с cross-column статистикой. У MS SQL все с этим куда получше. Конечно с этим можно было бы бороться, делая "материализацию подзапросов" на лету (как это делает тот же lsFusion), но 1С так тоже не умеет.

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