Огромное спасибо за информацию! Думал, что достаточно придерживаться стандартов оптимизации запросов, а тут, как оказалось, не все так гладко когда переходишь на уровень ооочень больших данных. По выборке "В (ВЫБРАТЬ .. ИЗ ...)" в условиях виртуальной таблицы: проверял на записях до 1 млн, там она отрабатывала медленнее, чем внутреннее соединение виртуальной таблицы и таблицы задающей отбор (это при серверной базе). При файловой базе быстрее работает именно "В ()" в условиях. Получается, что при ооочень большом количестве записей серверная база начинает вести себя как файловая база (конкретно в данном примере, хотя может и в других случаях тоже, надо проверять).
На больших выборках лучше заменить В на аналог exists в скуле. Достаточно написать (поле1, истина) В (ВЫБРАТЬ поле1, истина Из..). Тогда 1с оттранслирует запрос в exists,что будет работать в разы быстрее
Мой совет - смотрите это видео целиком, т.к. там где спикер говорит, что нельзя использовать частицу НЕ, В(), ИЛИ это относится к выборкам из больших таблиц (Документов, РС, РН). Дальше уточняется, что НЕ и В() вполне можно использовать в предварительных ВТ, в которых готовим списки для ВНУТРЕНЕЕ СОЕДИНЕНИЕ. Очень полезный материал. Спасибо!
Я вообще никогда не оставлял комментариев ни под каким видео, а тут просто не удержался, хочу написать, точнее даже выразить огромную благодарность за проделанную работу!! Спасибо большое ребят за видео!!
Это шикарное видео! Спасибо Артёму за кейсы. Нельзя просто так взять и написать сразу правильно 😂 А метрики использовать можно👍 Хочу так же😁 Было бы здорово в таком же формате посмотреть про настройку grafana.
Спасибо за видео. Было бы еще интересно рассказать для администраторов как такую базу обслуживают в адекватные сроки. Имею ввиду пересчет статистики, перестроение индексов в SQL. От этого тоже зависит производительность, и на такой базе выполнить это в разумные сроки не всегда просто.
Спасибо большое, за такой замечательный митап. Было очень интересно смотреть!!! Теперь буду ждать митапа по поводу инфраструктуры в данной компании. Как взаимодействуют разработчики между собой, какими приложениями пользуются и т.д.
Ну в целом - требования к запросам дин. списков те же самые. Тут обычно тормозит именно по причине того, что пользователь лезет туда, куда не надо, как при использовании {ГДЕ Поле.* } в СКД. Мы явно даём нужные поля, каждое использование ".*" в тексте запроса - должно быть обосновано разработчиком.
Мы, например, ограничиваем динсписки через ДинамическийСписок.УстановитьОграниченияИспользованияВОтборе и ДинамическийСписок.УстановитьОграниченияИспользованияВПорядке, передавая туда массив только индексированных полей.
Огромное спасибо за видео. Очень хочется прояснить такие вопросы: 1) 45:00 Пусть для примера у таблицы есть кластерный индекс "Измерение1"+"Измерение2". "Измерение1" принимает значения из ограниченного списка (например, перечисление или очень небольшой справочник). "Измерение2" принимает очень большое количество значений и обладает высокой селективностью. Большинство запросов к таблице имеют отбор по полю "Измерение1" плюс ещё что-то (например, "... ПЕРВЫЕ 1000 ... ГДЕ Измерение2 > &Мин ... УПОРЯДОЧИТЬ ПО Измерение2"). Надо улучшить запрос с отбором по некоторым значениям поля "Измерение2". Как лучше это сделать? А) Поменять поля в индексе местами. Насколько испортятся или останутся на прежней производительности большинство запросов? Б) Добавить индексирование по "Измерение2". При этом, скорее всего, новосозданный индекс будет размером в половину от кластерного. В) Сделать отбор по полю "Измерение1" из полного списка значений и отбор по полю "Измерение2". Г) Сгенерировать текст запроса из блоков, связанных через "ОБЪЕДИНИТЬ ВСЕ", и в каждом блоке отбирать "Измерение1" по одному значению. 2) 1:05:30 Вроде бы, как-раз где при количестве записей до 100 или до 1000 (по данным статистики) планировщик MS SQL применит полный обход таблицы независимо от наличия индексов.
Вопрос по примеру "ручного среза последних" (время 1:21:18): Рассматривали вариант помещения во временную таблицу строк с максимальным периодом? Что-то вроде ВЫБРАТЬ МАКСИМУМ(Период), ИДЗвонка ПОМЕСТИТЬ ВТ_СтатусыЗвонков ... СГРУППИРОВАТЬ ПО ИДЗвонка; ВЫБРАТЬ ВТ_СтатусыЗвонков.ИДЗвонка, ЖЗ.Статус ИЗ ВТ_СтатусыЗвонков ВНУТРЕННЕ СОЕДИНЕНИЕ РегистрСведений.ЖурналЗвонков КАК ЖЗ ПО ЖЗ.ИДЗвонка = ВТ_СтатусыЗвонков.ИДЗвонка И ЖЗ.Период = ВТ_СтатусыЗвонков.Период.
Таблица временных индексов всегда скидывается на жесткий диск, что ведет к существенной потере скорости, однако, когда выборка записей больше 8 мб, то временная таблица в любом случае скидывается на хард, поэтому индексы во временных таблицах оправданы только в запросах на выборку больших данных. Если запрос выбирает небольшие данные, использование индексов будет сильно тормозить.
Хочу информации об инструментах, которые рисуют все эти циферки про расходы времени и количества использований... Это какие-то готовые инструменты, или что-то дописывали? Сейчас тоже начинают всплывать вопросы по тормозам и хотелось бы их решать в порядке боли, а не как показалось.
00:30:52 есть где нибудь в литературе почитать, почему не рекомендуется использовать таблицу СрезПоследних у регистра сведений подчиненного регистратору? То есть вообще не рекомендуется использовать или в каких то конкретных условиях? Понятное дело, что могут быть регистраторы составного типа, но какие там соединения происходят при запросе к БД, где можно наглядно посмотреть или прочитать? На ИТС по этому поводу не видел информации. Что тогда использовать в таком случае? Как оратор поступает в данном случае, если ему нужен срез из такой таблицы?
Не хватает планов запросов. @Artem Kuznetsov, не понимаю, почему отрицание преобразуется в оператор "В". У меня такого нет. Запрос "Выбрать Ссылка Из Документ.ЗаказНаряд Где НЕ ВидРемонта = &ВидРемонта" преобразуется в "SELECT T1._IDRRef FROM dbo._Document321 T1 WHERE ((T1._Fld811 = @P1)) AND ((NOT (((T1._Fld2267RRef = @P2)))))", где @P1 - разделитель. Виды ремонта - справочник, с отборами по значению перечислений такое же условие. Используете ли дата акселератор? Если нет, то есть ли планы?
@@yellow_club пока что не все стримы посмотрел) Но на практике были трудности по работе с xdto и http запросами. Возможно эти темы уже есть на канале и я до них просто не добрался. Ещё раз спасибо! По 1с на ютубе не так много каналов. Ваш однозначно в топ3 для меня!
Добрый день, коллеги. Артем к вам вопрос, если это конечно еще возможно, в этом моменте 49:00. Вы уходите от скана кластерного индекса и делаете как бы принудительный Key lookup. Но ведь если поле "Договор" является селективным и у вас актуальная статистика оптимизатор и так должен использовать индекс по полю договор. Разве нет? Не совсем понимаю в чем выгода в этом кейсе, при условии что статистику вы обновляете. Ну и поле Договор очень вероятно, что является высокоселективным. Если конечно в таблице "ВыдачаССостояниями" не 100500 тыщ строк
@@yellow_club На самом деле ничего особенного, это я по вашим видео учусь. Просто фирма резко выросла, а штат ИТ-нет :) С управляемыми блокировками только пришлось тщательно повозиться.
Подскажите при последнем примере условие выносятся в фигурные скобки, это необходимо делать в ответах на скд или в любых запросах? Как понять что объект подключён к РЛС, только посмотрев роли? Заранее спасибо
Люди, сравнивающие, какой язык хороший, как плохой - странные. Работай в том, какой нравится. Мы же не сравниваем сварщика на строительстве домов и сварщика на строительстве судов, потому что все профессии важны
У меня на 8.1 УПП 6,6 Тб. По производительности все норм. Либо ты пишешь сразу хорошо и все летает, либо ты пишешь не правильно и ничего работать не будет. А так Платформа 1С конечно могет!
Легаси код - тяжелая наследственность : ) Устаревший код, который более не поддерживается и не обновляется, но используется. Второе значение - код от сторонних разработчиков, или из старых версий.
Пример с заявками не показательный вообще. Оптимизировать там имело смысл поэтапно - сначала убрать вычисления для начала и конца периода. Ясно что после этого запрос стал бы выполнятся за 1-2 сек. Что-то большие сомнения у меня, что оптимизатор после этого стал бы проверять каждую строку, а не то что было выбрано по периоду. Какой смысл все скидывать в ВТ, если по смыслу потом выполнялась бы та же самая операция, но уже по данным ВТ. Плюс если поле Шаг скорее всего не индексировано. Не надо зацикливаться на правилах. Знать их надо, но периодически подвергать сомнению тоже стоит.
Больно смотреть на это... Базы на 7 Tb с которыми работают по стандартам SQL 92 года, да хотя бы и 92, но там же даже от 92 года только 25% возможностей. Люди вваливают тонны денег в СУБД, железо, а потом ничего кроме SELECT сделать не могут. Все что им дано это кластерный индекс у которого первое поле с нулевой селективностью (разделитель) и .... и все. Героизм в крови, то с гранатой под танк, то вот 7Tb на 1С... Смотрел недавно hi load яндекса, был вопрос: "как вы решаете проблему с большимим базами?" Ответ: У нас нет больших баз, какие то данные лежат в columnstore какие то в mongo, там где требуются реляционные связи используется PG но так что у каждого сервиса своя PG
1С никам это не понять. Реально. Они вот так и пробуют - ковырять в запросах гигабайты информации. И радуются как дети когда через одно известное место получается на секунду ускорить что-то. 10 лет назад это смотрелось ещё ну.. как реалии технологической платформы, сейчас уже как идиотизм.
Херню какую-то написали. Без приведения конкретных примеров для сравнения, ваш комментарий из разряда "мне для моих задач это не требуется, поэтому и вы делайте как я". А я вам скажу, что не на 1С ваша разработка будет стоить в 10 раз дороже.
@@АлексейТ-ю9я Какие примеры вы хотите в комментариях на Ютубе? Что касается "для моих задач" то 1с уже давно позиционируется не как Бух для ларьков а как серьезный универсальный hiload framework. Что касается дороже в 10 раз то дело не в скорости разработки а в том что 1с команды получают меньше ЗП в 3 раза, и сами команда меньше следовательно один человек делает больше работы. И мне как специалисту это сильно не нравится. Я хочу как в нормальном ИТ работать меньше получать больше.
Не претендую на истину, но компоновщик данных в дин.списках и СКД, сам добавляет РАЗРЕШЕННЫЕ в запрос, поэтому в теории это можно не добавлять, но понятно что в этой компании просто такой стандарт, и видимо воизбежании ошибок, что где то в модулях форм или объектов забудут это сделать, добавляют везде
Спикеру надо либо на рашн переходить либо целиком на инглише вещать (хотя, может, это я слишком стьюпид и стар - не секу модерновый спич и факаплюсь как ластовый лузер)
1С и "быстро" это несовместимые вещи. 1С это для людей, которые медитируют. Нельзя сделать быстро из того, что работает изначально медленно. Опыт у меня в оптимизации достаточен. Здесь нет универсального подхода. К решениям в видео и подходах тоже есть претензии, просто вероятно никто не может это доказать (или не хочет). Самое распространенное заблуждение: создаешь ВТ - делай индексы. Ошибочное мнение. Создать индекс на пол миллиарда записей, а потом скуль решает его не использовать в силу своих мыслей и увеличивает время исполнения запроса на создание индекса что очень заметно. Проще пробежать все записи сканом
После фразы "создать индекс на полмиллиарда записей" стоит уже задуматься о том, на кой ляд ты это сделал.. А уже потом решать вопрос, как всунуть это планировщику, чтобы он побыстрее пропихнул этот запрос.
Огромное спасибо за информацию! Думал, что достаточно придерживаться стандартов оптимизации запросов, а тут, как оказалось, не все так гладко когда переходишь на уровень ооочень больших данных.
По выборке "В (ВЫБРАТЬ .. ИЗ ...)" в условиях виртуальной таблицы: проверял на записях до 1 млн, там она отрабатывала медленнее, чем внутреннее соединение виртуальной таблицы и таблицы задающей отбор (это при серверной базе). При файловой базе быстрее работает именно "В ()" в условиях. Получается, что при ооочень большом количестве записей серверная база начинает вести себя как файловая база (конкретно в данном примере, хотя может и в других случаях тоже, надо проверять).
Да, тема оптимизации бесконечна. Было бы что оптимизировать))
На больших выборках лучше заменить В на аналог exists в скуле. Достаточно написать (поле1, истина) В (ВЫБРАТЬ поле1, истина Из..). Тогда 1с оттранслирует запрос в exists,что будет работать в разы быстрее
@@mendicator4319, спасибо! Можете подсказать, в "(поле1, истина) В (ВЫБРАТЬ поле1, истина Из..)" - "Истина" здесь какую роль выполняет?
@@ОлегД-й9ш никакую. Просто заставит оттранслировать запрос не в in(), а в exists()
@@mendicator4319 очень интересно, проверю =)
Мой совет - смотрите это видео целиком, т.к. там где спикер говорит, что нельзя использовать частицу НЕ, В(), ИЛИ это относится к выборкам из больших таблиц (Документов, РС, РН). Дальше уточняется, что НЕ и В() вполне можно использовать в предварительных ВТ, в которых готовим списки для ВНУТРЕНЕЕ СОЕДИНЕНИЕ.
Очень полезный материал. Спасибо!
Я вообще никогда не оставлял комментариев ни под каким видео, а тут просто не удержался, хочу написать, точнее даже выразить огромную благодарность за проделанную работу!! Спасибо большое ребят за видео!!
Рад, что было полезно
Это шикарное видео! Спасибо Артёму за кейсы. Нельзя просто так взять и написать сразу правильно 😂 А метрики использовать можно👍 Хочу так же😁 Было бы здорово в таком же формате посмотреть про настройку grafana.
Стоящее видео! Очень классно и приятно слушать. Бальзам на уши! Палец вверх поставил
Спасибо за видео. Было бы еще интересно рассказать для администраторов как такую базу обслуживают в адекватные сроки. Имею ввиду пересчет статистики, перестроение индексов в SQL. От этого тоже зависит производительность, и на такой базе выполнить это в разумные сроки не всегда просто.
Спасибо большое, за такой замечательный митап. Было очень интересно смотреть!!! Теперь буду ждать митапа по поводу инфраструктуры в данной компании. Как взаимодействуют разработчики между собой, какими приложениями пользуются и т.д.
Мы тоже ждём) но пока ребята не хотят рассказывать)
Ребята, спасибо Вам за проделанную работу
Спасибо
Митап супер!!! 👍👍👍 просто 🔥
Подробно, подготовленно, понятно даже про сложные вещи 🤗
Большое пребольшое спасибо!!!!
Спасибо
Еще б такой же по оптимизации запросов для динамических списков на больших базах 🙃
Ну в целом - требования к запросам дин. списков те же самые. Тут обычно тормозит именно по причине того, что пользователь лезет туда, куда не надо, как при использовании {ГДЕ Поле.* } в СКД. Мы явно даём нужные поля, каждое использование ".*" в тексте запроса - должно быть обосновано разработчиком.
Мы, например, ограничиваем динсписки через ДинамическийСписок.УстановитьОграниченияИспользованияВОтборе и ДинамическийСписок.УстановитьОграниченияИспользованияВПорядке, передавая туда массив только индексированных полей.
Артем, спасибо!
Только включил запись, поставил лайк, спасибо вам за то что вы делаете!
Рад, что полезно 🙏
Огромное спасибо за видео.
Очень хочется прояснить такие вопросы:
1) 45:00 Пусть для примера у таблицы есть кластерный индекс "Измерение1"+"Измерение2".
"Измерение1" принимает значения из ограниченного списка (например, перечисление или очень небольшой справочник).
"Измерение2" принимает очень большое количество значений и обладает высокой селективностью.
Большинство запросов к таблице имеют отбор по полю "Измерение1" плюс ещё что-то (например, "... ПЕРВЫЕ 1000 ... ГДЕ Измерение2 > &Мин ... УПОРЯДОЧИТЬ ПО Измерение2").
Надо улучшить запрос с отбором по некоторым значениям поля "Измерение2".
Как лучше это сделать?
А) Поменять поля в индексе местами. Насколько испортятся или останутся на прежней производительности большинство запросов?
Б) Добавить индексирование по "Измерение2". При этом, скорее всего, новосозданный индекс будет размером в половину от кластерного.
В) Сделать отбор по полю "Измерение1" из полного списка значений и отбор по полю "Измерение2".
Г) Сгенерировать текст запроса из блоков, связанных через "ОБЪЕДИНИТЬ ВСЕ", и в каждом блоке отбирать "Измерение1" по одному значению.
2) 1:05:30 Вроде бы, как-раз где при количестве записей до 100 или до 1000 (по данным статистики) планировщик MS SQL применит полный обход таблицы независимо от наличия индексов.
Ничего не понятно, но очень интересно. Спасибо!
Значит есть куда расти ))
Очень познавательное видео, спасибо!
Работа в качестве хоббито ) Спасибо, было очень интересно
Мне кажется у Артёма есть и другие хобби)) Надеюсь на это)
Точно есть - как минимум исторические реконструкции.
Ага. Сноуборд, лазертаг, настольные игры, компьютерные игры. И еще я учусь играть на ударных :)
Спасибо за видео и за контент в целом! Очень полезно. Взял на заметку. А можно как-то связаться с Артёмом или Дмитрием?
Вопрос по примеру "ручного среза последних" (время 1:21:18): Рассматривали вариант помещения во временную таблицу строк с максимальным периодом? Что-то вроде ВЫБРАТЬ МАКСИМУМ(Период), ИДЗвонка ПОМЕСТИТЬ ВТ_СтатусыЗвонков ... СГРУППИРОВАТЬ ПО ИДЗвонка; ВЫБРАТЬ ВТ_СтатусыЗвонков.ИДЗвонка, ЖЗ.Статус ИЗ ВТ_СтатусыЗвонков ВНУТРЕННЕ СОЕДИНЕНИЕ РегистрСведений.ЖурналЗвонков КАК ЖЗ ПО ЖЗ.ИДЗвонка = ВТ_СтатусыЗвонков.ИДЗвонка И ЖЗ.Период = ВТ_СтатусыЗвонков.Период.
Тоже только к концу присмотрелся, что срез по другому считается
Очень круто! спасибо!
Меня больше заинтересовало как они вывели информацию по поводу каике отчеты сколько раз запускались и время выполнения. ТЖ не видел такого.
Таблица временных индексов всегда скидывается на жесткий диск, что ведет к существенной потере скорости, однако, когда выборка записей больше 8 мб, то временная таблица в любом случае скидывается на хард, поэтому индексы во временных таблицах оправданы только в запросах на выборку больших данных. Если запрос выбирает небольшие данные, использование индексов будет сильно тормозить.
Хочу работать с этим чуваком в команде
Хочу информации об инструментах, которые рисуют все эти циферки про расходы времени и количества использований... Это какие-то готовые инструменты, или что-то дописывали?
Сейчас тоже начинают всплывать вопросы по тормозам и хотелось бы их решать в порядке боли, а не как показалось.
Собираемся сделать такой выпуск. Скорее всего в январе-феврале
Да, вот это будет интересно
Это инструменты (их не мало), которые просто графически красиво показывают численные значения. А значения выдаёт сама платформа.
Сделайте выпуск про настройку графиков графаны)
Постараемся, спасибо за предложение
Интересный митап, спасибо. Скрытый герой - котейка. Открой, закрой... Закрыл? Открывай.. 😁
+ за внимательность 😂
00:30:52 есть где нибудь в литературе почитать, почему не рекомендуется использовать таблицу СрезПоследних у регистра сведений подчиненного регистратору? То есть вообще не рекомендуется использовать или в каких то конкретных условиях? Понятное дело, что могут быть регистраторы составного типа, но какие там соединения происходят при запросе к БД, где можно наглядно посмотреть или прочитать? На ИТС по этому поводу не видел информации.
Что тогда использовать в таком случае? Как оратор поступает в данном случае, если ему нужен срез из такой таблицы?
Расширяет кругозор, спасибо.
спасибо за видео
Спасибо, что посмотрели
А как у вас настроен технологический журнал, для такой метрики?
А можно видео как графану подключить и также красиво настроить ?
Может выступят ребята на эту тему
Не хватает планов запросов.
@Artem Kuznetsov, не понимаю, почему отрицание преобразуется в оператор "В". У меня такого нет. Запрос "Выбрать Ссылка Из Документ.ЗаказНаряд Где НЕ ВидРемонта = &ВидРемонта" преобразуется в "SELECT T1._IDRRef FROM dbo._Document321 T1 WHERE ((T1._Fld811 = @P1)) AND ((NOT (((T1._Fld2267RRef = @P2)))))", где @P1 - разделитель. Виды ремонта - справочник, с отборами по значению перечислений такое же условие.
Используете ли дата акселератор? Если нет, то есть ли планы?
Спасибо!
Какие ещё темы интересны?
@@yellow_club пока что не все стримы посмотрел) Но на практике были трудности по работе с xdto и http запросами. Возможно эти темы уже есть на канале и я до них просто не добрался. Ещё раз спасибо! По 1с на ютубе не так много каналов. Ваш однозначно в топ3 для меня!
Добрый день, коллеги. Артем к вам вопрос, если это конечно еще возможно, в этом моменте 49:00. Вы уходите от скана кластерного индекса и делаете как бы принудительный Key lookup. Но ведь если поле "Договор" является селективным и у вас актуальная статистика оптимизатор и так должен использовать индекс по полю договор. Разве нет?
Не совсем понимаю в чем выгода в этом кейсе, при условии что статистику вы обновляете. Ну и поле Договор очень вероятно, что является высокоселективным. Если конечно в таблице "ВыдачаССостояниями" не 100500 тыщ строк
Поддержу вопрос. В целом сложилось впечатление, что за актуальностью статистики не следят, иначе все эти развороты срезов были бы не нужны.
А почему докладчик применяет старый интерфейс УФ? Не такси. Есть какие-то причины производительности или просто вкусовщина?
Исторически сложилось. Зачем переходить на такси, если все сотрудники уже привыкли к этому интерфейсу?
Это из-за того, что конфигурация самописная, и написана под УФ, в Такси некоторые моменты ведут себя иначе, чем запланировано.
Интересно, какой процент (количество) запросов из БСП пришлось оптимизировать?
Ну, у нас есть постоянное расширение для БСП своё, но этим занимаются другие люди - я сходу не скажу про объём изменений.
@@artemkuznetsov3443 Артём, а вакансии у вас ещё есть?
@@АлександрГрунюшкин-г8ф На hh по компании "Центрофинанс" можно смотреть актуальные вакансии.
А что за консоль запросов на видео?
Крутой контент
Рад, что понравилось
где такую консоль запросов найти, чтоб как на видео показал количество записей в выборке (1час :30 минута)
Thanks!
Велком)
То чувство, когда ты единственный программист на базе 2тб и 500 юзеров. И без дашбордов 😀 ибо и так все узкие места знаешь
Круто! как насчет выступить у нас?
@@yellow_club На самом деле ничего особенного, это я по вашим видео учусь. Просто фирма резко выросла, а штат ИТ-нет :) С управляемыми блокировками только пришлось тщательно повозиться.
42:58 Что это было? Впустил кота? :-)
46:08 Полтергейст? Кот?
Полтергейст ))
1-е - выпустил кошку. 2-е - супруга впустила кошку :)
Подскажите при последнем примере условие выносятся в фигурные скобки, это необходимо делать в ответах на скд или в любых запросах? Как понять что объект подключён к РЛС, только посмотрев роли? Заранее спасибо
Можете делать в любых, но часть в фигурных скобках будет восприниматься только в СКД.
Люди, сравнивающие, какой язык хороший, как плохой - странные. Работай в том, какой нравится. Мы же не сравниваем сварщика на строительстве домов и сварщика на строительстве судов, потому что все профессии важны
интересно
Это хорошо)
У меня на 8.1 УПП 6,6 Тб. По производительности все норм. Либо ты пишешь сразу хорошо и все летает, либо ты пишешь не правильно и ничего работать не будет. А так Платформа 1С конечно могет!
Вот я тоже не понимаю таких людей, которые сначала пишут плохо, а потом переделывают 😂😂😂
Почему нельзя было идеально сделать с первого раза 🤣🤣
@@yellow_club да даже не идеально, а по стандартам разработки
Ну да, так и есть. В новом коде проблемы единичны с того момента, как начали применять стандарты. Почти всё - легаси.
@@artemkuznetsov3443 что такое легаси?
Легаси код - тяжелая наследственность : ) Устаревший код, который более не поддерживается и не обновляется, но используется. Второе значение - код от сторонних разработчиков, или из старых версий.
Здравствуйте, я остаюсь у вас на канале, жду и вас у себя. Мне очень понравился ваш канал, удачи вам.
Пример с заявками не показательный вообще. Оптимизировать там имело смысл поэтапно - сначала убрать вычисления для начала и конца периода. Ясно что после этого запрос стал бы выполнятся за 1-2 сек. Что-то большие сомнения у меня, что оптимизатор после этого стал бы проверять каждую строку, а не то что было выбрано по периоду. Какой смысл все скидывать в ВТ, если по смыслу потом выполнялась бы та же самая операция, но уже по данным ВТ. Плюс если поле Шаг скорее всего не индексировано. Не надо зацикливаться на правилах. Знать их надо, но периодически подвергать сомнению тоже стоит.
Версия Палформы?
В Телеграм чате желтого клуба писали, что 8.3.17
8.3.17 сейчас, но уже выполняется поэтапный переход на 8.3.20
@@artemkuznetsov3443 а режим совместимости?
Больно смотреть на это... Базы на 7 Tb с которыми работают по стандартам SQL 92 года, да хотя бы и 92, но там же даже от 92 года только 25% возможностей.
Люди вваливают тонны денег в СУБД, железо, а потом ничего кроме SELECT сделать не могут. Все что им дано это кластерный индекс у которого первое поле с нулевой селективностью (разделитель) и .... и все.
Героизм в крови, то с гранатой под танк, то вот 7Tb на 1С...
Смотрел недавно hi load яндекса, был вопрос: "как вы решаете проблему с большимим базами?"
Ответ: У нас нет больших баз, какие то данные лежат в columnstore какие то в mongo, там где требуются реляционные связи используется PG но так что у каждого сервиса своя PG
1С никам это не понять. Реально. Они вот так и пробуют - ковырять в запросах гигабайты информации. И радуются как дети когда через одно известное место получается на секунду ускорить что-то.
10 лет назад это смотрелось ещё ну.. как реалии технологической платформы, сейчас уже как идиотизм.
Херню какую-то написали. Без приведения конкретных примеров для сравнения, ваш комментарий из разряда "мне для моих задач это не требуется, поэтому и вы делайте как я". А я вам скажу, что не на 1С ваша разработка будет стоить в 10 раз дороже.
@@АлексейТ-ю9я Какие примеры вы хотите в комментариях на Ютубе? Что касается "для моих задач" то 1с уже давно позиционируется не как Бух для ларьков а как серьезный универсальный hiload framework. Что касается дороже в 10 раз то дело не в скорости разработки а в том что 1с команды получают меньше ЗП в 3 раза, и сами команда меньше следовательно один человек делает больше работы. И мне как специалисту это сильно не нравится. Я хочу как в нормальном ИТ работать меньше получать больше.
@@You2Ber42, что-то не понял суть ответа.
А агрегаты на больших регистра кто-то смог включить? Очень много часов включаются. Или это мертво рождённая фича?
Не претендую на истину, но компоновщик данных в дин.списках и СКД, сам добавляет РАЗРЕШЕННЫЕ в запрос, поэтому в теории это можно не добавлять, но понятно что в этой компании просто такой стандарт, и видимо воизбежании ошибок, что где то в модулях форм или объектов забудут это сделать, добавляют везде
Свертка базы? Не, не слышал(с)
Я говорил об этом вроде - о свертке думают уже не первый год, но пока бизнес использует в том числе старые данные по движениям и резать не согласен.
Грустно, что 7 ТБ база должников
Спикеру надо либо на рашн переходить либо целиком на инглише вещать (хотя, может, это я слишком стьюпид и стар - не секу модерновый спич и факаплюсь как ластовый лузер)
1С и "быстро" это несовместимые вещи. 1С это для людей, которые медитируют. Нельзя сделать быстро из того, что работает изначально медленно. Опыт у меня в оптимизации достаточен. Здесь нет универсального подхода. К решениям в видео и подходах тоже есть претензии, просто вероятно никто не может это доказать (или не хочет). Самое распространенное заблуждение: создаешь ВТ - делай индексы. Ошибочное мнение. Создать индекс на пол миллиарда записей, а потом скуль решает его не использовать в силу своих мыслей и увеличивает время исполнения запроса на создание индекса что очень заметно. Проще пробежать все записи сканом
После фразы "создать индекс на полмиллиарда записей" стоит уже задуматься о том, на кой ляд ты это сделал.. А уже потом решать вопрос, как всунуть это планировщику, чтобы он побыстрее пропихнул этот запрос.
@@АлексейОбухов-я1э не надо пытаться понять "на кой ляд". Есть данные - надо их обработать.
консоль запросов такое убожество...
а что лучше?
В обычных формах, в инструментах разработчика, консоль. Функций и возможностей на порядок больше, а не " вот это все". ))
Да, в обычных формах консоль больше возможностей имеет
@@mendicator4319 Тоже рыдал над консолью из обычных форм, когда перешёл на УФ. Прошёл все эти: отрицание, гнев, торг, депрессия, смирение :))))
@@NemanEnt потом смэрт? ))
Начните уже резать свои видео до минут 40-60. Ваши 5 минутки ге интересны. А два с лишним часа на просмотр найти очень сложно.
Будет сделано, спасибо за предложение 🙏
В чём проблема смотреть в несколько заходов на х2 скорости?
тема большая, таймкоды в помощь