0. alexeyvs77 20 17.11.17 14:19 Сейчас в теме

Ведение подробного лога (версионирование) справочников, документов и регистров сведений с сохранением истории изменений на SQL-сервере

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

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

Комментарии
Избранное Подписка Сортировка: Древо
2. WellMaster 98 28.02.18 10:24 Сейчас в теме
Не будет ли этот самый РегистрСведений.Логирование узким местом в производительности?
3. alexeyvs77 28.02.18 15:11 Сейчас в теме
(2) я делал замеры. Вклад логирования в общее время записи тех же документов пренебрежительно мал.
И потом, регистр не будет разрастаться бесконечно - он переносится на сервер. Если тормозит - поиграй с индексацией.

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

А если уж контора настолько огромна, что транзакций записи/просмотра/открытия форм стотыщ в секунду, и все алгоритмы оптимизированы настолько, насколько это возможно, тогда, возможно, вклад регистра в производительность окажется существенен. Но в таком случае странно предполагать, что руководитель ИТ-отдела такой серьезной конторы решит внедрять подсистему с инфостарта за 10sm.
30. pavel_D 5 02.05.18 14:04 Сейчас в теме
hren77, здравствуйте.
Как раз сейчас нужна подобная конфигурация, чтобы сократить размер информационной базы, вынеся версионирование в отдельную базу.
Скажите, пожалуйста, в вашем решении, как я понимаю, так и реализовано? Версионирование ведется в отдельной конфигурации, в отдельной базе? И каким образом рабочая конфигурация будет связана с конфигурацией версионирования? Подключена через COM-соединение? Или каким-то другим образом?
И как версии объектов будут появляться в этой базе? Посредством чего?
5. AlexO 126 01.03.18 12:46 Сейчас в теме
(2) любой регистр в 1С - узкое место.
У 1С вообще плохо с производительностью.
Поэтому везде, где возможно - все объемы данных выносить на внешнюю SQL (может быть не только MS SQL, хотя и предпочтительно), и обрабатывать там, возвращая в 1С лишь результат обработки.
Собственно, это - невозможность обработки больших объемов, - косвенно признает и демонстрирует сама 1С - в частности, переводом своего журнала регистрации на рельсы MySQL, да вот только не очень хорошо у неё все время все получается...
7. alexeyvs77 01.03.18 15:08 Сейчас в теме
(5)
любой регистр в 1С - узкое место

То есть, правильней было бы не использовать в качестве буфера регистр сведений, а писать прямо на sql?
8. AlexO 126 01.03.18 15:20 Сейчас в теме
(7) если большие объемы (миллионы или сотни миллионов записей в обработке) - то да, лучше сразу в SQL, "минуя" 1С.
Например, делаете доптаблицу к основной базе, но лучше - отдельную базу, чтобы и структуру 1С-баз не повредить, и не быть ограниченным в обработке.
Делаете там поиск, удаление, сортировку, обратно - уже результат, например, для дальнейшей обработки в документах 1С.
Т.е. чтобы основная нагрузка по перелопачиванию данных не ложилась на 1С-сервер, а чтобы "сырой", первичной обработкой больших объемов данных занимался специализированный сервер.
Аналогично, хранение, поиск, обработка картинок, видео - все хранить во внешней базе, в 1С только ссылки и вытаскивать нужное по мере необходимости. Иначе через полгода база 1С еле будет ворочаться, не говоря уже про выполнение прямых функций по обработке документов.
4. WellMaster 98 01.03.18 12:23 Сейчас в теме
Речь как раз про многозадачность, а не скорость записи в регистр.
И уж тем более не про размер регистра.
Даже типовое 1с-овское версионирование начинает жутко лагать, если его использовать на полную катушку. В той же КА 2.0.

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

