Версионирование - каковы последствия в плане производительности и роста базы?
Всем привет!
Поделитесь опытом, кто включал версионирование в ЗУП 3.1 - заметно ли это отразилось на быстродействии и на размере базы? После перехода на новую редакцию были тонны возмущения на предмет тормозов в новом ЗУПе, сейчас версионирование так и манит, останавливает только возможность ухудшения этих самих тормозов. И как это вообще работает, в любой момент можно его выключить и регистр с версиями перестанет заполняться или нет?
База клиент-серверная, ЗУП 3.1.8.246 плафторма 8.3.12.1529
Спасибо заранее всем откликнувшимся)
Поделитесь опытом, кто включал версионирование в ЗУП 3.1 - заметно ли это отразилось на быстродействии и на размере базы? После перехода на новую редакцию были тонны возмущения на предмет тормозов в новом ЗУПе, сейчас версионирование так и манит, останавливает только возможность ухудшения этих самих тормозов. И как это вообще работает, в любой момент можно его выключить и регистр с версиями перестанет заполняться или нет?
База клиент-серверная, ЗУП 3.1.8.246 плафторма 8.3.12.1529
Спасибо заранее всем откликнувшимся)
Найденные решения
в ЗУПе не такой объем данных как в оперативных БД(УТ, БУХ) так что, я считаю, можно не опасаться версионирования в ней.
Гораздо "страшнее" для ЗУПА монстровидный РЛС, корявые запросы в динамических списках
и массовая практика вычислений через механизмы представлений с использованием множеств временных таблиц - именно эти факторы и вызывают 99% тех случаев когда пользователи вопят "тормозит".
Гораздо "страшнее" для ЗУПА монстровидный РЛС, корявые запросы в динамических списках
и массовая практика вычислений через механизмы представлений с использованием множеств временных таблиц - именно эти факторы и вызывают 99% тех случаев когда пользователи вопят "тормозит".
Да выборочное указание объектов, пожалуй оптимальный выход, тем более что не обязательно сохранять версии всех объектов. Объем базы понятно что будет расти, без этого ни куда, тут придется чем то жертвовать.
Когда объемы информации в программе возрастают, можно постепенно отказываться от версионирования некоторых объектов вообще или применять его только в особенно важные моменты, например, при проведении документов. Можно ограничить срок хранения версий, например годом. После этого версии будут автоматически удаляться регламентным заданием. Настройка запуска регламентного задания осуществляется на странице настроек версионирования.
Источник:
Источник:
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Рост базы точно не избежен, но тут можно в какой то период делать свертку регистра, либо написать/доработать чтоб хранилось во внейшней базы. Но если сворачивать, то потеряется полная история изменения, если во внешней базе хранить, то писать какой то функционал по получению данных и представления ее для пользователя
(5) Доработать имеется ввиду сделать полностью свое через БСП или есть возможность доработаь платформенный? Просто никак не могу понять различия между ними, вроде как с первым, само собой можно делать все что угодно, а вот платформенный не очень понятно чем отличается. Полная история не нужна, в основном нужно просто "найти косячника" за последнее время :)
Когда объемы информации в программе возрастают, можно постепенно отказываться от версионирования некоторых объектов вообще или применять его только в особенно важные моменты, например, при проведении документов. Можно ограничить срок хранения версий, например годом. После этого версии будут автоматически удаляться регламентным заданием. Настройка запуска регламентного задания осуществляется на странице настроек версионирования.
Источник:
Источник:
у нас включено версионирование по тем объектам, по которым вечном разборки между кадровиками и расчетчиками кто что поменял, по остальным выключено
срок хранения стоит 3 месяца, более длительных разборок обычно не бывает :)
срок хранения стоит 3 месяца, более длительных разборок обычно не бывает :)
Да выборочное указание объектов, пожалуй оптимальный выход, тем более что не обязательно сохранять версии всех объектов. Объем базы понятно что будет расти, без этого ни куда, тут придется чем то жертвовать.
в ЗУПе не такой объем данных как в оперативных БД(УТ, БУХ) так что, я считаю, можно не опасаться версионирования в ней.
Гораздо "страшнее" для ЗУПА монстровидный РЛС, корявые запросы в динамических списках
и массовая практика вычислений через механизмы представлений с использованием множеств временных таблиц - именно эти факторы и вызывают 99% тех случаев когда пользователи вопят "тормозит".
Гораздо "страшнее" для ЗУПА монстровидный РЛС, корявые запросы в динамических списках
и массовая практика вычислений через механизмы представлений с использованием множеств временных таблиц - именно эти факторы и вызывают 99% тех случаев когда пользователи вопят "тормозит".
Лет 5 назад делал историю изменения реквизитов документа на 7.7 для организации, которая печатает рекламные объявления от частников и юр.лиц о продажах
до сих пор работают на ней. У них споры были, что кто-то исправляет объявления после разноски их в базу. До сих пор у них это работает.
до сих пор работают на ней. У них споры были, что кто-то исправляет объявления после разноски их в базу. До сих пор у них это работает.
Нашел статью с зазеркалья с описанием платформенного версионирования, вроде звучит неплохо - сам объект не хранится, только его изменения, плюс историю можно настраивать до реквизитов
В ЗУП настраивается в менб Администрирование - общие настройки - история изменений. Проверил на копии, отключается нормально и механизм очень заманчивый - наглядно показывает что изменилось :)
Когда мы проанализировали имеющуюся ситуацию, имеющийся опыт использования БСП, взвесили все «за» и «против», мы пришли к выводу, что наиболее эффективным решением будет реализовать историю данных в составе самой технологической платформы. Это позволит достичь следующих преимуществ:
Чтобы воспользоваться этим механизмом администратору или пользователю не придётся изменять конфигурацию, всё необходимое уже есть в платформе. Нужно только включить.
Этот механизм будет работать быстрее, чем аналоги, реализованные в составе конфигурации, т.к. он будет использовать возможности, недоступные из встроенного языка.
Сама история данных будет занимать меньше места, так как будет храниться не копия данных, а только их разница с предыдущей версией. Кроме этого само версионирование можно применять не ко всем реквизитам, а только к тем, которые интересуют. Это также даст дополнительную экономию.
Можно будет поддержать версионирование не только тех объектов, которые обладают уникальной ссылкой (справочники, документы и т.п.), но и необъектных сущностей, таких как записи регистров сведений, например.
Чтобы воспользоваться этим механизмом администратору или пользователю не придётся изменять конфигурацию, всё необходимое уже есть в платформе. Нужно только включить.
Этот механизм будет работать быстрее, чем аналоги, реализованные в составе конфигурации, т.к. он будет использовать возможности, недоступные из встроенного языка.
Сама история данных будет занимать меньше места, так как будет храниться не копия данных, а только их разница с предыдущей версией. Кроме этого само версионирование можно применять не ко всем реквизитам, а только к тем, которые интересуют. Это также даст дополнительную экономию.
Можно будет поддержать версионирование не только тех объектов, которые обладают уникальной ссылкой (справочники, документы и т.п.), но и необъектных сущностей, таких как записи регистров сведений, например.
В ЗУП настраивается в менб Администрирование - общие настройки - история изменений. Проверил на копии, отключается нормально и механизм очень заманчивый - наглядно показывает что изменилось :)
(20) так в (17) же ссылка.
Или вопрос был "как включить его использование"? Так в той же ссылке написано общими словами: «Включение» механизма заключается в том, чтобы указать, для каких именно объектов конфигурации будет вестись история изменений.
Из опыта: как-то создавал новый документ, пытался включить ему какой-то флаг использования из платформенного "история данных" - так конфигуратор сказал "нельзя, т.к. режим совместимости ниже требуемого". Ну ради этого я не стал в типовой повышать режим совместимости.
Или вопрос был "как включить его использование"? Так в той же ссылке написано общими словами: «Включение» механизма заключается в том, чтобы указать, для каких именно объектов конфигурации будет вестись история изменений.
Из опыта: как-то создавал новый документ, пытался включить ему какой-то флаг использования из платформенного "история данных" - так конфигуратор сказал "нельзя, т.к. режим совместимости ниже требуемого". Ну ради этого я не стал в типовой повышать режим совместимости.
Версионирование - такая вещь, что однажды попробовав (вернее, когда получаешь ответ на вопрос "да что за чертовщина творится в базе" в виде "тот-то тогда-то поменял реквизит в справочнике") - ни за что не откажешься. Пусть база растет (хотя не так уж и сильно, обычно гораздо больше по размерам регистры партий или прикрепленных файлов). Да и не приходилось сталкиваться с тем чтоб оно давало заметное замедление. Вот rls - тот да, сразу заметен.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот