Сказ о создании информационной базы для разработки и тестирования

28.08.24

Разработка - DevOps и автоматизация разработки

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

 

 

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

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

  • Через некоторое время я сменил место работы и уже работал с базой размером 10 гигабайт.

  • На следующем месте работы база 1С уже была 100 гигабайт.

  • Потом как-то так получилось, что я стал работать с базой 600 гигабайт. Мне казалось, что это очень много. Я приезжал на различные конференции, общался с коллегами, у которых базы по 50-100 гигабайт, они рассказывали о проблемах. Я им отвечал: «Какие у вас могут быть проблемы? Вот у меня база 600 гигабайт, это да». Они удивлялись: «Парень, ты там полегче с такими заявлениями» и спрашивали, как вообще с этим можно жить и работать.

  • Теперь я работаю с базой 2,5 терабайта – и это проблема для разработки и тестирования.

 

Способ №1 – Полная копия рабочей базы

 

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

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

Чтобы обеспечить их хотелки, нам понадобится каждому разработчику выделить по SSD-диску по 4 терабайта – это минимальный подходящий размер из возможных. Если мы перемножим 60 на 4 терабайта, окажется, что нам надо 240 терабайт места. Получается, что мы должны пойти к руководству и сказать: «Выделите нам бюджет более полутора миллиона рублей». Не каждый руководитель на это пойдет.

Хорошо, если руководство идет к нам на встречу и покупает каждому из 60 программистов по диску – мы все будем счастливы. Но все равно в какой-то момент место на этих 4 терабайтах закончится – базы же меняются.

 

Способ №2 – Удаление данных

 

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

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

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

  • Проходит время, места снова не хватает – что-то отключаем, мутим. Хорошо, снова вмещаемся.

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

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

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

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

  • Следующий этап – мы отдаем эту подготовленную базу программисту. Но если мы удалили данные до одного терабайта, 1 терабайт данных загрузить на обычный SSD-диск – это около четырех часов. Впору давать программистам day off, чтобы они отдохнули, пока грузится база. Мы своих программистов любим, мы им раньше давали это время.

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

  • Все компьютеры, как и люди, разные. На каждом компьютере могут быть разные жесткие диски. У кого-то 500 гигабайт, у кого-то 1 терабайт. И сложно вложиться в нужный размер. Но мы делаем невозможное. Мы влезаем в этот размер. Ходим счастливые, довольные.

  • И тут из-за угла вылезает мой коллега Антон и говорит: «Юра, ты удалил мне нужные данные!» Я говорю: «Антон, всем не угодишь

 

Способ №3 – Заполнение произвольными данными

 

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

Посмотрим, как здесь обстоит ситуация с минусами:

  • Время на написание обработки. Написать такую обработку – самое сложное в данной задаче, потому что ее может написать только разработчик, который знает, как работает 1С:Предприятие в режиме пользователя. Знает, где какую кнопочку нажимать, и какие движения должен делать документ.

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

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

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

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

 

Способ №4 – Махинации с базой данных

 

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

Однако, в этом способе есть минусы:

  • Самый главный минус, который нам подложила фирма «1С» – это нарушение лицензионного соглашения. Лезть в СУБД без платформы нельзя. Ужас. Может, когда-нибудь поменяют.

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

  • Но мы снова нарушаем лицензионное соглашение. Замкнутый круг, дело – труба.

 

Способ №5 – ?

 

Мы сидели, думали – а есть ли еще способ? И оказывается, способ есть!

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

 

Наш рабочий день начинался с очереди. В очереди куда? В конфигуратор.

 

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

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

Но надо же решать проблему – помогать людям. У нас была одна база – придумали решение: создадим вторую базу! Место есть.

 

Создали вторую базу. Баттлы в чате не утихают: «Кто внес изменения? Кто выкинул у нас из конфигуратора?» Создали третью базу, четвертую. Красавцы, места хватает.

Но жить с этим очень сложно – вплоть до того что чуть ли не драки в чате начинаются.

Кто что внес и в какую конфигурацию – вообще непонятно. Никто не может работать с этим. Тихий ужас. И мы с этим жили.

 

Выход

 

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

Решил посмотреть, что еще есть – смотрю, есть Windocks и приблизительно с аналогичным принципом Database Lab.

Я такой счастливый, думаю: «Сейчас я пойду к руководству, расскажу им, что нашел, и мы решим вопрос с доступом в конфигуратор».

А потом решил посмотреть цены – сколько это стоит. Открываю вкладку «Цены» и вижу 1 терабайт с подпиской на год стоит 10 тысяч долларов. А у нас 3 терабайта – нам нужно 30 тысяч. Как это? Руководство будет не очень довольно.

 

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

  • С рабочей базы снимаем резервную копию.

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

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

 

Прихожу к своему руководству и говорю: «Ребята, все, мы победили! Всем по конфигуратору, по базе!»

Собрали совещание, стали обсуждать, но у коллег возникли сомнения – как будет строиться очередь к этому файлу, какие для этого нужны диски?

 

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

  • HDD – это такой семейный седан. В него сел, катишься довольный. Он вроде надежный, но медленный.

  • А SSD – это болид «Формулы-1», в котором скорость не лимитирована, он может ехать очень быстро, если позволяет дорога.

Они говорят: «Конечно, у нас будут SSD-диски, мы же современные».

 

Возник следующий вопрос: «А что будет со скоростью?» Я предложил сравнить интерфейсы.

Если взять обычный пользовательский ПК, где стоит SATA:

  • SATA первый – 150 мегабайт в секунду;

  • SATA 2 – 300 мегабайт в секунду;

  • и SATA 3 – 600 мегабайт в секунду.

Но у нас в основном компьютеры Enterprise-сегмента, где главенствует SAS:

  • SAS первый – это 300 мегабайт в секунду,

  • SAS 2 – 600 мегабайт в секунду,

  • а современные модели SAS 3 и SAS 4 – 1200 и 2400 мегабайт в секунду.

Следующее поколение интерфейсов – PCI Express. Это M.2, U.2, U.3 и все остальные:

  • PCI Gen 2 – 500 мегабайт в секунду;

  • PCI Gen 3 – 1000 мегабайт в секунду;

  • PCI Gen 4 – 2000 мегабайт в секунду;

  • и последний PCI Express – 4000 мегабайт в секунду.

Если мы перемножим 16 линий на 4 гигабайта в секунду, то скорость чтения или записи на диск получится 64 ГБ в секунду. Это очень много.

А у нас оборудование где-то в районе SAS 3, PCI 3-4 – в общем-то, и неплохо.

 

Теперь посмотрим, что будет с очередью – как ее обслуживает тот или иной интерфейс:

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

  • SAS. Тоже одна очередь, но за сутки можно обслужить гораздо больше покупателей.

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

Коллеги говорят: «Окей, сдаемся – давайте пробовать».

 

Для реализации очереди мне понадобились:

  • интерес;

  • желание;

  • время – времени мне выделили неделю;

  • PowerShell – я реализовал на нем скрипт;

  • для администрирования сервера 1С скрипт использовал утилиту Rac/Ras;

  • для СУБД – командлет Invoke-Sqlcmd.

  • для дисков – вначале был DiskPart, но потом я перешел на командлет от Hyper-V, потому что он более универсальный.

 

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

  • Первая команда – New-VHD. С ее помощью мы создаем родительский диск.

  • Mount-VHD – подключаем его к системе;

  • Initialize-Disk– инициализируем,

  • New-Partition – создаем разметку,

  • Format-Volume – форматируем,

  • Get-VHD – получаем его номер,

  • Add-PartitionAccessPath – добавляем на диск операционную систему,

  • Restore Database – загружаем туда базу данных с помощью SQL-сервера;

  • Set Recovery Simple – переводим базу данных в режим Simple;

  • Set Auto_Shrink Off; DBCC Shrink File; Alter DataBase – шринканули;

  • EXEC sp_detach_db – отключились от SQL-сервера;

  • Remove_PartitionAccessPath; Remove-Item; Dismount-VHD – и отключаемся от операционной системы.

Отлично – быстро создали родительский диск.

 

А как создать разностный диск? Всего-то нам нужно:

  • New-VHD – создать разностный диск,

  • Mount-VHD – подключить его,

  • Add-PartitionAccessPath – добавить операционную систему,

  • EXEC sp_attach_db – подключить базу данных.

Вообще простота.

 

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

Потом мне надоело, что я вручную все делаю, и я автоматизировал процесс через Telegram. Теперь:

  • Программист отправляет в чат-бот Telegram команду определенного формата,

  • Telegram-бот запускает PowerShell с алгоритмом для SQL-сервера, который мы рассмотрели.

  • Дополнительно с помощью Rac/Ras подключает созданную базу в 1С и возвращает пользователю базу с подключением.

И это все работает, это классно.

Но самый смак в том, что создание базы теперь занимает 30 секунд. Это очень быстро.

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

В стандартном случае, чтобы загрузилась база 2,5 терабайта при хороших дисках нужно 30 минут. Помните, мы обсуждали, что у программистов на обычном SSD-диске, чтобы загрузить базу в 1 терабайт уходило 4 часа? Здесь – 30 секунд. Это вообще космос! Это сколько мы экономим времени разработчиков на тестирование!

И это все занимает 45 мегабайт. Представьте, у нас есть диск на 1 терабайт, сколько мы туда можем таких баз поместить? Да тысячи мы можем этих баз записать! И обеспечить тысячу человек полной копией. Это очень классно.

Понятно, что со временем количество изменений увеличивается, и разностные файлы растут. Но не так критично они растут.

 

Это у нас работало полгода. Мы обкатывали механизм, и пришла в голову идея: «Слушайте, мы же вначале использовали урезанную базу. А давайте попробуем применить этот подход для баз разработки?» Я говорю: «Давайте попробуем»:

  • Мы снова сделали копию с рабочей базы.

  • Загрузили в родительский диск.

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

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

 

На выходе мы получили следующую картину:

  • У нас теперь есть три полные базы:

    • Одна база – клон, который был родоначальником нашего подхода.

    • Вторая база – это база для разработки.

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

  • У нас остались все те же 60 разработчиков.

  • При этом все это занимает 5 дисков:

    • один из них на 12 терабайт;

    • и 4 обычных «седана» по 8 терабайт для хранения дифференциальных баз.

Все это нам все обошлось менее 400 тысяч рублей. Неплохо. Мне кажется, отлично. И руководство довольно.

 

Альтернативы на Linux

 

Когда я рассказываю ребятам про этот подход, они говорят: «Юра, ну ты же работаешь с MS SQL, у тебя Windows. А что нам делать? Мы на Linux, у нас PostgreSQL».

Я отвечаю: «Ребят, никакой разницы нет – подход работает и там, и там. Отличие только в том, что команды другие. Там не будет PowerShell, но там будет что-нибудь другое – хотя PowerShell есть и на Linux».

Тем более, Linux разрабатывает сообщество, и у него есть свои внутренние механизмы, которые могут делать то же самое.

Например, в Linux, в отличие от Windows, есть файловая система ZFS, которая приблизительно может делать такую же функциональность – там есть возможность клонировать образы, и она тоже хранит изменения. Правда, у ZFS есть проблемы с лицензией, но у нее есть аналог – BTRFS система, и там проблем с лицензией нет. Правда, в тонкостях, как это все работает из-под капота, я не разбирался, но оно должно работать.

