0. maxx 887 23.11.13 15:35 Сейчас в теме

Оптимизация работы подсистемы "Версионирование объектов" в БСП

Многие знают, что подсистема версионирования объектов в БСП (библиотеке стандартных подсистем) довольно прожорливая, базы начинает "пухнуть" от размера, поэтому многие её не включают. Я же столкнулся ещё с одной проблемой-перепроведение документов стало занимать гораздо больше времени. Попытался со всем этим что-то сделать и всё-таки использовать этот функционал в реальной работе, не переделывая всё кардинально.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Armando 1392 24.11.13 02:54 Сейчас в теме
Мне кажется, что это какое-то вредительство.
Что происходит в БСП:
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
3. Сериализация объекта
4. Запись в регистр

Что я увидел у Вас:
Представим, что пользователь просто нажал ОК ничего не изменяя.
Первые 2 пункта не отличаются
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
дальше самое интересное
3. Получение пометки на удаление по ссылке через точку: Источник.Ссылка.ПометкаУдаления
4. Сериализация объекта
5. Считывание из регистра предыдущей версии элемента справочника
6. Какая-то проверка и еще раз считывание уже какой-то другой (исходной) версии этого элемента
7. Сериализация объекта полученного по ссылке. Т.е. полное чтение объекта из базы. Ссылка.ПолучитьОбъект()
8. Запись в регистр без сериализованной версии объекта.

Хорошая такая оптимизация получилась. Вместо 1 раза сериализация выполняется 2 раза. Плюс к этому еще 4 раза зачем-то обращаемся к базе. И все равно выполняем запись в регистр. Тут уже не сильно важно есть там сериализованый объект или нет (если только он не очень большой). В каких-то отдельных случаях может произойти ситуация, что придется выполнить еще одно чтение из регистра и еще одну запись в этот регистр.

И ради чего это? Ради экономии пары гигов дискового пространства? Вам жалко что ли?
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?
alexeyvs77; mnemchinov; roman8115; ojiojiowka; +4 Ответить
2. maxx 887 24.11.13 10:24 Сейчас в теме
(1)
3. Получение пометки на удаление по ссылке через точку: Источник.Ссылка.ПометкаУдаления

Согласен, что функционал по определению, пометили ли на удаление объект, нужно сделать опциональным. Мне он был нужен, подумаю.

Вместо 1 раза сериализация выполняется 2 раза. Плюс к этому еще 4 раза зачем-то обращаемся к базе. И все равно выполняем запись в регистр. Тут уже не сильно важно есть там сериализованый объект или нет (если только он не очень большой)

Разница есть при записи документом с большой ТЧ, быстрее сравнить версии, чем записать эту большую версию в регистр. Запись практически пустой записи отличается по времени от записи с ХранилищеЗначения большого размера (несколько килобайт)

И ради чего это? Ради экономии пары гигов дискового пространства? Вам жалко что ли?
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?

Действительно жалко место, только на 2 гига, а гигов 20 и администраторы серверов начинают беспокоится о месте на сервере (500 Гб), особенно если надо развернуть копию и что-то проверить.
А обработка, которая удаляет лишние версии, у меня есть. Эта обработка переводит хранение из структуры хранения версий в БСП в мою структуру, удаляя лишние (одинаковые) версии.

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


33. maxx 887 28.11.13 09:43 Сейчас в теме
мы об этом узнали только в (2), причем в конце немаленького комментария, зато с припиской "и главное - перепроведение". А из (0) мы то подумали, что вопрос о том, что "тратится лишнее время при записи" и "пухнет база".

Согласен, что наверное нужно было начать описание с того, из-за чего всё начиналось, а не сразу описывать БСП.
3. Armando 1392 24.11.13 12:09 Сейчас в теме
Согласен, что функционал по определению, пометили ли на удаление объект, нужно сделать опциональным. Мне он был нужен, подумаю.