Да и речь не идет о руководителе ИТ-отдела.
6. alexeyvs77 01.03.18 15:06 Сейчас в теме
(4) Про многозадачность поподробней можно?
9. AlexO 126 01.03.18 15:27 Сейчас в теме
(6) возможно, имелось ввиду - "многопоточность" поступления данных в регистр, когда сразу несколько объектов вносят данные, а не "многозадачность".
Хотя и тут - вопрос упирается в скорость записи в регистр, на уровне таблиц хранения все равно будет блокировка всей таблицы для внесения каждой записи, если писать из 1С. А не блокировка только записи, как многие думают.
Блокировку же записей можно делать только на уровне SQL-сервера, а не 1С-сервера.
10. alexeyvs77 01.03.18 15:36 Сейчас в теме
(9)
на уровне таблиц хранения все равно будет блокировка всей таблицы

А вот тут да, может быть затык. Тут можно подумать насчет прямой записи в таблицу регистра.
Займусь, как будет скучно
12. AlexO 126 01.03.18 15:45 Сейчас в теме
(10) во-первых, прямая запись, даже если удасться соблюсти "полярность" (заполнение всех нужных полей) и последовательность, рано или поздно приведет к "повреждению" физической таблицы - ведь вы будете заполнять таблицу параллельно с 1С-сервером, о чем он знать не знает, и, поэтому, не контролирует целостность вашей записи на своем уровне.
Не говоря уже - о конфликтах доступа к таблицам и записям между вами и сервером 1С, которые вообще непонятно как вы сможете разрулить - 1С-сервер не дает таких инструментов и возможностей, и в нем нет обратной связи для устранения таких конфликтов (ну разве что сообщения об отказе в доутупе или ошибках - можно считать такой "обратной связью"), а на уровне SQL - оба обращения будут тождественны и приоритетны, как два обычных пользователя, вы их тоже не разделите никак.
14. alexeyvs77 01.03.18 16:12 Сейчас в теме
(12)
физической таблицы - ведь вы будете заполнять таблицу параллельно с 1С-сервером

Почему параллельно с сервером, если я буду заполнять и очищать конкретный регистр только прямой записью - и никак более?
Или я что-то не понял?
15. AlexO 126 01.03.18 16:16 Сейчас в теме
(14)так вы же написали:
Тут можно подумать насчет прямой записи в таблицу регистра


а у SQL-баз нет "регистров", это сугубо название из 1С в данном случае, поэтому - регистры только в базе 1С, ну и, далее, вы обращаетесь вместе с сервером 1С к одним и тем же регистрам базы 1С.
17. alexeyvs77 01.03.18 16:31 Сейчас в теме
(15)
а у SQL-баз нет регистров

Ну хорошо: не в регистр, а в соответствующие таблицы на sql-сервере.
обращаетесь вместе с сервером 1С к одним и тем же регистрам

Почему вместе с сервером, если я условился обращаться к регистру соответствующим регистру таблицам только прямыми запросами?

Когда я говорю "прямое обращение к регистру", я подразумеваю обращение к таблицам, из которых состоит сущность 1с "регистр сведений".
18. AlexO 126 02.03.18 09:43 Сейчас в теме
(17)
Почему вместе с сервером, если я условился обращаться к регистру соответствующим регистру таблицам только прямыми запросами?

Потому что, а кто будет "разруливать" ваше совместное обращение к одной таблице? При условии, что вы обращаетесь к таблице базы 1С, а не к "левой".
SQL-ю вы равны, 1С-сервер о вас знать не знает, вы сами - поймать не можете (нет средств).
Т.е., вы считаете, что при одновременном обращении к одной таблице и блокировке SQL-ем этой таблицы "для вас", 1С-сервер скажет "ну хорошо, подожду, пока кто-то копается в "моей" таблице"? ))
И не забывайте, еще худо-бедно можно было бы рассчитывать "ну это маловероятно, что будем читать одно и то же" при обращении к строкам (хотя это и не так - очень даже вероятно, что к одним строкам и будете обращаться, данные-то одни, вы со своей стороны работаете "по документу", 1С-сервер - со своей), так ведь 1С блокирует всю таблицу "под себя".
Или попытается это сделать.
19. alexeyvs77 02.03.18 10:12 Сейчас в теме
(18)
Т.е., вы считаете, что при одновременном обращении к одной таблице и блокировке SQL-ем...

Еще раз: почему будет одновременное обращение средствами sql и сервером 1С к одному регистру, если я условился обращаться к этому регистру только прямыми запросами - как на запись так и на чтение?...
Хотя, при таком раскладе, чем городить алгоритм корректного обращения прямыми запросами к таблице, возможно, будет правильней расположить на этом же сервере базу лога. Тогда и с настройками подключения не надо будет заморачиваться...
20. AlexO 126 02.03.18 10:30 Сейчас в теме
(19)
почему будет одновременное обращение средствами sql и сервером 1С

А как вы запретите 1С работать с его же базой? Вот понадобилось ему что-то, он и обратился.
А там - вы работаете (читаете, пишете в таблицу). SQL сообщает 1С-серверу - "обожди, брат, тут пока не до тебя".
Что, и как, по-вашему, среагирует на такую "бестактность" 1С? ))
И причем тут "прямые-непрямые" запросы, у 1С свои задачи, она их и будет решать без оглядки на то, что еще кто-то работает с этими данными.
Вы просто забываете, что блокировать будет уже не 1С-сервер, а SQL на своем уровне.
Вы для него - равноправные "пользователи" базы, он вас не разделяет на "это сервер, а это - прямой запрос админа".
21. alexeyvs77 02.03.18 12:05 Сейчас в теме
(20)
у 1С свои задачи, она их и будет решать без оглядки на то

Например?
22. AlexO 126 02.03.18 13:07 Сейчас в теме
(21) обработка документов другими пользователями - подойдет? )
23. alexeyvs77 03.03.18 11:48 Сейчас в теме
(22) Если эта обработка будет затрагивать регистр лога, то каким образом?... если к регистру будут только прямые запросы
24. AlexO 126 03.03.18 12:00 Сейчас в теме
(23) если это только ваш "регистр" (таблица), и 1С о нем "не знает" - то не будет.
А если регистр из конфигурации - то будет.
У вас же указано - "регистр сведений или справочник", но не указано, свой ли будете делать, или типовой.
Да и потом, всегда есть соблазн обратится к такому регистру "изнутри", средствами 1С-сервера, как к элементу ИБ - данные собрать, проанализировать там...
Лучше всегда делать отдельную SQL-базу, чтобы процессы обработки не пересекались. И вам удобнее, никаких ограничений и "оглядок" на 1С, и структура базы не будет нарушена, в случае чего.
27. alexeyvs77 03.03.18 20:45 Сейчас в теме
(24) Ну, понятно.
На самом деле все объекты этой разработки нетиповые. В т.ч регистр лога...
Но вот отдельная база на том же сервере - тут да, согласен, оптимальней. Не надо будет прописывать подключение, и лишнего посредника-регистра не будет. Как и регламентного задания переноса на сервер.
Появится время - доделаю.
16. AlexO 126 01.03.18 16:18 Сейчас в теме
(14)или вы про "реляционные таблицы"? ))
Это несколько другое, чем регистры 1С, даже по отношению к РС, не говоря про - регистры накопления ))
11. alexeyvs77 01.03.18 15:38 Сейчас в теме
(9) Это может быть актуально только для очень крупной конторы - с тысячами пользователей
13. AlexO 126 01.03.18 15:48 Сейчас в теме
(11) не обязательно.
Может быть просто контора с большим объемом обрабатываемых данных, которые собираются и поступают в автоматическом и полуавтоматическом режиме.
А то и просто - куча менеджеров из филиалов (даже не сотрудников) через веб заполняют центральную базу по своим филиалам.
Вот вам и тысячи новых документов в день, а в каждом - несколько ТЧ и сотни и тысячи строк.
А к концу дня - десятки миллионов записей, требующих "утряски" и обработки ))
25. aspirator23 392 03.03.18 15:38 Сейчас в теме
(11)Обработка логирования выглядит продуманной. Для оценки влияния ее на систему мы знаем что при добавлении записи в регистр сведений время все же меньше чем вставка. Стоит посмотреть на поведение обработки, запустив разных роботов на изменение разных объектов, чтобы они не пересекались по этим объектам. Далее постепенно увеличивать количество роботов. Будет ли критична запись в логирование и при какой нагрузке? Где произойдет блокировка? На записи объектов или логировании? Тогда можно обоснованно сделать вывод о влиянии логирования на поведение системы.
26. AlexO 126 03.03.18 16:25 Сейчас в теме
(25)
мы знаем что при добавлении записи в регистр сведений время все же меньше чем вставка.

вы уже научились разделять вставку и добавление? Т.е., разделили INSERT?
Я вот полагал, что этим занимается анализатор СУБД, возможно, вы знаете то, чего не знаю я.
28. aspirator23 392 06.03.18 10:03 Сейчас в теме
Чтобы увеличить быстродействие записи можно попробовать следующее:
1.Попробовать максимально упростить и сократить количество полей регистра сведений. Отказаться от индексирования полей.
2.Попробовать вместо регистра сведений использовать справочник, где отключить код и наименование. В этом случае не будет индексирования.
При записи в справочник не будет проверяться уникальность элементов.
3. Использовать стороннюю не реляционную базу. Быстродействие их выше.
29. AlexO 126 06.03.18 12:51 Сейчас в теме
(28)
2.Попробовать вместо регистра сведений использовать справочник, где отключить код и наименование.
Это встроенные поля, как вы их отключите? Они все равно останутся.
Задание в "0" лишь укажет 1С-серверу "не смотреть" эти поля.
Индексирование - будет в любом случае, иначе - как вы вообще полагаете что-либо выудить из таблицы справочника? )
Просто поиск будет по одному ключу (он же GUID поля, он же идентификатор, binary 16-bit) - IDRRef.
Вот полнотекстовый поиск стоит отключить. Желательно, по всем объектам.
При записи в справочник не будет проверяться уникальность элементов

Средствами 1С - да, не будет.
"Уникальность" не будет проверяться на уровне "Код-наименование" (т.е. пользователю "визуально" покажут много якобы "одинаковых" элементов), а реально каждый объект будет все равно уникальным.
3. Использовать стороннюю не реляционную базу. Быстродействие их выше.

Это самый верный и производительный вариант.
Потому как основные тормоза при работе с данными - это использование механизмов 1С для работы с ними.
Использование специально разработанной для целей обработки данных СУБД - увеличивает производительность на порядки, даже не в разы.
31. ice-net 14 26.12.18 15:06 Сейчас в теме
(0)

(!) В версиях платформы 8.2.х не предусмотрены подписки на события получения форм. В таком случае регистрация событий просмотра работать не будет.

Речь именно о платформе 8.2? Другими словами, на конфигурации с обычными формами, в режиме совместимости 8.2 на платформе 8.3 будет работать регистрация событий просмотра?
32. alexeyvs77 26.12.18 22:14 Сейчас в теме
(31) Речь именно о платформе. На 8.3 просмотр будет работать, в т.ч. и в режиме совместимости с 8.2
33. xico 54 11.02.19 11:40 Сейчас в теме
Будет ли работать с sql 2008? файл 1Clogs.bak я так понимаю для 2014 -го сервера, а нет ли версии для 2008 сервера?
34. alexeyvs77 20 11.02.19 12:44 Сейчас в теме
(33) На 2008 не пробовал. В любом случае можно создать базу вручную - всего одна таблица:
Прикрепленные файлы:
35. xico 54 11.02.19 13:32 Сейчас в теме
36. AzagTot 37 14.02.19 19:56 Сейчас в теме
Не рассматривали возможность создания подобной доработки (или перевода этой) в виде расширения конфигурации?
37. alexeyvs77 20 14.02.19 21:35 Сейчас в теме
(36) Хорошая идея. Как только придётся внедрять это на типовой конфигурации, именно так и сделаю
38. alexeyvs77 20 14.02.19 21:37 Сейчас в теме
(36) Хотя... Все равно придется снимать с поддержки. Разработка использует свой справочник, свой регистр сведений. Так что, думаю, смысла в этом нет
39. AzagTot 37 15.02.19 00:15 Сейчас в теме
(38) Можно в расширение добавить справочник и РС.
40. alexeyvs77 20 15.02.19 11:44 Сейчас в теме
(39) в расширение, похоже, нельзя добавить подписки на события. Точнее, добавить можно, но только из основной конфигурации.
41. AzagTot 37 15.02.19 18:59 Сейчас в теме
(40) Да, свои подписки нельзя добавить в расширение, к сожалению, можно только заимствовать существующие в конфигурации.
Из-за этого практически не возможно будет сделать универсальное расширение. При этом, под конкретную конфигурацию сделать расширение из вашей подсистемы будет возможно, хоть и с частичной потерей функциональности.
42. xico 54 19.02.19 11:13 Сейчас в теме
После установки системы стали часто появляться ошибки блокировки
43. alexeyvs77 20 19.02.19 11:58 Сейчас в теме
44. alexeyvs77 20 19.02.19 12:00 Сейчас в теме
(42) Какая конфигурация, сколько пользователей и какие именно блокировки?
45. xico 54 19.02.19 12:23 Сейчас в теме
Конфа "Управление торговлей", редакция 10.3 (10.3.49.4)
Пользователей примерно 15. Блокировки возникают при проведении реализации (реализаций довольно много).
Возникает ошибка "Конфликт блокировок при выполнении транзакции". При этом соединение у пользователя захватывает СУБД, и так и висит. Пока не сбросишь соединение, у всех возникают аналогичные ошибjav * ascript:void(0);ки. Пока я не копался что именно там происходит
46. alexeyvs77 20 19.02.19 12:59 Сейчас в теме
(45) Хм... не сталкивался с подобными ошибками. Тем более, что пользователей всего 15.
А заблокирована именно реализация? Или рег. сведений.Логирование?
47. xico 54 19.02.19 13:54 Сейчас в теме
49. alexeyvs77 20 21.02.19 16:54 Сейчас в теме
(47) Доработал. Прописал блокировки при записи регистра
48. alexeyvs77 20 19.02.19 15:38 Сейчас в теме
Ну, значит надо с управляемыми блокировками поэкспериментировать.
Займусь на досуге
50. xico 54 22.02.19 15:16 Сейчас в теме
Спасибо! поставил версию с блокировками, вроде пока ошибок не было
51. Demosm 02.04.19 07:55 Сейчас в теме
Если не выполнять пункты настройки 2 и 3 - тогда как это работает? Сейчас дает ошибку:

{РегистрСведений.Логирование.МодульМенеджера(1278)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (ADODB.Recordset): Невозможно использование подключения для выполнения операции. Оно закрыто или не допускается в данном контексте.
52. alexeyvs77 20 02.04.19 12:28 Сейчас в теме
(51 в какой момент возникает эта ошибка?
При открытии журнала? или в какой-то другой?
53. alexeyvs77 20 02.04.19 15:16 Сейчас в теме
И еще: как именно "дает ошибку"? Возможно, в случае отсутствия подключения к sql, такой текст выводится в окне сообщений. Но при этом, алгоритм отрабатывает нормально
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Специалист техподдержки 1С
Иркутск
зарплата от 28 000 руб. до 34 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 48 000 руб. до 96 000 руб.
По совместительству

Программист 1С
Ставрополь
зарплата от 40 000 руб. до 60 000 руб.
Полный день

Программист 1С
Благовещенск (Амурская область)
зарплата от 40 000 руб. до 70 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб. до 150 000 руб.
Полный день