• Каких размеров базу возможно выгрузить в dt?

• Лучшее время для перехода на Postgres в Вашем календаре.

• Как ускорить процесс конвертации.

  • Оборудование — диски.

  • Оборудование — сеть.

  • Оборудование и виртуализация.

  • Настройка СУБД.

  • Настраиваем кластер 1С и очищаем итоги.

  • Пересчет итогов в Postgres и важность AUTOVACUUM.

• Если 1С сделает быстрее, значит это кому‑то нужно?

• P.S. Миграция между информационными базами без выгрузки в dt-файл

Каких размеров базу возможно выгрузить в dt?

Со стороны миграция базы 1С (MS SQL\Oracle\Db2) на Postgres выглядит так

«Тут нужно поблагодарить платформу 1С, потому что для прикладного разработчика совершенно не важно, с какой базой он работает. Все эти вопросы решаются на уровне платформы. Миграция выглядит так — выгрузил базу в dt‑ник, загрузил его обратно в другую базу. Вот и все.»

Из интервью Иван Панченко: «PostgreSQL совершенствуется, и 1С тоже идет навстречу» (infostart.ru)

Все так, да не так — ведь я не враг самообмана, не обрывался б он так рано. Вопросов много:

• Какой объем базы поместится в Dt? 2, 5, 10 терабайт?

• Сколько времени она будет выгружаться\ и загружаться? Хватит ли нам выходных или технологического окна?

Формально размер Dt файла ограничен только очень большим числом 2 в 64 степени и зависит от файловой системы (NTFS,exFAT) как в Unix так и в Windows File System Functionality Comparison — Win32 apps | Microsoft Learn. Для 1С это почти бесконечность, в смысле — Вы дождетесь следующей версии платформы пока процесс выгрузки такого объема завершится.

В данной статье описан конкретный случай миграции более скромной базы объемом 1.7 терабайт c MS SQL 2019 на Postgres 15.2 — не самая большая, есть и больше на 5 терабайт, но для прогнозирования длительности процесса и этого достаточно. Размер приведен с учетом данных в таблицах, индексами и определенной фрагментацией. База была определенным образом подготовлена, чтобы сократить выгружаемый объем данных, но об этом ниже.

Когда мы говорим об объеме базы данных нужно понимать, что индексы могут занимать примерно столько же сколько и таблицы базы данных, а в зависимости от фрагментации и гораздо больше — реальность достаточно посмотреть в отчете SQL Server management studio в полях Data\Indexes пример тут 1С БодиПозитив / Хабр (habr.com) . Помните об этом, когда Вас поражает объем базы в компании N. Конечно, индексы не выгружаются в Dt файл, но при загрузке из Dt они перестраиваются на что тратится время.

Сколько реально занимает база в MS SQL можно посмотреть запросом (поскольку размер данных идет в страницах по 8к то size * 8/1024 = size /128).

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB, CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS SpaceUsedInMB

FROM sys.database_files;

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

Лучшее время для перехода на Postgres в Вашем календаре

Итак — выгрузка в Dt файл заняла 14 часов. Сам Dt файл занимает 55 Гигабайт. Кстати, давайте мерятся размерами Dt файла? Так хотябы честнее и без фрагментации.

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

Внимательный читатель задаст вопрос ‑а почему сразу не выгрузил 5 терабайт, только 1.7 — жалко что ли?

Просто это сложнее. Базы такого объема в MS SQL приходится распределять по файловым группам (табличным пространствам), для распределения данных\нагрузки по массивам. Но при переброске между MS SQL и Postgres эта информация теряется, поскольку это делается средствами СУБД. Можно максимум отделить данные и индексы на этапе создания базы на разные Tablespace Postgres v81c_data, v81c_index, за что 1С огромное спасибо, ведь как прямо написано на ИТС.

Глава 5. Администрирование:: Клиент‑серверный вариант. Руководство администратора:: 1С:Предприятие 8.3.23. Документация (1c.ru)

«Пользовательские табличные пространства относятся к конкретной базе данных. Настройки табличных пространств не переносятся между базами данных с помощью выгрузки информационной базы в dt‑файл и обратной загрузки в другую СУБД.»

Даже если Вы обладатель лицензии КОРП и у вас есть функция управления табличными пространствами через 1С — при переносе через Dt данная информация теряется. При таком подходе можно только распределить эти 5 терабайт по двум массивам (данные и индексы). Если такие объемы не дробить по меньшим табличным пространствам — вы не сможете легко перекидывать бэкапы между серверами с дисковыми подсистемами разных размеров и использовать разные контроллеры для увеличения скорости ввода вывода.

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

Тут цитата:

«В первом раунде тяжелая операция – загрузка DT 40 с лишним гигабайт, итоговая база почти 2 терабайта. Сразу оговорюсь, если заглянуть в интернет, там будет много информации о том, что в DT не выгружается база, потому что она более 100 гигабайт, и ничего не работает. Все работает, надо только правильно настраивать сервер 1С, надо понимать, куда сервер 1С выгружает DT. Подтверждаю на своем опыте: база до 5 терабайт (больше не приходилось выгружать) из DT загружается и в DT выгружается. Все остальное – это неумение настраивать сервера 1С.

Первые результаты. С явным преимуществом побеждает MS SQL. Он в 2 раза быстрее загрузил данные в DT. Оба загружали очень долго, Postgres – почти двое суток, а MS SQL – почти сутки…»

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

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

1. Сократить объем выгружаемых\загружаемых данных.

2. Сделать пересчет итогов в фоновом режиме, когда база уже в Online. Это даст вам возможность раньше  запустить проверки или сервисные процедуры – если они у Вас есть. Вы можете также параллельно пересчитывать итоги в разных регистрах, если IOPS дисковой подсистемы позволяют. Своей обработкой или встроенным механизмом конфигуратора, где можно задавать количество заданий.

Как ускорить процесс конвертации

Скажу сразу, что выгрузка\загрузка осуществлялась на базе с релизом платформы 8.3.22.1709, а база без режима совместимости. Какие-то варианты, например, 8.3 с базой в режиме совместимости с 8.2 я не рассматривал принципиально, поскольку Postgres очень сильно меняется и платформа 1С тоже. С новыми версиями проще решать проблемы, а они есть. Данный тест проведен на сборке Postgres 15.х скачан с release.1c.ru.

Если Вы можете сделать свертку - лучше сделайте. Быстрые способы освободить базу от старых данных описаны тут 1С БодиПозитив / Хабр (habr.com).

Оборудование - диски

Для конвертации я использовал кластер из двух двухпроцессорных серверов HP (сервер приложений и сервер СУБД) c дисковой системой на HDD уровня RAID 10 . Поскольку, большинство операций в процессе переноса идет со стороны 1С однопоточно  - многоядерность и распределение нагрузки не так критичны, кроме момента создания индексов (несколько тысяч ). Не у всех есть двойной объем SSD, поэтому правильно выбирайте уровень RAID HDD.

На Raid 10 я не зафиксировал критических ожиданий, но нужно понимать что RAID 10 на 14 дисках дает ~2500 IOPS, а RAID5, который любят за большую итоговую емкость, с таким же количеством дисков только  ~700 IOPS . Этого может не хватить,  поэтому не думайте о IOPS с высока -  посчитайте проектный Калькулятор IOPS. RAID & IOPS Calculator. (team.ru) , сравните по счетчиками ОС , мониторьте Response time и проконсультируйтесь с системным администратором.

Оборудование - сеть

Обмен по сети идет высокий, много bulk \ bulk insert операций, поэтому приложений и сервер базы данных  должны взаимодействовать через сеть с минимальными задержками, не сильно отличающимися от прямого соединения кросскабелем. Если нет 10gb Ethernet , то возьмите хотя бы 2 гигабитных канала объединенных в Teamed Lan. О том как влияет сетевая задержка при передаче пакетов на производительность написано тут Анализ производительности компьютерных сетей на примере прикладных программ 1С  . Клиент серверное взаимодействие по сети, нужно отличать от скачки торрентов\копирования файлов – там блоки крупнее и структура отправленных и принятых пакетов разная, контент проще. В клиент серверном взаимодействии все наоборот - поэтому сетевая задержка критична.

Если у Вас есть возможность объединить сервер приложений и базы данных на время конвертации – Вы сократите издержки обмена по сети. Но как постоянный рабочий вариант это плохо - поскольку 1С не управляет распределением ресурсов по Numa узлам На многопроцессорных системах на одном сервере должно работать больше одного процесса rphost :: Проблемы и решения :: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru)  , а значит будут пересечения 1С и СУБД на одних и тех же ядрах (MS SQL и Postgres в разной степени поддерживают Numa node) при многопоточной работе и плавающие замедления производительности. Вам это надо?

Оборудование и виртуализация

Когда нужно много дискового пространства – можно выделить временный виртуальный кластер, но его нужно выравнивать по физическим машинам и убедится, что эти машины не используются другими виртуальными машинами иначе будет как  тут  1С + MS SQL против Матрицы виртуализации / Хабр (habr.com) , а Вас будет преследовать известный вопрос «Что есть реальность?»

Настройка СУБД

В особой настройке нуждается только СУБД приемник куда мы загружаем — Postgres.

Выключите синхронный commit — параметр synchronous_commit = off, пусть он будет асинхронным что увеличит производительность. Но параметр fsync ставить в off НЕ рекомендую — здесь можно конкретно разрушить данные в Postgres при неудачном прерывании процесса Postgres. Ведь synchronous_commit = off в плохом случае, только теряет последние транзакции с сохранением целостности СУБД, а fsync =off гораздо опаснее.

К сожалению в Postgres нет аналога minimal logging как в MS SQL для всей базы. Вернее есть опция unlogged для таблиц, которая позволяет эффективно делать bulk inserts, но ее может гипотетически ставить только кластер 1С при создании таблицы перед загрузкой Dt файла, и менять после загрузки. Но не торопитесь писать на community@1c.ru  — загадывать желания лучше по крупному, пример в последнем разделе.

Настраиваем кластер 1С и очищаем итоги

Отдельно нужно упомянуть дисковое пространство на сервере приложений 1С. Как показал мониторинг — временные файлы 1С при выгрузке DT могут занимать значительный объем (в моем случае до 20 гигабайт). Каталог временных файлов можно переместить, указав другие переменные окружения для пользователя под которым запускается кластер 1C в Windows.

На MS SQL нужно очистить итоги, чтобы сократить объем выгружаемых данных и заодно проверить корректность перерасчетов. Поверьте, Вы узнаете много нового, когда сравните производительность расчета итогов в MS SQL vs Postgres — все‑таки это функция платформы.

Очистку итогов в MS SQL лучше производить помесячно, сдвигом итогов назад дату происхождения базы — иначе это вызовет большую транзакцию c DELETE со всеми вытекающими последствиями. Если Вы внимательно читает код ниже, они наверное уже наступили, но если кнопка еще не нажата — про удаление больших данных можно почитать тут 1С БодиПозитив / Хабр (habr.com).

Код выглядит примерно так:

	Пока ТекДата > НачалоМесяца(НовыйПериод)-1 Цикл
		ТекДата = НачалоМесяца(ТекДата) - 1;
		СУУ_Лог.ЗаписатьСообщение(ИДВызова, "Сдвиг итогов назад", Перечисления.СУУ_ВидСообщения.Информация, 
		"Начало сдвига итогов на "+Строка(ТекДата));
		РегистрыБухгалтерии.Хозрасчетный.УстановитьПериодРассчитанныхИтогов(ТекДата);
		Если ВключаяРегистрыНакопления Тогда
			Для каждого ТекРег Из РегНакопления Цикл
				ТекДатаРегистра = РегистрыНакопления[ТекРег].ПолучитьПериодРассчитанныхИтогов();
				Если ТекДатаРегистра > ТекДата Тогда
					РегистрыНакопления[ТекРег].УстановитьПериодРассчитанныхИтогов(ТекДата);
				КонецЕсли; 
			КонецЦикла; 
		КонецЕсли; 
		СУУ_Лог.ЗаписатьСообщение(ИДВызова, "Сдвиг итогов назад", Перечисления.СУУ_ВидСообщения.Информация, 
		"Завершение сдвига итогов на "+Строка(ТекДата));
	КонецЦикла;

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

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

Отдельно стоит упомянуть регистры накопления с агрегатами. Там очистить итоги по периодам платформа не позволяет — только удалить все РегистрНакопленияМенеджер.ОчиститьАгрегаты() со всеми вытекающими последствиями. Как вариант можно помочь этому методу сделав предварительно truncate _AccumRgAgg<n> _AccumRgDl<n>, если ожидание по времени превосходит результат. Для таких действий нужно читать ИТС по структуре СУБД для 1С и дружить со средствами трассировки запросов.

Пересчет итогов в Postgres и важность AUTOVACUUM

Пересчет итогов это встроенный механизм платформы 1С, поэтому, было интересно сравнить производительность c MS SQL. Оборудование, диски, и операционная система, базы были одинаковы. Результат оказался не в пользу Postgres в 3–5 раз!!!

Вот сравнение на регистре бухгалтерии:

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

Исследование показало, что AUTOVACUUM срабатывал слишком редко, когда параметры autovacuum суффиксами threshold и scale_factor установлены по умолчанию.

Postgrespro настройка autovacuum

На картинке выше видно, что при настройке этих параметров деградация производительности исчезает, но это тема отдельной статьи. Если настроить autovacuum — деградация исчезает, но MS SQL в данной задаче все равно опережает.

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

Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С / Хабр (habr.com)

PostgresSQL — бесплатный сыр для 1С или ступенька к Enterprise версии?

Если  1С сделает быстрее, значит это кому-то нужно?

Технически 1С может сделать процесс быстрее, но кому это нужно?

Вы часто меняете СУБД при объеме больше терабайта? Я думаю раз в в солнечный цикл.

Вы делаете бэкап через dt? Но это неправильно — Вы как минимум теряете важную информацию о настройке таблиц в СУБД (напр распределение по tablespace см выше).

У меня нет статистики сколько процентов клиентов «1С подписанных на ИТС» имеют базу больше двух терабайт, но судя по медленному продвижению механизмов распараллеливания для алгоритмов в типовых конфигурациях (см Язык мой — враг мой. Архитектору о будущем 1С ) — пока время перемен не пришло. Есть ли такая статистика у 1С? А Вам кто‑то звонил спрашивал? Тогда ответ очевиден.

Однако есть задача, так и не решена в 1С — сохранение данных в архив. Весь учет построен на периодах и прошлые года неизбежно хочется поместить в архив. Конечно у 1С есть обработка сверки базы данных для 1С Бухгалтерии Как в «1С:Бухгалтерии 8» (ред. 3.0) выполнить свертку информационной базы?:: Отвечает специалист 1С (1c.ru), но кто рискнет запустить ее на терабайтной базе?

Проблемы, которые будут и решения, которые сейчас можно сделать для помещения периода в архив, описаны тут 1С БодиПозитив / Хабр (habr.com) — Вы как минимум не сможете быстро удалить, а потом вернуть данные из архива обратно, когда попросят. Партицирование средствами СУБД тоже не поможет, причины описаны в той же статье. Тогда какой выход?

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

Здесь можно почитать, что означает данная концепция Теория шардирования / Хабр (habr.com) . Это именно концепция, а не стандарт. Конечно, придется реализовать шардирование на уровне кластера 1С. Можно конечно воспользоваться будущим механизмом шардирования в Postgres План разработок (postgrespro.ru) , но мы то знаем, что общие реквизиты разделители могут этому помешать. К сожалению, общие реквизиты присутствуют для типовых конфигураций во всех индексах и 1С БСП. Кроме того, здесь нужна особая бизнес‑логика для контроля последовательности архивных периодов, механизмы извлечения из архива.

Реализация дает много плюсов — хочется поместить период в архив, выгрузил в DT, а платформа сделала truncate\drop нужных таблиц. Нужно извлечь данные из архива — извлек в ту же базу, либо в копию. И все выгрузки и загрузки можно сделать параллельно по шардам (отдельным таблицам).

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

Нравится? Тогда требуйте шардинг в будущих версиях — разумная реализация решает многие проблемы.

«Мечтай по‑крупному, мелкие мечты не зажигают сердца.» Гете

А пока подписывайтесь на наш канал t.me/Chat1CUnlimited , будем реализовывать мечты альтернативными методами.

P. S. Пока писал статью -  новом релизе 8.2.23 появился новый метод конвертации Глава 7. Автономный сервер :: Руководство администратора :: 1С:Предприятие 8.3.23. Документация (1c.ru)

Судя по отзывам выглядит перспективно , попробую его на 5 терабайтной базе в следующий раз

7.4.18. Миграция между информационными базами без выгрузки в dt-файл

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

ibcmd infobase replicate --data=d:\ss-data\cs-data --dbms=MSSQLServer --database-server=localhost --database-name=dbMsSql --database-user=msUser --database-password=123 --target-dbms=PostgreSQL --target-database-server=localhost --target-database-name=dbPgSql --target-database-user=pgUser --target-database-password=123 --target-create-database

В данном примере:

● Каталог данных автономного сервера: d:\ss-data\cs-data;

● СУБД, источник: Microsoft SQL Server;

● СУБД, приемник: PostgreSQL;

● Информационная база, источник: dbMsSql;

● Информационная база, приемник: dbPgSql;

● Обе СУБД работают на локальном компьютере;

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

● Параметры доступа к СУБД (имя пользователя и пароль) приведены исключительно в демонстрационных целях. В производственных базах данных использовать такие параметры доступа настоятельно не рекомендуется.