Если очень надо, то лучше пометку получать запросом, а не через точку по ссылке. Тем более, если у Вас документы с большим количеством записей в ТЧ. Сейчас чтоб получить пометку, тянется вообще весь объект.
Разница есть при записи документом с большой ТЧ, быстрее сравнить версии, чем записать эту большую версию в регистр. Запись практически пустой записи отличается по времени от записи с ХранилищеЗначения большого размера (несколько килобайт)

Для больших объектов актуально. Согласен. Но для маленьких это того не стоит. Проще его записать, чем выполнить кучу накладных манипуляций.
Действительно жалко место, только на 2 гига, а гигов 20 и администраторы серверов начинают беспокоится о месте на сервере (500 Гб), особенно если надо развернуть копию и что-то проверить.

Если у Вас MS SQL, то как вариант можно этот тяжелый регистр хранить в отдельной файловой группе и не бекапить ее. Только скорее всего при каждой реструктуризации придется заново переносить таблицу. Возможно на инфостарте кто-то этим уже заморачивался, надо поискать.
Ну и главное, перепроведение. У меня на база перепроведение ДО занимало часов 8, ПОСЛЕ 1 час, т.к в этом случае не происходит ни сравнения версий , ни записи этих версий, а только информация о том, что документ проводился.

Здесь полностью согласен. Чтоб облегчить групповое перепроведение, надо костыль прикручивать. Либо на этот период вообще отключать версионирование этих документов.


В общем что хочу сказать. Я так понимаю, что выигрыш достигается только на тяжелых объектах и только когда текущая версия объекта не отличается от предыдущей. Но для этого я бы сначала собрал статистику. А то у меня есть сомнения на этот счет. Для начала надо посчитать, при каком весе объекта его запись становится дороже расходов на сравнение и пр. Потом оценить вес имеющихся версий. Если есть такие объекты и их много, то надо бы собрать статистику, часто ли происходит перезапись неизмененного объекта. Если из 10 версий 1 неизмененная по отношению к предыдущей, то наверное не стоит заморачиваться. В любом случае надо замеры делать.
Ну и спасибо за попытку сделать что-то полезное.
6. maxx 887 25.11.13 09:12 Сейчас в теме
(3)
Если очень надо, то лучше пометку получать запросом, а не через точку по ссылке. Тем более, если у Вас документы с большим количеством записей в ТЧ. Сейчас чтоб получить пометку, тянется вообще весь объект.


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

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

Со статистике я и начал думать обо всем этом.
4. Silenser 517 24.11.13 19:30 Сейчас в теме
ИМХО.
Серилизация сама по себе занимает крайне мало времени, а вот сравнение - да. При записи документа нужно делать минимум телодвижений, ИМХО в БСП как раз все правильно - получили номер версии, сериализовали и записали, а анализ весь потом. Если уж так заботит размер базы - создайте регламентное задание, которое будет версии шерстить и удалять лишние или удалять больше определенного числа версий на объект. Я бы даже не искал последний номер версии, а писал GUID, потом можно отсортировать по дате записи версии (только не помню, если ли дата записи в стандартной БСП).
В идеале, посмотреть бы нагрузку на проц сервера приложений и на диск на SQL базе в момент перепроведения документов.
5. maxx 887 25.11.13 09:08 Сейчас в теме
(4)
При записи документа нужно делать минимум телодвижений

Это не аксиома, всё зависит от ситуации. Большинство решений по накоплению изменений объектов делают анализ именно перед записью.

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

Послушайте, но какая разница делать это сразу или регламентным заданием с точки зрения времени, все равно суммарное время будет одинакова при любом способе. Тут опять же зависит от условие эксплуатации конкретной базы. Если сидят до 10 операторов работают в файловых обычно базах, и к ним иногда забегает администратор(-программист), то наверное лучше всё сразу делать при записи. Если это админ в компании, который действительно всем занимается, может контролировать запуски регламентных заданий , результат этих запусков, то наверное тогда лучше делать регламентным заданием.
Поэтому опять же вижу, что это можно сделать настройкой типа "Сравнивать версии при записи" или "Сравнивать и удалять одинаковые версии регламентным заданием".
9. Silenser 517 25.11.13 09:40 Сейчас в теме
(5) Попробую навести вас на мысль: допустим регламентное задание потратило суммарно 30 мин на анализ и удаление лишних версий (при этом 28 мин ушло на анализ, а 2 мин на запись, при этом продолжительность каждой отдельной транзакции была минимальна, т.к. анализ выполнялся вне ее), а суммарно анализ внутри процедуры ПередЗаписью потратил 20 мин (при этом и анализ и запись вся суммарно заняла 20 мин, т.к. все выполняется внутри транзакции записи документа).
10. maxx 887 25.11.13 09:48 Сейчас в теме
(9)Ничего не понял, сформулируйте по-другому, что хотите сказать
11. Silenser 517 25.11.13 10:18 Сейчас в теме
(10) Увеличение числа телодвижений внутри транзакции ведет к увеличению ее продолжительности. Увеличение продолжительности транзакции ведет к увеличению числа одновременно активных транзакций. Увеличение числа одновременно активных транзакций ведет к риску эскалации транзакций, таймауту или деадлоку.
12. maxx 887 25.11.13 12:20 Сейчас в теме
(11) Да, теперь понял. Конечно время транзакции увеличится, тогда вариант с регламентным заданием может быть будет и лучше. Но думаю все равно надо анализировать ситуации каждый документ и его поведение в каждой базе, как эксплуатируется база. Например, Справочник "Организации" редко редактирует, я думаю можно и при записи всё сделать, а расходный документ уже может быть и блокировки. Просто не нужно забывать о "бедных" бухгалтерах, кладовщиках, которые работают одни в базах и нет у них помощи со стороны администраторов, я думаю там само всё должно работать.

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



13. Silenser 517 25.11.13 13:54 Сейчас в теме
(12) Опять же ИМХО, если у бухгалтеров или кладовщиков нет помощи от админов или разработчиков, то организация скорее всего маленькая и документооборот небольшой. Так что можно даже немного вольностей себе позволить при разработке, все равно они особо разницы не почувствуют, пока их в базе одновременно человек 30-50 не окажется.
7. ShantinTD 88 25.11.13 09:12 Сейчас в теме
(0) ну ведь глаза сломаешь, пока дочитаешь твою статью. В ворде хотя бы проверил, что ли...

Мысли вижу правильные, но реализация - пока что костыльная. Конечно, хранить полную сериализацию объекта в каждой записи, тем более не измененной, это жирно будет. Но 4 раза читать из базы, 2 раза сериализовывать - перебор, ИМХО. Тут скорее как Silenser в (4) написал нужно подчищать регистр периодически.

И еще вопрос: в том случае, когда для группового перепроведения используется не специализированная обработка, а динамический список, например, что прикажете? Отказаться от типового удобного механизма, за которым никуда лезть не нужно, в пользу отдельной обработки?
alexeyvs77; u_n_k_n_o_w_n; +2 Ответить
8. maxx 887 25.11.13 09:20 Сейчас в теме
(7)Но 4 раза читать из базы, 2 раза сериализовывать

С чего это решили, происходит все лишь дополнительное чтение объекта сохраненного в базе 1 раз.
2 раза сериализовать - 1 раз и так сериализуется в стандартном БСП , а 2-ой раз нужно для сравнения. Что не так?
14. ShantinTD 88 26.11.13 10:14 Сейчас в теме
(8) я хотел сказать, что производить достаточно громоздкие проверки при каждой мало-мальской записи - не есть гуд. Вижу, что понимание этого тут уже родилось.
Однако, могу и в пользу Вашего решения высказаться (и не буду стесняться в этом!): Ваш вариант вполне пригоден к применению, если использование регламентов по тем или иным причинам невозможно или затруднено. Причинами могут быть небольшая контора без толкового администратора базы, использование файлового варианта (опять же малопригодно для большой конторы), или еще что-то. С удовольствием продолжу конструктивный диалог, послушаю какие еще причины могут способствовать применению Вашего варианта.

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

(13) Silenser, если их окажется "человек 30-50", то это уже не маленькая контора. Да и в файловом варианте работать такой оравой негуманно. Опять приходим к регламентному заданию.
15. maxx 887 26.11.13 11:23 Сейчас в теме
(14)
я хотел сказать, что производить достаточно громоздкие проверки при каждой мало-мальской записи - не есть гуд. Вижу, что понимание этого тут уже родилось

Тут вы сразу крест поставили на кучу решений (http://infostart.ru/public/18588/, http://infostart.ru/public/172052/
http://infostart.ru/public/71458/
http://infostart.ru/public/19364/ и прочее и прочее)

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

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

Честно говоря мне эта тема не так интересно. Потому что в любой мало-мальски хорошей конфигурация, логика оптимального проведения не подразумевает, что нужно всё перепроводить и все движения переделывать, поэтому появляется в конфигурации свои обработки перепроведения (возьмите Бухгалтерию хотя бы), свои кнопки перепровести у пользователя, последовательности (по партиям_ и т.п.)
16. Silenser 517 26.11.13 11:52 Сейчас в теме
(15)
Как я знаю перед записью документа в момент перепроведения нельзя понять, менялся ли документ или нет, чтобы ничего не сравнивать объект с текущей версией в базе. В момент перепроведения он считается измененным, поэтому передать признак, что не нужно делать дополнительные действия нельзя.

Можно предположить, что если функция Модифицированность() дает истину в процедуре ПередЗаписью, то объект скорее всего изменен. Тогда можно в допсвойства закинуть некий признак и в ПриЗаписи выполнить некие действия по записи версии. Для документа еще нужно будет сравнить флаг проведения, если не ошибаюсь, его изменение на модифицированность не влияет.
17. maxx 887 26.11.13 12:15 Сейчас в теме
(16)
Для документа еще нужно будет сравнить флаг проведения, если не ошибаюсь, его изменение на модифицированность не влияет.

Надо это проверить. Вроде раньше влиял.
18. ShantinTD 88 26.11.13 13:54 Сейчас в теме
(15) я не сказал, что категорически нельзя проводить проверки перед записью. Я лишь поставил под сомнение правильность и оптимальность проверок. Это как раз то, о чем уже говорил Silenser: стОит ли овчинка выделки?
Честно говоря мне эта тема не так интересно. Потому что в любой мало-мальски хорошей конфигурация, логика оптимального проведения не подразумевает, что нужно всё перепроводить и все движения переделывать, поэтому появляется в конфигурации свои обработки перепроведения (возьмите Бухгалтерию хотя бы), свои кнопки перепровести у пользователя, последовательности (по партиям_ и т.п.)

Еще раз обрисую ситуацию: любая типовая на управляемых формах, форма списка - скорее всего является "Динамическим списком", можно выделить несколько документов (в том числе все) (а предварительно настроить отбор и сортировку) и нажать "провести". Специальная обработка - не требуется, перепроведение - групповое, конфигурация - типовая, "хорошая?" - "не плохая". А если говорить о перепроведении вообще, то в "хорошей" конфигурации его быть не должно, ИМХО. Нужно изначально не дать пользователю сделать неправильно.
19. maxx 887 26.11.13 14:12 Сейчас в теме
(18)
Еще раз обрисую ситуацию: любая типовая на управляемых формах, форма списка - скорее всего является "Динамическим списком", можно выделить несколько документов (в том числе все) (а предварительно настроить отбор и сортировку) и нажать "провести".


Проверил Модифицированность() даёт Истину, если перепроводишь документ.

Поэтому, я не знаю пока стандартного решения, как отличить "простое перепроведение" от "изменения проведенного документа (как программно, так и интерактивно) и его последующем проведением"
21. ShantinTD 88 27.11.13 09:53 Сейчас в теме
(19) еще раз повторю вопрос из (7): как поведет себя Ваша подсистема при использовании группового перепроведения из динамического списка?
По логике вещей запись о том, что документ перепровели должна остаться, а вот сериализация объекта в регистре сохраняться не должна. Правильно? Как дело обстоит на самом деле? Нужно ли мне подтягивать отдельную обработку, чтобы перепровести несколько документов? (при том, что в динамическом списке выбрать какие именно нужно перепровести - реально дело нескольких секунд).

Конечно, если перепроводятся документы разных типов, восстанавливаются последовательности, используется хитрый алгоритм и прочее - тут не отвертишься от специализированной перепроводилки.
22. maxx 887 27.11.13 11:20 Сейчас в теме
(21)
По логике вещей запись о том, что документ перепровели должна остаться, а вот сериализация объекта в регистре сохраняться не должна. Правильно?

Да всё правильно.

Просто я понял мы обсуждали, как при перепроведении динамических списков избавиться от сравнения версий и пока решения нет. Сравнение производиться будет, но одинаковые версии в регистр записывать не будут, будут только записи о проведении (пустышки), которые ссылаются на записи базовых версий.
20. ShantinTD 88 26.11.13 14:13 Сейчас в теме
Есть встречное предложение: называть это не "оптимизация", а "надстройка" над подсистемой версионирования объектов. То есть не заменять типовой механизм, а дополнять его. Опционально.
Может быть смазано высказываю свою мысль: система выборочного хранения записей в регистре - это хорошо, а вот как складывать записи в регистр или чистить его ("оперативно" или "регламентно") - сделать настраиваемым. И, например, при первом запуске, или периодически при запуске, проверить число пользователей в базе (при большом количестве рекомендовать регламент). Или проверить режим базы (для файлового варианта рекомендовать (жестко так рекомендовать) оперативный механизм). "Пусть лошадь думает - у нее голова большая". Пусть база сама определяет большая она или нет...
23. eeeio 114 27.11.13 13:53 Сейчас в теме
На мой взгляд оптимизация должна подразумевать вынос наиболее затратных действий в регламентную обработку. Например так:
1. ПриЗаписи в отдельный регистр фиксируется признак ВозможноНадоСохранитьВерсию = Истина и ссылка на объект, а также автор и дата записи (для нового объекта этот пункт не нужен);
2. Потом регламентное задание по этому регистру перебирает объекты и сравнивает их с хранящимися версиями - при нахождении различий сохраняет новую версию и удаляет обработанную строку из регистра (удаляет в любом случае)
3. На случай повторной записи объекта до регламентной обработки ПередЗаписью объекта происходит проверка на наличие флага ВозможноНадоСохранитьВерсию, и при его наличии сохраняет версию объекта ИЗ ССЫЛКИ
alexeyvs77; +1 Ответить
24. maxx 887 27.11.13 15:47 Сейчас в теме
(23) В целом, как уже обсуждали выше, согласен, что операцию сравнения и удаления можно вынести в регламентную обработку. Но я выступаю за то, чтобы работали оба варианта: сразу при записи документа или отложено регламентной обработкой(тут как раз придётся добавлять новое поле в записи "ВерсияПрошлаПроверкаНаИдентичностьСПредыдущими")
27. eeeio 114 27.11.13 18:43 Сейчас в теме
(24) мой вариант помимо сокращения объема хранимых версий (как и в статье) хорош тем, что:
- при записи неизмененного объекта не будет никаких затрат на проверку версий, если не считать быстрого запроса флага ВозможноНадоСохранитьВерсию
- при записи измененного объекта в случае отсутствия флага ВозможноНадоСохранитьВерсию тоже не будет затрат на сравнение версий
- и только при повторной записи объекта будет 1 раз вызвана процедура сравнения и записи версии
29. maxx 887 27.11.13 20:59 Сейчас в теме
(27)Не пойму что вы принципиально нового придумали.

В моем варианте для новых объектов никаких сравнений и записи версий нет.

При повторное записи идет сравнение и запись версии предыдущей, если есть отличия. Исключение:проводка документов со флагом в не проверять и не записывать версию.

Также напомню, что разработка родилась,когда документы проводились за месяц около 8 часов,после запуска моей настройки 1час, т.е. Большая часть времени уходило на сериализацию версий и запись этих версий в регистр
30. eeeio 114 28.11.13 08:54 Сейчас в теме
(29) Да, я не очень понятно выразился (хотя ничего принципиально нового я не придумал, конечно):
1. Запись нового объекта- нет затрат на контроль и запись версий (как и у вас)
2. При перезаписи объекта, после регламентной обработки "ОтложеннаяЗаписьВерсий" - нет затрат на контроль и запись версий (у вас есть)
3. При перезаписи объекта, необработанного регламентной обработкой "ОтложеннаяЗаписьВерсий" - есть сравнение и запись новой версии (из ссылки до изменения!), если найдены отличия (у вас тоже есть)
4. Нет необходимости в заполнении ДополнительныхСвойств объекта
То есть, судя по пунктам 2 и 4 можно получить плюсы из статьи, не заплатив (почти) за них минусами - лишним контролем при записи и замедленной скоростью типовой групповой перезаписи объектов из журнала
ojiojiowka; +1 Ответить
31. ShantinTD 88 28.11.13 09:22 Сейчас в теме
(29)
Также напомню, что разработка родилась,когда документы проводились за месяц около 8 часов...
мы об этом узнали только в (2), причем в конце немаленького комментария, зато с припиской "и главное - перепроведение". А из (0) мы то подумали, что вопрос о том, что "тратится лишнее время при записи" и "пухнет база". Вероятно, следовало начать с того, что оказалось "главным". По крайней мере акцентировать на этом внимание в (0). И акцентировать внимание на том, что обработка перепроведения тоже должна быть "оптимизированная", то есть заточенная под использование Вашей схемы версионирования.
Вероятно, если бы с (0) не осталось сомнений, что основной выигрыш именно на групповом перепроведении, то и вопросов и споров было бы меньше.
В свете того, что все затевалось ради перепроведения - предложение такое: комбинировать оба метода - ускоренный режим именно при перепроведении (специальной обработкой), и обычный режим + регламентная подчистка регистра при "плановом" проведении документа/записи объекта.
25. Danil.Potapov 27.11.13 17:27 Сейчас в теме
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши. В хеш данных подаются двоичные данные от ЗаписьFastInfoset, получается хеш. В самом регистре версий добавляется ресурс с хешом версии. При записи из регистра считывается последняя версия и ее хэш и сравнивается с новых хешом. Такая доработка позволяет уменьшить объемы чтения данных из базы.
Кузьмич; +1 Ответить
26. maxx 887 27.11.13 17:53 Сейчас в теме
(25)
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши.

Дайте ссылку почитать про хэши. Тут главное учесть, что проводят и меняют документы разные пользователи, в разные дни.
28. Danil.Potapov 27.11.13 18:52 Сейчас в теме
(26) в справке конфигуратора 8.3 ХешированиеДанных метод добавить, туда подается результат работы ЗаписьFastInfoset.Записать()

итого

ДвоичныеДанные = ЗаписьFastInfoset.Закрыть()
ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.SHA256);
ХешированиеДанных.Добавить(ДвоичныеДанные);
ХешВерсии = ХешированиеДанных.ХешСумма

второй вариант подавать на хеширование не Двоичные данные и строку (если работа версионирования идет через ЗаписьXML).



ojiojiowka; +1 Ответить
32. ShantinTD 88 28.11.13 09:28 Сейчас в теме
(28) Dpotapov, а с 8.3 тоже нужно осторожно - далеко не все перешли на новую платформу. Бывают и те, кто еще какой-нибудь 8.2.13 пользуются.
34. Danil.Potapov 28.11.13 09:54 Сейчас в теме
(32) ShantinTD, В 8.2 делаю тоже самое через регламентное задание, ночью система ищет версии без хеша, добавляет его, удаляет одинаковые версии. Скорость записи измененного документа не меняется, но хоть места становится меньше.
35. ShantinTD 88 28.11.13 10:17 Сейчас в теме
(34) Dpotapov, я сказал о том, что "использовать хеш" на 8.3 можно, но нужно иметь ввиду, что на 8.2 встроенного хеша нет - нужно приколхозивать его. У меня, например, была самописная процедура MD5(СтрокаДляХеширования). Естесственно, поменять во всех местах ее вызов на вызов встроенного объекта хеширование - хлопотно, и неправильно. В саму процедуру внесены изменения: если версия 8.3 или выше - то встроенный объект, иначе самописный алгоритм.
А "отсталые" пользователи, к сожалению, бывают: умер комп, поставили заново 1С с диска. Только вот диск 2010 года (или 2011 - не позднее), там тебе и счет-фактура "неправильная", и платформа старая, и прочее и прочее.
36. maxx 887 28.11.13 11:30 Сейчас в теме
(25)
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши.