Но если бы у меня был Linux, и нужно было бы выбирать – использовать файловую систему из ZFS/BTRFS или подход с виртуальными дисками – я бы выбрал виртуальные диски, потому что:

  1. Подход универсальный – он применим и на Linux, и на Windows;

  2. Я не уверен в надежности этих файловых систем – не знаю, как они работают с диском, как быстро на них диски выходят из строя. А мне нужна надежность в том, с чем я работаю.

Так вроде неочевидный подход позволил нам решить две задачи:

  • задачу с доступом в конфигуратор;

  • и задачу с доступом для баз разработчиков.

 

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

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

DevOps для 1С DevOps и автоматизация разработки Программист Стажер Платные (руб)

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

48000 руб.

20.06.2023    21093    21    4    

305

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    11499    94    4    

125

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.57.

2160 руб.

05.08.2024    939    10    1    

6

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.113.

2400 руб.

04.07.2022    8207    38    1    

28

DevOps и автоматизация разработки Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    12195    10    5    

34

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.156.30.

1800 руб.

20.01.2022    7585    18    0    

12

DevOps и автоматизация разработки Программист Платформа 1С v8.3 Бесплатно (free)

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

18.09.2024    1235    antonov_av    6    

14

DevOps и автоматизация разработки Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 1С:Документооборот Россия Бесплатно (free)

В данной инструкции рассмотрим процесс развертывания приложения на Python с использованием фреймворка Flask и Tesseract OCR в контейнере Docker. Узнаем, как использовать Tesseract в связке с Flask и осуществлять обращения к Tesseract для обработки изображений. Рассмотрим пример обращения к приложению Docker из 1С, в том числе для замещения CuneiForm в старых конфигурациях 1С:Документооборот версии 1.4 и ниже.

20.08.2024    794    romanichenko    2    

9
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. oveksKnaaz 29.08.24 07:44 Сейчас в теме
Однозначно лайк. Может кто то это провернет на PostgreSQL и так же выложет свою инструкцию.
А так ждем в новых версиях платформы групповую работу в конфигураторе опубликованную на зазеркалье
6. s22 22 29.08.24 16:43 Сейчас в теме
(1) технически наверно будет достаточно развернуть базы на ZFS постгрейсовские

там из коробки есть дедубликация. далее разрабам копировать (именно копировать) родительскую базу.
при этом файлы не будут целиком копироваться, а только создаваться ссылки на страницы изначальной
2. RustIG 1729 29.08.24 09:21 Сейчас в теме
в клонах хранятся изменения? а кто эти изменения вносит в клоны? как актуализируется информация в клонах?
4. s22 22 29.08.24 15:48 Сейчас в теме
(2)

страница1 - нет изменений - читается из родительской
страница2 - нет изменений - читается из родительской

делаем изменение в странице1 - страница1 записывается в копию

читаем страницу1 - читается из копии
читаем страницу2 - читается из родительской
3. RustIG 1729 29.08.24 10:11 Сейчас в теме
Честно говоря, я не до конца понял, как все устроено, и нет ли минусов? может падает в какой -то момент? лучше один раз увидеть, чем 100 раз услышать... Сколько разработчиков участвуют в этом?

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

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

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

- удаления данных для будущих копий - один раз создали копию БД, удалили лишнюю инфу - вот вам и база для будущих клонов для разработки - база в два раза -три раза меньше исходной

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

- для проведения заполнения базы данными - сейчас так работают все типовые конфигурации - для создания Демо-баз используют расширения для заполнения данных - но у них файловые базы и вес около 1,5 Гб - то есть не сопоставимо с базой из доклада - но можно сделать подобное заполнение для определенных процессов - как раз для отладки и разработки самых "узких" мест...

- для проведения автотестов - каждая уважающая себя компания делает автотесты под себя

- для выгрузки/загрузки документов за период для однотипных конфигураций - я раньше всегда пользовался таким методом через групповую обработку УниверсальнаяВыгрузкаЗагрузкаДанных - сначала переносил цфшник, затем переносил данные с помощью обработки - не все подряд, а только те документы, которые надо было тестить
5. s22 22 29.08.24 16:38 Сейчас в теме
А как обновляете родительскую?
user612295_death4321; +1 Ответить
9. user612295_death4321 30.08.24 12:58 Сейчас в теме
(5) Поддержу вопрос.

Если разработчиков много, у каждого какие то свои требования к актуальности родительской копии и один из этой кучи разрабов просит накатить более свежую БД. Как выглядит процесс?
11. stopa85 39 01.09.24 06:58 Сейчас в теме
(5) полагаю что берут и обновляют родительскую, а все дочерним перезаписывается.

Разрабы же хранят свои доработки в git или хранилище. И свои копии обновляют.
7. partizand 136 29.08.24 19:14 Сейчас в теме
Вы забыли ещё один способ. При разработке используется пустая база и пишется тест, который сам подготавливает себе нужные данные.
Этот способ наилучший, но конечно труднореализуемый.
8. genayo 29.08.24 22:05 Сейчас в теме
30 клонов баз по 25ТБ одобряют этот способ :)
10. roman72 388 31.08.24 22:49 Сейчас в теме
Что же за данные набивают 2,5 терабайта в вашей базе????
12. kamisov 216 01.09.24 12:02 Сейчас в теме
(10) это далеко не самый большой размер базы. Какая-нибудь ERP с включенной историей данных почти на всё запросто съест столько места.
13. roman72 388 01.09.24 19:00 Сейчас в теме
(12) Это объяснение выглядит притянутым за уши. Тут проще хранить ежедневный бэкап за 10 лет, чем за 400тр (ой ли) решать так сложно проблему, да ещё и иметь неповоротливую базу в терабайты. Там же ещё и обрезка и реиндексация базы съедают временного ресурса ого-го.
14. kamisov 216 01.09.24 19:32 Сейчас в теме
(13) нет, это ваше объяснение выглядит притянутым за уши :)
16. roman72 388 01.09.24 23:12 Сейчас в теме
(14) Да?
Приведите, пожалуйста, пример из вашего личного опыта с базой, где основным наполнителем были данные истории данных.
Какой максимальный размер у такой базы был, какая была конфигурация?
И какова была цель хранения столь обширной истории данных?
17. kamisov 216 01.09.24 23:50 Сейчас в теме
(16) да.
Любая конфигурация: типовая, нетиповая. Иногда ставят ЕРП, и, не используя функционал ЕРП, дописывают к ней свои блоки. Если включить историю вообще на все, то будет пухнуть как на дрожжах. Зачем? Бизнесу надо в любой момент понять что и как было. И вашего жутко профессиональное мнение вообще никому будет не интересно. Молча включили историю и живите как хотите :)

Из личного опыта в нетиповой 1.5 ТБ: 500 ГБ истории, 200 логов (да, прям в базе), остальное данные. Базе 10 лет.
19. roman72 388 02.09.24 11:52 Сейчас в теме
(17) Так что было в 500Гб истории то?
Треть базы из-за неё. А ради чего?
Да ещё и логов 200Гб???? Да в самой базе!! Тут другие под логи отдельные диски выделяют, а тут вот оно как.
Итого половина базы забита редкоиспользуемой информацией.

Бизнес может начхать на мнение любого профессионала, но законы природы ему не обойти, лишь только отсрочить ненадолго.
20. kamisov 216 02.09.24 12:29 Сейчас в теме
(19) я не знаю как еще объяснять: история всей базы. Каждого справочника, документа, регистра, задачи… всего. Вот, всего. Так понятно? Вся база в истории. Вся. Вообще вся. Абсолютно. Полностью.

> Тут другие под логи отдельные диски выделяют

Голь на выдумки хитра, это от бедности. Пока есть возможность тушить пожар деньгами, бизнес будет делать именно так.
21. roman72 388 02.09.24 15:09 Сейчас в теме
(20) Регистры в истории данных?????
Это как выглядит?
Регистр, сам про себе, и есть история данных.

Это ж у какого сейчас бизнеса есть деньги тушить пожар при 20% годовых?
22. kamisov 216 02.09.24 15:28 Сейчас в теме
(21)
Регистры в истории данных?????

да

Это как выглядит?

В свойствах регистра включить историю данных

Регистр, сам про себе, и есть история данных.

Далеко не всегда

Это ж у какого сейчас бизнеса есть деньги тушить пожар при 20% годовых?

Который никогда в кредит не жил

Прошу меня избавить от вопросов в дальнейшем…
Gesperid; +1 Ответить
28. webester 26 27.09.24 06:21 Сейчас в теме
(10) ДНС к примеру 13 терабайт управленческая самописка на 2020год, я видел эту базу, там нет БСП, историй и прочего. 50-250 магазинов на крупный город.
15. PerlAmutor 131 01.09.24 19:38 Сейчас в теме
Правильно ли я понимаю, что если каждый разработчик работает в своем клоне и кому-то одному потребуется накатить свежую базу, это потребует обновить родительскую копию, а как следствие все эти изменения применятся на разностные копии? Например.один из программистов дорабатывал конфигурацию, но еще не поместил эти доработки в хранилище и тут все эти доработки затираются рабочей копией?
18. s22 22 02.09.24 10:17 Сейчас в теме
(15)
Правильно ли я понимаю, что если каждый разработчик работает в своем клоне и кому-то одному потребуется накатить свежую базу, это потребует обновить родительскую копию, а как следствие все эти изменения применятся на разностные копии? Например.один из программистов дорабатывал конфигурацию, но еще не поместил эти доработки в хранилище и тут все эти доработки затираются рабочей копией?


если btrf то скорей всего обновление родительской просто займет полный размер. а из старой (которая удалена) родельской остануться только данные недостающие в клонах
23. yuraid 49 03.09.24 14:27 Сейчас в теме
(2) Если говорим про ежедневный клон, то загружается последняя полная резервная копия с помощью скрипта раз в сутки
(3) Минусы есть как и везде. Падает в основном при недостатке места на диске, как физическом так и виртуальном.
(5) Родительская база обновляется в ручную или с помощью скрипта, нужные команды есть в статье
(7) В статье способ 3
(10) Много разной информации требующейся для работы онлайн-гипермаркета
(15) Базы разработчиков обновляются по графику в основном раз в месяц или по мере надобности. Административно решен вопрос с обновлениями баз.
garaevilnur; RustIG; +2 Ответить
24. roman72 388 03.09.24 19:56 Сейчас в теме
(23)
"(10) Много разной информации требующейся для работы онлайн-гипермаркета"
А можно точнее?
Мне интересно какая информация касающаяся работы гипермаркета и причем хранимая не в объектах и регистрах, а именно помещаемая в историю.
По исходным носителяминформации свёртка что-ли выполняется?
26. yuraid 49 05.09.24 13:53 Сейчас в теме
(24) Какая информация там была, я уже не помню. Насколько помню неактуальные/неиспользуемые данные постоянно перемещались в отдельную информационную базу или удалялись. Проводилась ежедневная работа с данными чтобы база быстро не росла и работала как можно быстрее
25. cloud666 28 04.09.24 14:01 Сейчас в теме
А можно скрипты выложить?
Например: New-VHD = New-VirtualDisk как я понимаю?
27. yuraid 49 05.09.24 14:00 Сейчас в теме
(25) Скрипт не могу выложить.
Информации в статье достаточно чтобы написать собственный скрипт. Команды написаны для PowerShell.
Единственное что не указанно в статье что после перезагрузки оборудования нужно снова монтировать диски
Оставьте свое сообщение