Как работают управляемые блокировки

29.04.19

База данных - HighLoad оптимизация

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

Казалось, о работе сервера 1С и механизма блокировок за годы разработки уже знаешь всё, но 1С не перестаёт удивлять. Механизм управляемых блокировок создан 1С для того, чтобы по сути полноценно заменить механизм транзакционных блокировок на уровне сервера СУБД, отчасти из за политики "1С работает с любыми СУБД". Но на самом деле всё получилось не совсем так - далее проведём "лабораторную работу", и сделаем из неё выводы - в лучших традициях школьной физики :).

Итак начнём - простой кейс:

Конфигурация 2 объекта РС и Документ.

Конфигурация

Регистр сведений независимый, код следующий:

Блок кода 1

	Если Блокировать Тогда		
		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();
	КонецЕсли;
	
	Если ЧитатьЗапросом Тогда		
		Запрос = Новый  запрос();
		Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
		ТЗ = Запрос.Выполнить().Выгрузить();
	КонецЕсли;

	Если ЧитатьНабор Тогда		
		Набор = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
		Набор.Прочитать();
	КонецЕсли;

	Если ЗаписатьНабор Тогда		
		Запись = набор.Добавить();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес = 3;	
		Набор.Записать();
	КонецЕсли;

Всё предельно просто.

Теперь Запускаем два сеанса.

Сеанс 1: Проводим документ с галкой "Блокировать". Ставим точку останова на строке:

"Если ЧитатьЗапросом Тогда".

Сеанс 2: Проводим документ с галкой "Читать запросом". 

Внимание вопрос: "Проведётся ли документ во втором сеансе или нет?"

Нам бы очень хотелось чтобы ответ на данный вопрос был "нет".

Тем не менее, документ проводится - без особых проблем.

 

Повторяем эксперимент - только во втором сеансе ставим галку "чтение набора"

Тот же вопрос "Проведётся?"

Очевидный ответ - "Конечно", ведь по сути что там что там чтение всего регистра.

Тем не менее наблюдаем примерно следующую историю: 

Конфликт блокировок

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

Спойлер - эти тесты проводим пока в режиме "клиент-сервер".

Из эксперимента выше сделаем несколько первых выводов:

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Вывод 2: Объектное чтение и чтение запросом работает по разному

 

Тут можно сказать: "здравствуй фантомное чтение, неповторяющееся чтение". От "Грязного чтения" нас убережет MS SQL: в уровне изоляции READ COMMITED SNAPSHOT "грязное чтение" невозможно. Хотя я тоже сомневаюсь, потому как объектная модель 1С не полностью отражается в СУБД возможно могут быть нюансы, но примеров подобрать пока не удаётся.

 

Для того, чтобы понять на каком этапе своего развития в платформе 1С потеряли требование "согласованности данных" обратимся к истории.

Попробуем выполнить следующий код в разных версиях платформы:

 

Блок кода 2

	Запрос = Новый Запрос;
	Запрос.Текст = "ВЫБРАТЬ
	               |	СУММА(РегистрСведений1.Рес) КАК Рес
	               |ИЗ
	               |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1
	               |
	               |ДЛЯ ИЗМЕНЕНИЯ";
	Выборка = запрос.Выполнить().Выбрать();
	Выборка.Следующий();
	Количество = Выборка.Рес;
	
	
	
	Если Количество > 0 Тогда
		
		Запись = РегистрыСведений.РегистрСведений1.СоздатьМенеджерЗаписи();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес  = -1;
		Запись.Записать();
			
	КонецЕсли;

 

Я специально избегаю регистров накопления в примерах, потому как в РН как минимум две таблицы на уровне СУБД, а хочется продемонстрировать на одной.

Этот код выполняется в транзакции - в обработке проведения документа в моём случае. Первую транзакцию нужно конечно остановить и попытаться провести вторую. По условию мы не должны уйти в минус.

 

1С 8.1  и ранее (ну или просто Автоматический режим блокировки)   

второй документ "висит на блокировке". После прохождения точки останова второй документ проводится, запись в РС не создаётся.

Код отрабатывает правильно как в случае остановки "после записи" так и в случае "после чтения".

Секрет конечно в инструкции "для изменения", которая кроме всего прочего превращает S блокировку в U.

На уровне СУБД уровень изоляции MS SQL - SERIALIZABLE. MS SQL блокирует всё что надо и не надо. Чтобы получить несогласованные данные  надо очень постараться.

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

 

1С 8.2 и первые версии 8.3 (режим управляемых блокировок)

Появились "Управляемые блокировки". Самое главное что происходит с MS SQL при установке "управляемой блокировки" - уровень изоляции становится "READ COMMITED". 

Чтобы включить его в последних редакциях 8.3 нужно выполнить:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT OFF
GO

Здесь уже немного похуже. Если точку останова в коде поставить после записи - всё отработает как и в предыдущем примере - транзакция установит X блокировку и всё будет OK. А вот если точку останова поставить после чтения - получим совместимые S блокировки - одна и та же информация будет считана двумя транзакциями.

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

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

Конечно нужно добавить в этот код начало вроде:

		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();

и нам уже ничего не страшно.

Зачем я тогда делаю на этом акцент?

В данном примере вы читаете остатки (по сути) - их конечно нужно блокировать.

Но если у вас в транзакции происходит чтение элемента справочника, который в данный момент может изменять другая транзакция?

Вот тут как раз S блокировка очень сильно пригодилась бы. Но об этом дальше.

 

Современные версии 1С 8.3

Возвращаем обратно режим версионника:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT ON
GO

Выполняем код - получаем "-1" как в случае установки "точки останова" при чтении, так и в случае установки "точки останова" при записи.

Теперь можно сделать ещё один вывод:

Вывод 3: чем современнее версия 1С, тем больше возможности для параллельной работы и тем меньше шансов обеспечить согласованность данных.

 

А теперь "Гвоздь программы": файловая база - код приведенный в блоке кода 1 выполняем в ней. Единственное изменение - код чтения данных из регистра придётся перенести в обработку, т.к. в файловой базе два одинаковых документа параллельно провести не получится.

В обработке будет код:

      НачатьТранзакцию();
	  	 	Запрос = Новый  запрос();
			Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
			ТЗ = Запрос.Выполнить().Выгрузить();
	  ЗафиксироватьТранзакцию();

В документе ставим галку "блокировать" и точку останова, выполняем обработку - уверенно висит на блокировке. 

Убираем галку "блокировать" в документе (но не точку останова) конечно без проблем читает регистр.

Итак, в завершение "чудес" управляемых блокировок получаем их разную работу в файловой и клиент-серверной версии.

Вывод 4: Управляемые блокировки в файловой и клиент-серверной версиях работают по-разному. В файловой - "нормально".

 

Теперь о косяках в типовых. Для примера возьму УТ 11.

Перед записью в набор движения естественно читаются, происходит это в функции "ТекстЗапросаТаблицаТоварыНаСкладах(Запрос, ТекстыЗапроса, Регистры)" - для Товаров на складах. 

Так вот, "косяк" потенциально будет во всех строчках этого запроса где "точка" фигурирует дважды:

"КОГДА ЕСТЬNULL(ТаблицаТовары.Назначение.ДвиженияПоСкладскимРегистрам, ЛОЖЬ)"

"И (НЕ ТаблицаТовары.Склад.ИспользоватьОрдернуюСхемуПриОтгрузке

И ТаблицаТовары.Номенклатура.ТипНоменклатуры В"

Что в этом плохого? 

Ну вот представьте - начали вы проведение документа пока склад ещё был не ордерным, а в процессе проведения кто-то его поменял на ордерный...

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

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

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

"Эти справочники защищены от изменений, не так всё просто" - напрашивается комментарий. На самом деле всё просто. Распределенная база, полный обмен. Задано небольшое число элементов в транзакции. В каждом справочнике есть код:

Процедура ПередЗаписью(Отказ)

	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;

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

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

К слову, реально это нужно только для проведения - в других случаях необходимость что-то блокировать сомнительна.

Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

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

Почему на это не особенно обращают внимание? Да потому что эти ошибки видны только в случае реальной параллельной работы большого количества пользователей, да и то крайне редки. Если у вас много пользователей в базе 1С, у вас скорее всего наберётся несколько куч проблем более актуальных, чем описанный выше кейс. Ну а у кого всё хорошо и все вопросы решены скорее всего уже правильно расставлены блокировки, и такие крупные компании редко работают на типовых базах. Но вообще знать о таком "поведении" платформы нужно, как и учитывать его в проектах, которые ориентированы на большое количество параллельно работающих пользователей. Ведь пока мы (1С-ники) не научимся корректно работать с системами, в которых 1000+ активных пользователей и обеспечивать в них согласованность данных SAP нам на рынке не подвинуть. 

P.S. Всё описанное выше "не баг а фича", вполне нормально документировано на ИТС, который всё равно никто не читает  на котором вы можете детально ознакомиться с описанием работы управляемых блокировок "от Вендора" https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000535 

P.P.S. Если это прочитают коллеги из 1С - тут нет "камня в огород типовых" или в сторону реализации управляемых блокировок (хотя конечно хм...). Из статьи выше должно по задумке стать очевидным, что прикладным разработчикам очень не хватает возможности выбирать уровень изоляции с которым будет начинаться транзакция (в т.ч. неявная). READ COMMITED для проведения документов списания товара это слишком лайтово. Всех косяков, с этим связанных, не выловить.
 

Управляемые блокировки

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2972    spyke    26    

42

Быстродействие типовой 1С

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

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5105    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7632    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5975    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8862    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5104    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16181    skovpin_sa    14    

98
Отзывы
177. kolya_tlt 86 08.05.19 15:53 Сейчас в теме
Люто плюсую по выводу №5. Но моя практика показала, что платформа просто не справляется с таким количеством блокировок. Сервер 1С просто ложился каждые два часа. Кейс был абсолютно такой же - движения документа зависели от галок номенклатуры и мы блокировали ссылки номенклатур документа, который проводится. Пришлось от этой идеи отказаться :(
acanta; comol; +2 Ответить
165. alex_sh2008 4 07.05.19 18:35 Сейчас в теме
(164)Уровни изоляции уже есть в скл сервере, в 1С достаточно просто транслировать объектные блокировки на реляционную базу, а то что сейчас сделали мне вообще не понятно.
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
100. spacecraft 06.05.19 16:40 Сейчас в теме
(99) э... версия СУБД это не только версия внутри mssql, это и postgree и oracle и т.д.
Если делать под каждую, то там такой бардак начнется. Тут в версиях платформы багов предостаточно, что бы еще и в версиях СУБД отлавливать.
101. comol 5051 06.05.19 16:41 Сейчас в теме
(98) Да. Нормальная система, ориентированная на параллельную работу и согласованность данных должна быть оптимизирована под конкретную СУБД - чудес не бывает. Можно одну конфу но два набора кода :)
104. spacecraft 06.05.19 16:44 Сейчас в теме
(101) если задействовать полностью все возможности конкретной СУБД, то при переносе на другую будут такие сложности, особенно если сильно переделанная конфа или самописка, то мало не покажется. Помимо сертификации 1С нужна будет полная сертификация на конкретные СУБД. Это увеличение стоимости владения. Полный проигрыш той же SAP, куда 1С стремится.
106. comol 5051 06.05.19 16:49 Сейчас в теме
(104)
Полный проигрыш той же SAP,
В последней SAP одна СУБД. Да и в предпоследней была одна :))).
Если система хорошо работает под одной СУБД - накой её переносить на другую?
107. spacecraft 06.05.19 16:51 Сейчас в теме
(106) я думал это очевидно. Захват рынка с более низшей нишей владея, с постепенным выдавливанием. Классика жанра.
108. comol 5051 06.05.19 16:53 Сейчас в теме
(107) Может. Не возьмусь рассуждать про маркетинговую составляющую. Но техническая из за этой истории получилась голимой.
109. spacecraft 06.05.19 16:57 Сейчас в теме
(108) предположим, 1С создала платформу с поддержкой той же СУБД Oracle. Каковы шансы, что на нее перейдут с SAP? Стоимость? Вряд ли. Сразу сделать продукт в разы лучше чем SAP вообще не реально. Плюс переучивание специалистов. Не вариант.
Только тихим сапом постепенного внедрения на рынок с более-менее конкурентным предложение и увеличением возможностей.
Что там будет далее, трудно сказать. Возможно будет более ориентированный подход, а последние возможности СУБД. Поживем, увидим.
116. acanta 06.05.19 17:47 Сейчас в теме
Огромное спасибо всем за статью и участие в обсуждении. Разложили по полочкам как для блондинок.
110. acanta 06.05.19 17:03 Сейчас в теме
(107) этот рынок уже захвачен ГИС Меркурий, егаис, офд...
113. spacecraft 06.05.19 17:05 Сейчас в теме
(110) вот только не надо сравнивать несравнимые вещи. Во всяком случае егаис и офд это из другой оперы.
103. comol 5051 06.05.19 16:43 Сейчас в теме
(96) А мне и не нужен весь спектр поддерживаемых СУБД... ИМХО это глупость и тупиковый путь
114. spacecraft 06.05.19 17:14 Сейчас в теме
(103) кстати. Если о чем-то говорит EF из C#, то ничего не напоминает?
102. herfis 498 06.05.19 16:42 Сейчас в теме
(93) Извините, но у нас с вами диаметральное расхождение во мнении "кто лучше изучил матчасть". Раз "не в коня корм", не вижу смысла продолжать.
105. comol 5051 06.05.19 16:48 Сейчас в теме
(102) Оу, вижу обиду. Сорри не хотел. Ну просто надо это знать, иначе так и будем писать "абы чо, да кабы как" :(.
111. herfis 498 06.05.19 17:04 Сейчас в теме
(105) Ок. Еще одна попытка :)
Смотрите - в блокировках СУБД нет ничего волшебного и они вовсе не так супер-оптимальны, как вы пытаетесь тут представить. Главная проблема - они накладываются без понимания бизнес-логики, которая есть у приложения. И за это приходится платить. Лучше всего зарекомендовал себя Repeatable Read при чтении в версионниках, потому что решает большинство проблем автоматически тупо за счет MVCC. Но все что выше - вовсе уже не так гладко работает. В реальных системах с требованиями по параллельному доступу практически никто не работает на SERIALIZABLE - слишком накладно. Всегда пытаются разрулить архитектурно, с учетом бизнес-логики конкретного приложения. 1С себе такое позволить не может - это платформа для СОЗДАНИЯ программ. И поэтому в общем случае проведение по регистрам требует именно SERIALIZABLE. Если вы пропустили всю эпопею с тем, что при этом происходит - потрудитесь восполнить :)
comol; spacecraft; acanta; +3 Ответить
118. comol 5051 06.05.19 17:52 Сейчас в теме
(111)
И поэтому в общем случае проведение по регистрам требует именно SERIALIZABLE


Ну наконец то видимо меня поняли! Браво коллега.
Именно об этом и писал в статье и комментах. Чудес не бывает.
А теперь ещё признайтесь что в (91) написан бред, о чём я вам и написал в (93).
120. herfis 498 06.05.19 17:57 Сейчас в теме
(118) Если вы это понимаете, то я решительно не понимаю, почему вы не понимаете все остальное. А в (91) написано тоже самое.
Если вас сбила с толку фраза "Уровень изоляции - это те же самые блокировки", то подразумевалось что уровни изоляции - всего лишь политики использования блокировок (в блокировочнике).
123. comol 5051 06.05.19 18:04 Сейчас в теме
(120)
уровни изоляции - всего лишь политики использования блокировок (в блокировочнике).

Уже лучше... Почти что правда.

Продолжим. Управляемые блокировки - хороший универсальный инструмент? Или в СУБД блокировки реализованы лучше?
112. spacecraft 06.05.19 17:04 Сейчас в теме
(105) просто у вас разная точка зрения на проблему. У Вас хорошие знания конкретной СУБД, но не допонимание объекта УправляемыеБлокировки.
115. comol 5051 06.05.19 17:43 Сейчас в теме
(112)
но не допонимание объекта УправляемыеБлокировки
Ну ещё один "обвинитель" меня такого недопонимающего :))))) Хоть бы в профиль заглянули товарищи :)
117. spacecraft 06.05.19 17:50 Сейчас в теме
(115) я сужу по вашим высказываниям в данной теме. Мне надо проигнорировать ваши высказывания здесь и прошерстить весь интернет? Увольте.
119. comol 5051 06.05.19 17:53 Сейчас в теме
(117) Какое из моих высказываений показалось вам некорректным с точки зрения понимания механизма работы управляемых блокировок? Где я ошибся?
121. spacecraft 06.05.19 18:01 Сейчас в теме
(119) Вы зациклились на конкретной версии mssql и не желаете видеть ничего другого.
122. comol 5051 06.05.19 18:02 Сейчас в теме
(121) А как это связано с "моим пониманием объекта УправляемыеБлокировки" (оригинальное написание сохранено)? :)))

Троллинг?
124. spacecraft 06.05.19 18:05 Сейчас в теме
(122) наверно просто недопонимание, что вам пытаются объяснить. Унификация работы с разными СУБД.
125. comol 5051 06.05.19 18:20 Сейчас в теме
(124) мне этого не надо объяснять. Я пишу о том что унификация работы с разными СУБД отбрасывает 1С назад и приводит к потере качаства решений. Это важно понимать любому 1С-нику. Да и знать СУБД под которую пишешь тоже надо. В нормальных системах такая унификация - миф. В 1С это почти поняли, надо сделать ещё чуть чуть усилий...
126. acanta 06.05.19 18:27 Сейчас в теме
Имхо это показатель хорошего качества типовых. Раньше франчайзи разворачивали такую сеть и такую СУБД как им удобно и устанавливали собственную разработку, уже адаптированную под нее.
Типовые конфигурации были исключительно нагрузкой в коробке к платформе или каркасом для разработки франчайзи и устанавливались в чистом виде редко.
Сейчас они настолько хороши, что выбор между типовой и оптимизированным решением часто не в пользу последнего в первую очередь с точки зрения запуска в работу.
127. spacecraft 06.05.19 18:30 Сейчас в теме
(125) судя по всему про EF не в курсе. Унификация тоже имеет права на существование, даже в ущерб использования некоторых возможностей.
Вот представьте себе.
1С оставляет платформу только с поддержкой mssql 2008. На сколько будет падение спроса?
Ок. Хорошо. Часть бизнеса купила и пользуется.
Далее обновление платформы и требование использовать теперь mssql 2012. Бизнес скрепя зубами приобретает обновление до нужной версии.
Далее 2014, 2016 и т.д. С какого момента бизнес пошлет этот продукт в утиль?
Тут надо исходить из потребности бизнеса, а не тех. возможностей, которые постоянно обновляются.
Бизнесу главное удовлетворение текущим состоянием. Если продукт от 1С это удовлетворяет с текущими блокировками, то нет смысла что-то кардинально переделывать в угоду менее 1%.
Это конечно не означает, что нужно останавливаться. Ведется работа по увеличению возможностей и производительности. Но в первую очередь конечно определяются конкуренты, чтобы не переманили к себе и урвать кусок пирога у других.
А технология ради технологии бизнес не интересует.
128. acanta 06.05.19 18:47 Сейчас в теме
(127) т.е. если обновление платформы 1с теоретически будет совмещаться с обновлением СУБД и грубо говоря включаться в стоимость коробки или вместо ИТС предусматривать покупку обновлений ( о чем тоже много говорят), то архитектуру придется менять уже по совершенно другим причинам.
130. spacecraft 06.05.19 19:00 Сейчас в теме
(128) даже если будет реализована прямая поддержка работы с конкретной СУБД на уровне платформы и переделывать конфигурацию не потребуется, то включать стоимость в обновление 1С просто не имеет смысла. Там несколько видов лицензий. Да и обновления самой СУБД будет довольно высокой. Там цены могут быть несколько килобаксов (если не десятков).
Да и сама процедура каждый раз обновлять СУБД не самая простая.
129. comol 5051 06.05.19 18:55 Сейчас в теме
(127) Я о другом. Я о том что "1С файловая" и "1С Клиент-Сервер" это разные платформы и под них нужны разные типовые и развиваться они должны отдельно...

Нельзя как говориться и рыбку съесть и .... (далее по тексту).

Мелкий и средний бизнес конечно текущая ситуация удовлетворяет. Но мне, если честно, абсолютно чхать с большой колокольни на мелкий и средний. Ситуация такова что в РФ его не так много, а бабки крутятся в крупном бизнесе... а мелкий скоро весь "уедет в облака".

И никому эта вся история "одна платформа - разные СУБД" будет не нужна. Всем нужно будет чтобы "всё хорошо и качественно работало", а софт и железо найдём какие нужно (справедливо для облачных решений и крупного бизнеса).

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

Поэтому я тута и переписываюсь на эти важные, на мой взгляд, темы. Потому что всё равно в 1С инфостарт читают, глядишь что-то и "пролетит" как с RCSI было.
131. spacecraft 06.05.19 19:08 Сейчас в теме
(129) я это уже понял (об этом и говорил выше). Но не согласен. Меня устраивает текущее положение с разными СУБД. Возможно Oracle пока не интересна. А вот то что файловая и sql база поддерживаются одного стандарта меня вполне устраивает (конечно со знанием фиксированных отличий). Программировать на файловой быстрее и удобнее мне лично и уже готовые изменения через хранилище конфигураций вносить в рабочую на sql. Удаленно работать так проще.
132. comol 5051 06.05.19 19:32 Сейчас в теме
(131) Я в этом отношении конечно по-другому мыслю... для меня принципиальны контуры Dev, Test, Stage. Каждый из них должен быть максимально приближен к Production. Моя практика показывает что тут "лучше по книжке". Соответственно контур разработки должен быть приближен к Production, поэтому разрабатывать на файле - зло злушее... хотя это ИМХО конечно.
starik-2005; +1 Ответить
133. spacecraft 06.05.19 19:43 Сейчас в теме
(132) test вполне допускаю на приближенной к prod. Особенно если нужно отладить сложный запрос на большом объеме данных. А зачем dev обязательно на такой же?
134. comol 5051 06.05.19 19:46 Сейчас в теме
(133)
А зачем dev обязательно на такой же

А как косяки разбирать если на test воспроизвелись а у разработчика нет? В конце концов как нагрузку воспроизводить? Как многопользовательскую работу отлаживать? В конце концов если prod весит > 1 TB что делать? Если на Test кодить то test это dev...
135. spacecraft 06.05.19 19:47 Сейчас в теме
(134) спорный момент. В каждом варианте есть свои плюсы/минусы.
136. alex_sh2008 4 07.05.19 11:48 Сейчас в теме
(131)
А вот то что файловая и sql база поддерживаются одного стандарта меня вполне устраивает (конечно со знанием фиксированных отличий).

Мне трудно представить, как можно разработать эффективный код на двух разных по своему функционалу типов баз. Файловая база уровень блокировки на таблицу, sql база уровень блокировки - запись.
137. spacecraft 07.05.19 11:54 Сейчас в теме
(136) в большинстве случаев код не упирается в особенности блокировок. Если понимать общую структуру и возможности, то это не мешает. Естественно тестирование нужно проводить на полноценной системе.
Можно вести и в пустой базе mssql. И так же пролететь. Объем данных другой. Если же вести разработку с базой под TB, то это уже мазохизм. Так что в любом случае последующие тестирование на больших данных никто не отменял.
138. acanta 07.05.19 11:54 Сейчас в теме
(136) так типовые пишут два и более варианта исполнения каждого модуля именно с учётом режима запуска. Вопрос в том, что останется от этой красоты и универсальности при первой же доработке.
139. alex_sh2008 4 07.05.19 11:57 Сейчас в теме
(138)Остается то что мы имеем сейчас, конфигурации девелопер, и для того что бы заставить такую конфигурацию хоть как то работать в продакшин, надо ее переписать
84. herfis 498 06.05.19 12:33 Сейчас в теме
И да - это автоматически приводит к тому, что при чтении запросом данных, влияющих на алгоритм проведения, на эти данные нужно обязательно наложить сначала управляемую блокировку. Я думал, это и так все знают. У того же Чистова это было неплохо расписано: https://1c.chistov.pro/2013/07/blog-post_25.html
При "классической" партионке у него перед чтением себестоимости запросом накладывается управляемая блокировка на товары, по которым будет выполняться чтение и описывается, зачем это нужно. Без этих знаний, насколько я понимаю и сертификацию пройти нельзя.
90. comol 5051 06.05.19 13:14 Сейчас в теме
(84) дело в том что не все понимают что НЕ только на эти данные. Это конечно всё уже расписано, просто "дьявол скрыт в деталях"
140. acanta 07.05.19 12:01 Сейчас в теме
Судя по всему, сертификат DBA разработчик должен получать до сдачи спеца по платформе. Я надеюсь что хотя бы профильные вузы дают достаточно для его получения.
141. starik-2005 3033 07.05.19 16:22 Сейчас в теме
(140)
Я надеюсь что хотя бы профильные вузы дают достаточно для его получения.
Профильные ВУЗы в лучшем случае дадут представление о том, где искать, что искать и как это делается. К моменту окончания "профильного" ВУЗа, в котором какое-то обучение СУБД может основываться на чем-то типа Acсess от мелкомягких или Delphi с interdb лохматых годов (или, в лучшем случае, My SQL с бэкэндом на питоне), знания студента уже 10 лет как неактуальны, а за 10 лет в IT-сфере тысячелетия проходят.
142. TODD22 18 07.05.19 16:31 Сейчас в теме
(141)
К моменту окончания "профильного" ВУЗа, в котором какое-то обучение СУБД может основываться на чем-то типа Acсess от мелкомягких или Delphi с interdb лохматых годов (или, в лучшем случае, My SQL с бэкэндом на питоне)

И что там в теории реляционных БД сильно изменится за это время? Типы данных колонок таблиц, связи, нормализация?
143. starik-2005 3033 07.05.19 17:06 Сейчас в теме
(142) NoSQL, например. Работа оптимизатора, хинты (которые в 1С используются от слова никак), шардинг, репликация, снапшоты, ... Да вот даже в 1С поведение меняется, а народ никак угнаться не может.
144. comol 5051 07.05.19 17:22 Сейчас в теме
(143) сорри что вмешиваюсь а как всё вышеперечисленное относится к
теории реляционных БД
?
145. starik-2005 3033 07.05.19 17:24 Сейчас в теме
(144) оптимизация и хинты - прямо, носкул - опосредованно, ибо объектная модель медленно и верно заходит в реляционную. Шардинг, реплика, снапшоты и прочее - это механизмы повышения доступности данных, а данные - это продукт теории реляционных баз.
146. TODD22 18 07.05.19 17:37 Сейчас в теме
(145)Вы теорию БД с конкретной реализацией механизмов не путаете?
147. starik-2005 3033 07.05.19 17:38 Сейчас в теме
(146)
Вы теорию с конкретной реализацией не путаете?
А, Вы об этих отношениях первичных ключей к множеству и всему такому прочему? И помогает эта теория в создании конкретной реализации? Как? (всегда интересовался, кстати)
148. TODD22 18 07.05.19 17:41 Сейчас в теме
(147)
И помогает эта теория в создании конкретной реализации?

мы вроде про обучение в ВУЗах основам теории БД.
Что 10 лет назад была теория БД, что сейчас и саму теорию можно учить хоть на листочке в клеточку, хоть на Access, хоть на MS SQL.
151. starik-2005 3033 07.05.19 17:45 Сейчас в теме
(148)
мы вроде про обучение в ВУЗах основам теории БД.
Кто "Вы"?
Аня Ж. в (140) пишет, что , предположительно, в ВУЗе дают столько знаний чтобы получить сертификат DBA, а это ни разу не теория реляционных БД - это знание конкретной реализации. На что я говорю, что программа устарела еще до поступления в ВУЗ, а Вы тут вставляете про условно нужную всем теорию этих самых реляционных баз, которую в ВУЗе худо-бедно студенту дали (что-то на уровне того, что в двоичном дереве индекса можно найти ключ за не более, чем log2(N)). И студенту это, конечно, может помочь ответить на парочку вопросов теста DBA, но остальные вопросы будут совершенно не о том.
153. TODD22 18 07.05.19 17:48 Сейчас в теме
(151)А если 140 тогда да... Про DBA как то пропустил.
149. TODD22 18 07.05.19 17:42 Сейчас в теме
(147)
(всегда интересовался, кстати

Наверное гугл сможет удовлетворить Ваш интерес.
152. starik-2005 3033 07.05.19 17:46 Сейчас в теме
(149)
Наверное гугл сможет удовлетворить Ваш интерес.
Да я ужепонял, что удовлетворить интерес Вы в принципе неспособны )))
155. TODD22 18 07.05.19 17:50 Сейчас в теме
(152)Вы вот ленились в гугле посмотреть предобработку данных, но утверждали что гугл ваш интерес не удовлетворил, но вам очень интересно. Полагаю что если было бы интересно погуглили бы самостоятельно.
156. starik-2005 3033 07.05.19 17:52 Сейчас в теме
(155)
Полагаю что если было бы интересно погуглили бы самостоятельно
Так я уже давно в теме. Вот тут, например, добрые и, возможно даже умные люди пишут следующее:
Извлекайте все данные которые можно извлечь, но руководствуйтесь здравым смыслом.
Не пытайтесь включать эксперта, преждевременно удаляя признаки.
157. TODD22 18 07.05.19 17:55 Сейчас в теме
(156)
Извлекайте все данные которые можно извлечь, но руководствуйтесь здравым смыслом.
Не пытайтесь включать эксперта, преждевременно удаляя признаки.

Ну и? Пишут молодцы. Какое отношение это имеет к тому что я писал?
158. starik-2005 3033 07.05.19 18:00 Сейчас в теме
(157)
Какое отношение это имеет к тому что я писал?
Вот и я про то же самое - часто не нужно ничего подготавливать - просто бери и кидай в топку ИИ.
161. TODD22 18 07.05.19 18:05 Сейчас в теме
(158)
Вот и я про то же самое - часто не нужно ничего подготавливать - просто бери и кидай в топку ИИ.

Вы видимо не до конца понимаете те две строчки что привели и что такое предобработка. Перечитайте несколько раз медленно и подумайте.
163. comol 5051 07.05.19 18:25 Сейчас в теме
(145)
данные - это продукт теории реляционных баз.

Ну вообще теория реляционных баз это о нормальных формах, доказательство их корректности, теоремы, отношения... Т.е. там как бы больше математики в принципе. Оно не про данные.
167. starik-2005 3033 07.05.19 20:06 Сейчас в теме
(163) все это - доказательства теорем о всяковской твм их "нормальности" без оперирования данными - просто абстрактный слой формул. Эти формулы для оперирования данными как используются? Может быть вычисляют минимально нужную для запроса операцию чтения? Может они помогают найти лучший - быстрый - вариант обращения к данным? Неа. Они постулируют свойства реляционных отношений и, собственно, все. Хотя с удовольствием послушаю, что там еще есть - ну разьвыдалась честь общаться с людьми, в этом понимающими.
172. TODD22 18 07.05.19 23:40 Сейчас в теме
(167)
все это - доказательства теорем о всяковской твм их "нормальности" без оперирования данными - просто абстрактный слой формул.

Закон Ома то же абстрактная формула если нужно воткнуть зарядку от телефона в розетку.... Для чего его учат....
150. alex_sh2008 4 07.05.19 17:43 Сейчас в теме
(143)
хинты (которые в 1С используются от слова никак)


Можете назвать применение этих функции применимо для 1С, я не смог ничего придумать?
154. starik-2005 3033 07.05.19 17:49 Сейчас в теме
(150)
этих функции применимо для 1С
Ну как вариант - это выборки с разным уровнем селективности, чтобы в одном случае был скан таблицы (низкоселективный отбор по организации из 99% документов), а в другом - поиск в индексе (для остальных 1% документов организации №2). Сейчас в принципе это тоже можно решить двумя запросами с дополнительным полем, чтобы оптимизатор не брал из кеша "чужой" запрос.
159. alex_sh2008 4 07.05.19 18:00 Сейчас в теме
(154)Добавление хинтов в 1С может только усугубить ситуацию, а не дать преимущество. Да и потом таких задач очень мало, не тот уровень приложений которые пишутся на 1С
160. starik-2005 3033 07.05.19 18:02 Сейчас в теме
(159)
не тот уровень приложений которые пишутся на 1С
Скажите это деловым линиям.
162. alex_sh2008 4 07.05.19 18:21 Сейчас в теме
(160)Ну это им захотело самбичеванием заниматься.
164. comol 5051 07.05.19 18:28 Сейчас в теме
(159)
Добавление хинтов в 1С может только усугубить ситуацию

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

Но к моей идеи о добавлении уровня изоляции это не относится :)
165. alex_sh2008 4 07.05.19 18:35 Сейчас в теме
(164)Уровни изоляции уже есть в скл сервере, в 1С достаточно просто транслировать объектные блокировки на реляционную базу, а то что сейчас сделали мне вообще не понятно.
166. comol 5051 07.05.19 18:43 Сейчас в теме
169. starik-2005 3033 07.05.19 20:09 Сейчас в теме
(165) да, с хиниами соглашусь - не стоит.
168. starik-2005 3033 07.05.19 20:08 Сейчас в теме
(164) как я понимаю, проблема не в том, что это плохо, а а том, что собеседуемые в этом понимают чуть более, чем ничего? Скажу по-секрету, что мреди тех, кто понимает в этом, собеседуемые встречаются примерно 1/25.
170. alex_sh2008 4 07.05.19 21:33 Сейчас в теме
(168)Ну значит и вы не до конца понимаете как работают хинты, реализовать их в 1С можно сказать не реально, для этого придется переделать всю архитектуру движка
171. starik-2005 3033 07.05.19 22:14 Сейчас в теме
(170) так они работают на уровне скульного кода как модификаторы, типа select * ftom a a left join b b on a.id = b.id hint nested loops - типа того чтото. Зарелизить это в 1с - не проблема. Другое дело, что это только с мс скулом работать будет.
173. comol 5051 08.05.19 00:40 Сейчас в теме
(171) В любой СУБД хинты есть в том или ином виде... но в (170) прав. Сделать это будет тяжело - потому как в 1С логическую сущность от физической отделили
175. alex_sh2008 4 08.05.19 08:21 Сейчас в теме
(171)Я не говорил про их применение, а говорил про то как они работают, это фактически низкоуровневые инструкции для планировщика/оптимизатора скл сервера, и работают они только при определенных условиях.
174. comol 5051 08.05.19 00:43 Сейчас в теме
(168) чтобы юзать хинты надо понимать детали как устроен оптимизатор запросов СУБД, При этом не только в конкретной ситуации, а думать что будет под нагрузкой, при эскалации, при разном коилчестве данных в таблицах, неактуальной статистике и т.п.... Вообщем мало я встречал людей кто мог бы этим воспользоваться... очень мало...
176. kolya_tlt 86 08.05.19 15:41 Сейчас в теме
Документ и Регистр сведений - это слишком просто. Попробуйте установить блокировку на регистр бухгалтерии, причём не на весь, а на определённый Счет и на определенные значения видов субконто, например, на номенклатуры документа по 41ому.
177. kolya_tlt 86 08.05.19 15:53 Сейчас в теме
Люто плюсую по выводу №5. Но моя практика показала, что платформа просто не справляется с таким количеством блокировок. Сервер 1С просто ложился каждые два часа. Кейс был абсолютно такой же - движения документа зависели от галок номенклатуры и мы блокировали ссылки номенклатур документа, который проводится. Пришлось от этой идеи отказаться :(
acanta; comol; +2 Ответить
178. comol 5051 09.05.19 12:35 Сейчас в теме
(177) ну вот и практический кейс подъехал, который только ещё больше расстраивает
179. alex_sh2008 4 10.05.19 17:15 Сейчас в теме
(178)Таких примеров можно сколько угодно привести, и так можно бесконечно обсуждать. Какое резюме в итоге?
180. herfis 498 11.05.19 10:33 Сейчас в теме
(179) Что разработчики платформы 1С тупые и не шарят. И мы бы написали гораздо лучше. Если бы умели :)
Что типа надо было автоматически транслировать управляемые блокировки в блокировки СУБД.
А то, во что может превратиться управляемая блокировка по конкретному складу (например), при попытке транслировать ее в блокировки СУБД - никто почему-то задумываться не хочет (или не может).
185. alex_sh2008 4 11.05.19 11:13 Сейчас в теме
(180)
А то, во что может превратиться управляемая блокировка по конкретному складу (например)

Во что может превратится?
187. herfis 498 11.05.19 11:22 Сейчас в теме
(185) Ну смотри.
Допустим, склад у тебя второе измерение в регистре после номенклатуры, без отдельного индекса. Да даже если с индексом. Допустим склада всего два и индекс по нему обладает плохой селективностью. Соответственно оптимизатор почти никогда не будет его применять.
Как наложить по складу блокировку СУБД? Очевидно, нужно сделать отдельный запрос с отбором по этому складу и хинтом нужных блокировок. Мало того, что этот дополнительный запрос сам по себе неэффективен, так он еще с высокой вероятностью вызовет эскалацию блокировок и про параллельное проведение по разным складам можно будет забыть. Управляемые же блокировки отработают мгновенно и не нагружая СУБД.
Идея же интеллектуально впихивать хинты в основной запрос, пытаясь достичь эффекта аналогичного управляемым блокировкам - еще более утопична.
193. alex_sh2008 4 11.05.19 11:40 Сейчас в теме
(187)Как взаимосвязаны между собой индексы и блокировки СУБД?
194. herfis 498 11.05.19 11:52 Сейчас в теме
(193) Вот навскидку: http://www.hardline.ru/2/13/1840/
Не факт, что в (187) будет какая же картина, я не настолько крут в деталях сиквельных блокировок. Просто слышал звон :)
Поэтому в (187) пример неэффективной ситуации, могущей привести к эскалации в любом случае.
195. alex_sh2008 4 11.05.19 11:57 Сейчас в теме
(194)Ну тогда рекомнедую ознакомится как работают блокировки в sql сервер а потом уже делать выводы что к чему приведет.
196. herfis 498 11.05.19 11:58 Сейчас в теме
181. acanta 11.05.19 10:50 Сейчас в теме
(177) вообще, по стандартам разработки в 7ке рекомендовалось все данные, от которых зависит результат проведения, включать в документ.
В крайнем случае использовать периодические реквизиты, если этого требует прикладная задача.
В 8ке регистры сведений влияющие на результат проведения блокировать можно?
Логично что данные, используемые при проведении, на этапе проектирования следует либо отдельным полем сохранять в реквизите документа, либо брать из регистра сведений. РАУЗ разве не так устроен?
182. herfis 498 11.05.19 11:01 Сейчас в теме
(181) Какой смысл блокировать условно-постоянную информацию, влияющую на проведение? Что это даст в реальности? А чем это чревато? Если подумать?
Гораздо лучше, проще и логичнее запрещать обычным пользователям изменять такую информацию, если она может повлечь за собой необходимость перепроведения. Это стандартная практика.
183. acanta 11.05.19 11:07 Сейчас в теме
(182) Вопрос в том, что считать постоянной, а что условно-постоянной. Почему не убрать услуги из справочника номенклатура совсем и не использовать в качестве услуг технологические операции?
Исправление ошибки пользователя и теоретически возможное изменение информации во времени это не одно и то же.
Профилактика гораздо надёжнее чем разделение пользователей на обычных и особенных в рамках единой базы данных.
Разработчик не знает в скольких базах клиентов такое разделение вообще есть, даже если ему этого хочется, а проблема существует в любом случае.
184. herfis 498 11.05.19 11:12 Сейчас в теме
(183)
Вопрос в том, что считать постоянной, а что условно-постоянной.

В смысле? В 1С постоянной инфы практически нет. Те же свойства номенклатуры, могущие влиять на проведение - это условно-постоянная информация. Если ее кто угодно может менять когда угодно, то блокирование ее при проведении никаких проблем не решит, только добавит новые.
186. acanta 11.05.19 11:16 Сейчас в теме
(184) Правильно. Если изменение реквизита номенклатуры настолько критично для работы системы, что вызывает проблему, зачем этот реквизит вообще существует?
188. herfis 498 11.05.19 11:26 Сейчас в теме
(186) Затем, зачем существует учетная политика.
189. acanta 11.05.19 11:28 Сейчас в теме
(188) Ок, зачем существует учётная политика?
190. herfis 498 11.05.19 11:29 Сейчас в теме
(189) Определять политику учета, не?
191. acanta 11.05.19 11:30 Сейчас в теме
(190) что вы под учетом понимаете?
192. herfis 498 11.05.19 11:31 Сейчас в теме
(191) Мы можем долго играть в эту дурацкую игру. Но мне уже надоело.
199. Andreynikus 1361 12.01.21 22:21 Сейчас в теме
> Чтобы включить его в последних редакциях 8.3 нужно выполнить:

Наверное имелось ввиду "вЫключить"
Оставьте свое сообщение