А можете тыкнуть меня на материалы по хешированию, незнакомая для меня тема.
Поэтому пока не понимаю, что именно оптимальнее получается: размер версии или скорость сравнения?
38. maxx 887 28.11.13 21:44 Сейчас в теме
(37)Правильно я понял, что вы утверждаете, что хеширование использовать оптимальнее, т.к.:
- сжатый ЗаписьFastInfoset в ХешФункцию занимает меньше в размере, чем сжатие просто типа ХранилищеЗначения?
- сравнивать ХешФункции будет быстрее чем сериализованные ХранилищеЗначения с ЗаписьFastInfoset внутри?
39. Danil.Potapov 29.11.13 10:34 Сейчас в теме
(38) нет. Смысл в том, чтобы сравнивать хэш версий, а не тащить из базы хранилище предыдущей версии.
40. maxx 887 29.11.13 10:48 Сейчас в теме
(39)
Смысл в том, чтобы сравнивать хэш версий, а не тащить из базы хранилище предыдущей версии

Смысла не понял (сравнивать потому что можно сравнивать хеш версии а не версии объектов так?).
41. Danil.Potapov 29.11.13 11:04 Сейчас в теме
(40) сравниваются хэш версий объектов, так как при вытягинваии из базы будет меньше тянуться данных.
42. maxx 887 29.11.13 17:50 Сейчас в теме
(41)
сравниваются хэш версий объектов, так как при вытягинваии из базы будет меньше тянуться данных

Не понял за счет чего меньше.
43. Bad_Developer 19.09.14 13:50 Сейчас в теме
Что мешает серриализованные объекты сохранять в файл, и по периодам архивировать данные. Их можно складывать в дальний угол. И в случае форсмажора восстанавливать всю цепочку событий.
44. maxx 887 19.09.14 23:12 Сейчас в теме
Да ничего не мешает мне лично и думаю 1с, главное если есть желание.
Минусы только чтобы проанализировать изменения в данных на копии базы данных нужно дудеть тащить весь архив.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Специалист внедрения и сопровождения 1С
Москва
зарплата от 80 000 руб.
Полный день

Product Owner (Менеджер по продукту 1С)
Москва
зарплата от 100 000 руб. до 170 000 руб.
Полный день

Тим лид по разработке 1С (Team Lead 1С)
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству