Как ускорить запрос в управляемых формах.

1С v8

06.05.15

✎

08:43

Добрый день, нужна помощь в оптимизации запроса.

В справочнике товаров 70к наименований, запрос осуществляет поиск по 3 полям справочника (наименование, дополнительное наименование и описание). В запросе получаю цены и остатки и после этого выгружаю запрос в таблицу на управляемой форме.

    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ
                   |    Товары.Ссылка КАК Товар,
                   //|    Товары.Наименование,
                   |    Товары.Описание,
                   //|    Товары.ДополнительноеНаименование,
                   |    ОстаткиОстатки.КоличествоОстаток КАК ОбщийОстаток,
                   |    ОстаткиСклад1.КоличествоОстаток КАК ОстатокСклад1,
                   |    ОстаткиСклад2.КоличествоОстаток КАК ОстатокОстатокСклад2,
                   |    ЦеныЗакупкиСрезПоследних.Цена КАК ЦенаЗакупки,
                   |    ЦеныПродажиСрезПоследних.Цена КАК ЦенаРеализации
                   |ИЗ
                   |    Справочник.Товары КАК Товары
                   |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Остатки.Остатки(&ДатаФормирования) КАК ОстаткиОстатки
                   |        ПО ОстаткиОстатки.Товар = Товары.Ссылка
                   |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Остатки.Остатки(&ДатаФормирования, Склад = &Склад1) КАК ОстаткиСклад1
                   |        ПО ОстаткиТирасполь.Товар = Товары.Ссылка
                   |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Остатки.Остатки(&ДатаФормирования, Склад = &Склад2) КАК ОстаткиСклад2
                   |        ПО ОстаткиБендеры.Товар = Товары.Ссылка
                   |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныТоваров.СрезПоследних(&ДатаФормирования, ВидЦены = &ЦенаЗакупки) КАК ЦеныЗакупкиСрезПоследних
                   |        ПО ЦеныЗакупкиСрезПоследних.Товар = Товары.Ссылка
                   |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныТоваров.СрезПоследних(&ДатаФормирования, ВидЦены = &ЦенаРеализации) КАК ЦеныПродажиСрезПоследних
                   |        ПО ЦеныПродажиСрезПоследних.Товар = Товары.Ссылка
                   |ГДЕ
                   |    (Товары.Наименование ПОДОБНО &ПолеПоиска
                   |            ИЛИ Товары.Описание ПОДОБНО &ПолеПоиска
                   |            ИЛИ Товары.ДополнительноеНаименование ПОДОБНО &ПолеПоиска)
                   |    И Товары.ЭтоГруппа = ЛОЖЬ";

    //врПолеПоиска = ЭтаФорма.ТекущийТовар.Наименование;
    ПолеПоиска = "%" + СокрЛП(ПолеПоиска) + "%"; //+ врПолеПоиска + "%";

//тут устанавливаю параметры запроса и далее выгружаю их в табличную часть

Объект.Товары.Загрузить(Запрос.Выполнить().Выгрузить());

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

Подскажите варианты ускорения запроса.

Изначально пробовал результат выбрать Пока Результат.Следующий Цикл, но это работает медленнее чем выгружать и загружать через таблицу значений. Поле описание строка 200, дополннаименование строка 50.

Я понимаю что соединения в таблицах очень тормозят, но не представляю как на управляемых формах как от них избавиться но при этом выводить ту же информацию но быстрее.

1 DomanM

06.05.15

✎

08:45

(0) почему не получается хранить вт?

2 GhostAnton

06.05.15

✎

08:50

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

3 GhostAnton

06.05.15

✎

08:52

Актуальность информации об остатках клиент может регулировать кнопкой обновитьитоги, так как не всегда есть нужда в актуальности итогов в течении часа другого

4 МаксимМП23

06.05.15

✎

08:53

(2) Ты мне мозг сломал этим постом.

5 GhostAnton

06.05.15

✎

08:55

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

6 Aloex

06.05.15

✎

08:56

(0) Сделай три запроса через Объединить все или загони во временную таблицу справочник номенклатуры.

7 senior

06.05.15

✎

08:57

(0) не совсем понял механику. У тебя есть поле ввода, надо найти товары с похожим именем. А для чего ВТ используешь?

8 Fragster

гуру

06.05.15

✎

08:59

(2)открой для себя ПоместитьВоВременноеХранилище

9 DomanM

06.05.15

✎

09:00

(2) почему переменная а не реквизит?

10 GhostAnton

06.05.15

✎

09:01

(8) есть какой-то пример как поместить и вернуть на сервере, чтоб вся таблица не тянулась к клиенту

11 Aloex

06.05.15

✎

09:01

(0)+(6) и только к отобранной номенклатуре делай джойны.

12 Bober

06.05.15

✎

09:02

Весь запрос - это трешак. Как минимум нужно вынести отбор товара в отдельный запрос и потом во все параметры вирт таблиц добавить отбор по номенклатуре.

13 DmitrO

06.05.15

✎

09:02

(7)в обычных формах, он в ВТ хранил предварительно рассчитанные остатки и цены скорее всего.

14 GhostAnton

06.05.15

✎

09:02

(9) разве реквизит не грузится на клиента при открытии формы? даже если не отображается

15 GhostAnton

06.05.15

✎

09:03

(13) да так и делал и это был самый быстрый вариант из всех

16 GhostAnton

06.05.15

✎

09:10

(11) Сделать запрос по номенклатуре и |ПОМЕСТИТЬ в таблицу далее по полученному выбрать цены и остатки, я правильно понял? такой вариант не пробовал использовать, но думаю что будет работать значительно быстрее.

Но так же хотелось бы попробовать воспользоваться (8) но не могу до конца разобраться с этим

17 DmitrO

06.05.15

✎

09:12

(15)теперь так не получится :)
теперь надо делать по другому, все считать одним запросом (пакет):
1.сначала отобрать товары в ВТ_Товары
2.потом рассчитать остатки в ВТ_Остатки с использованием фильтра по уже отобранным товарам, причем рассчитать сразу все нужные ресурсы (в целом, и по обоим складам), индексировать ВТ
3.рассчитать цены в ВТ_Цены с собственной реализацией среза последних, тоже за один раз обе цены, индексировать ВТ
4.соединяя все три ВТ получить результат.

18 GhostAnton

06.05.15

✎

09:15

(17) а есть ли вариант полученные ВТ хранить на сервере для того чтоб каждый раз не пересоздавать их?

19 DmitrO

06.05.15

✎

09:15

(16)в данном случае вариант из (8) не подойдет, т.к. предварительно рассчитанные данные огромны, а храниться они будут на сервере 1С а не на сервере БД, и по сути сервер 1С будет их закидывать из временного хранилища на сервер БД каждый раз при выполнении поиска.

20 DmitrO

06.05.15

✎

09:16

(18)нет, разработчики платформы 1С считают что нам это не нужно.

21 GhostAnton

06.05.15

✎

09:18

(17) Да просто даже если я убираю запрос цен и остатков, то намного запрос не становится быстрее, всеравно выбор самого товара подходящего условиям занимает длительное время :(

(20) Да это действительно печально

22 GhostAnton

06.05.15

✎

09:19

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

23 GhostAnton

06.05.15

✎

09:23

Хоть блин бери и загружай всю инфу клиенту и дальше просто отборами по таблице вести поиск, открытие формы бедт долгим но далее будет по идее быстрее

24 EugeniaK

06.05.15

✎

09:23

Разделить на 2 этапа.
Сначала отобрать товары с условием
Товары.Наименование ПОДОБНО &ПолеПоиска
| ИЛИ Товары.Описание ПОДОБНО &ПолеПоиска
| ИЛИ Товары.ДополнительноеНаименование ПОДОБНО &ПолеПоиска
Загнать их в массив.
И уже массив передавать в запрос, заменив условие на "Номенклатура в &МассивНоменклатур" и подставлять в параметры таблиц
"РегистрНакопления.Остатки.Остатки(&ДатаФормирования, Номенклатура в &МассивНоменклатур)"

25 vde69

06.05.15

✎

09:24

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

26 DmitrO

06.05.15

✎

09:25

(20)+ тут суть вот в чем, по идее, для реализации в УФ твоего первичного сценария надо сохранить между серверными вызовами менеджер временных таблиц (это именно он держит ВТ на сервере БД). Чтобы его сохранить его надо либо поместить в реквизит формы (это не возможно), либо поместить его во временное хранилище (тоже нельзя, это даже платформой явно контролируется). Это все изза того, что при назначении этих ограничений они исходят из отказоусточивой кластреной мождели, а по ней все сохраненные значения во временном хранилище или в форме обязательно должны быть сериализуемыми, т.к. может произойти отказ текущего рабочего сервера 1С, перемещение сеанса на другой рабочий сервер 1С, и следующий серверный вызов может быть уже к другому серверу в кластре.

27 vde69

06.05.15

✎

09:31

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

28 Loki Evil

06.05.15

✎

09:36

(26)
А с таблицей значений тоже самое получится?
Или можно сохранить в таблицу значений, а потом использовать выбрать * поместить ВТТаблицаОстатков в пакете и потом собственно запрос к ВТТаблицаОстатков?

29 GhostAnton

06.05.15

✎

09:36

(25) В отдельном окне отображать не вариант инфу, так как рабочему необходимо видеть цены и остатки по всем нескольким позициям, так как по сути это одна и та же деталь но от разных производителей и с разными ценами. А тыкать на каждую для просмотре цен и остатков это совсем не удобно

30 GhostAnton

06.05.15

✎

09:39

(27) актуальность остатков имеет значение, но приоритет более в скорости поиска, а при необходимости перерасчитать таблицу по кнопке клиенту проще когда есть промежуток во времени

31 DmitrO

06.05.15

✎

09:39

(25)я считаю что здесь динамический список ни к чему не нужен

32 GhostAnton

06.05.15

✎

09:39

(31) согласен, полносьбю

33 Вася Чез

06.05.15

✎

09:40

(0) покури вот это, вдруг на правильные мысли натолкнет http://1cprogress.ru/anatomiya-registra-nakopleniya-virtualnaya-tablica-ostatkov.html

34 DmitrO

06.05.15

✎

09:45

(28)так это и есть вариант (8), ему оценка дана, см. (20)

35 DmitrO

06.05.15

✎

09:47

(21)"Да просто даже если я убираю запрос цен и остатков, то намного запрос не становится быстрее, всеравно выбор самого товара подходящего условиям занимает длительное время :( "

тогда чета ты темнишь, тут УФ точно не причем тогда(!)

36 DmitrO

06.05.15

✎

09:51

(34)+ поправка: ему оценка дана, см. (19)

37 GhostAnton

06.05.15

✎

09:51

(35) Да нет, УФ, управляемые формы, обработка рабочий стол пользователя, на нем 3 табличные части и поле поиска, при заполнении данных поля поиска данные получают в первую таблицу согласно найденным позициям запроса, при активизации строки в этой таблице выполняю другой запрос условием которого является только выделенная строка (конкретнее товар) по нему выбираются аналоги и помещаются в другую таблицу. При выборе строки либо в той либо в другой таблице данные помещаются в третью и на основании третьей по кнопке создаются либо расход либо перемещение

38 GhostAnton

06.05.15

✎

09:52

Платформа 8.3 интерфейс такси

39 GhostAnton

06.05.15

✎

09:54

У элемента справочника таб часть есть, но в ней не более 15 строк, да и она не причем, в запросе то я ее не использую

40 DmitrO

06.05.15

✎

09:55

(37)ну 2я и 3я таблица к обсуждаемому вопросу не относятся, так?

41 GhostAnton

06.05.15

✎

09:56

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

42 GhostAnton

06.05.15

✎

09:58

Я конечно грешу что тесты все произвожу в файловом варианте, но думаю что производительность запроса не вырастет в 5 раз когда переведу в серверную

43 Loki Evil

06.05.15

✎

10:00

(34), (36) ясно
просто не понятно было - вы про менеджер ВТ или таки про таблицу с данными.

а то что в (0) - пример не оптимального запроса, после оптимизации может показать вполне приемлемую скорость работы.3 соединения с таблицей остатков без отбора по номенклатуре, 2 соединения с ценами...

44 GhostAnton

06.05.15

✎

10:03

(43) вот и хочу оптимизировать, сейчас переписываю запрос использую ПОМЕСТИТЬ и выбором остатков и цен только по ним, но поиск просто товара занимает от 3 до 10 секунд, это критично, в обычных формах удалось добиться поиска за несколько сотых секунды

45 DmitrO

06.05.15

✎

10:03

(42)нельзя подобные выводы делать на таких разных платформах хранения данных, может и вырастет.

Боевой сервер БД на MSSQL при наличии свободной памяти закешит у тебя все страницы первичной таблицы справочника товаров в память при первом же поиске, и при всех последующих поисках будет их обрабатывать вообще не обращаясь к диску.

46 DmitrO

06.05.15

✎

10:04

(45)+чего в файловом варианте не будет никогда

47 vde69

06.05.15

✎

10:05

(29) кто тебе мешает в дополнительном окне показывать все АНАЛОГИ и ЗАМЕНЫ с ценами?

лет 10 назад делал так на рынке АВТО-МОЛ

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

48 senior

06.05.15

✎

10:11

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

49 senior

06.05.15

✎

10:11

(48) опечатка: *а почему нельзя

50 vde69

06.05.15

✎

10:15

по сабжу (конкретно про запрос) правильный совет только в (24), разумеется можно не в массив а использовать ВТ...

51 GhostAnton

06.05.15

✎

10:16

(45) В общем сегодня подниму сервер и буду делать выводы на сколько производительней, если поиск будет осуществляться не более 3 секунд то вполне устроит результат.
(47) так и делаю, но и отображать цены нужно и в основной таблице.
(50) да так и переписываю сейчас, через ПОМЕСТИТЬ и далее запрос цен и остатков с отбором по полученной инфе в вт

52 GROOVY

06.05.15

✎

10:20

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

53 Loki Evil

06.05.15

✎

10:23

(51) (52) Либо еще можно сделать служебное поле - объединение 3-х полей, и подобно-поиск проводить по одному полю, результат по скорости можно прикинуть убрав 2 поиска по наиболее коротким реквизитам.

54 Nikulin

06.05.15

✎

10:32

А не вариант делать запрос (получать все данные) только по товарам, которые отображаются пользователю в данный момент в списке?
в толстых формах это всегда работало.
как это на УФ делать - я еще не курил, не подскажу.

55 Nikulin

06.05.15

✎

10:35

а. тут дело еще и в поиске.
тогда я мимо в (54)

56 Nikulin

06.05.15

✎

10:36

тогда встречный вариант.
Зачем делать кучу соединений при поиске.
1. ищем
2. нашли = делаем еще запрос с ценами и прочим...

57 Simod

06.05.15

✎

11:02

(0) Что такое "ОстаткиТирасполь"?

58 GhostAnton

06.05.15

✎

11:49

59 GhostAnton

06.05.15

✎

11:51

По производительности в сравнении с серверным вариантом работы буду знать ночью, после запуска базы

60 Зеленый пень

06.05.15

✎

11:56

(58) Ну тут же сразу видно поле для оптимизации - вместо 5 запросов к виртуальным таблицам можно оставить 2.

61 Loki Evil

06.05.15

✎

11:58

(59)
в запросе можно для ВТ добавить индекс для поля Товар (по нему потом соединения будут).
ГДЕ (Товары.Наименование ПОДОБНО &ПолеПоиска ИЛИ Товары.Описание ПОДОБНО &ПолеПоиска ИЛИ Товары.ДополнительноеНаименование ПОДОБНО &ПолеПоиска)

+ можно попробовать вот это ^^^ условие заменить на
проверку по одному сводному полю (доп. реквизит в справочник)
ГДЕ Товары.СлужебноеПолеТекстовогоПоиска ПОДОБНО &ПолеПоиска

62 Loki Evil

06.05.15

✎

11:59

(60) Смотря как там потом результат используется, если нужны остатки колонками, то имха лучше уж в запросе как у автора сделано.

63 Зеленый пень

06.05.15

✎

12:01

(62) С чего бы лучше? Ничто не мешает сделать колонками, но по 1 запросу к остатками и ценам.

64 GhostAnton

06.05.15

✎

12:05

(60) да колонки отдельно
(62) если делать как у меня пусть и больше соединений, но МояТаблица.Загрузить(Результат.Выгрузить()) работает быстрее чем если делать выборку с обходом по группировкам для заполнения конечной таблицы, я сравнивал и пробовал тот вариант.
(59) как сделать индексы и потом с помощью их ускорить?, "по одному сводному полю" не совсем понял, имеете ввиду добавить реквизит и там хранить общее значение всех полей?

65 Зеленый пень

06.05.15

✎

12:27

(64)
Зачем обход?

Делаешь запрос:

ВЫБРАТЬ
        Товар,
        СУММА(КоличествоОстаток) КАК ОбщийОстаток,
        СУММА(ВЫБОР КОГДА Склад = &СкладСклад1 Тогда КоличествоОстаток ИНАЧЕ 0 КОНЕЦ) КАК ОстатокСклад1,
        СУММА(ВЫБОР КОГДА Склад = &СкладСклад2 Тогда КоличествоОстаток ИНАЧЕ 0 КОНЕЦ) КАК ОстатокСклад2
ПОМЕСТИТЬ ВсеОстатки
       ИЗ РегистрНакопления.Остатки.Остатки(
                &ДатаФормирования,
                Товар В
                    (ВЫБРАТЬ
                        ТЧ.Товар
                    ИЗ
                        ТЧ КАК ТЧ) ) КАК ОстаткиСклад

СГРУППИРОВАТЬ ПО Товар

и соединяешь ТЧ с этой врем.таблицей "ВсеОстатки"

аналогично с ценами, только там в вирт.таблицу ставишь фильтр на 2 типа цены.

66 Бубка Гоп

06.05.15

✎

12:44

(65) дело говорит

67 Loki Evil

06.05.15

✎

13:05

(65)!!!! блин, как все просто то!
снимаю шляпу, вижу первый раз.

68 DmitrO

06.05.15

✎

13:18

(64)(67) боже мой, ну я же в (17) еще все написал :)
а вы тут все языками чешете, идите уже работать :)

69 GhostAnton

06.05.15

✎

13:19

70 Зеленый пень

06.05.15

✎

13:22

71 Loki Evil

06.05.15

✎

13:26

(69)
ВЫБРАТЬ
Товары.Ссылка КАК Товар,
Товары.Описание,
Товары.Родитель КАК Группа,
Товары.ДополнительноеНаименование
ПОМЕСТИТЬ ТЧ
....
Индексировать по Товар - нужно добавить.

Про общее поле
Пишу уже который раз, берем, добавляем реквизит строковый, количество символов = сумме количества символов в 3-х ваших реквизитов: наименование, описание и дополнительноеНаименование.
Заполняем реквизит, добавляем подписку на событие при записи чтобы если поменялось одно из полей - менялось и наше служебное поле

и тогда!!! вместо 3- проверок ПОДОБНО &ПолеПоиска, будет 1 проверка, работать должно быстрее

72 Loki Evil

06.05.15

✎

13:28

(71) Хотя когда там вместо соединения теперь объединение - может уже и не актуальна индексация по полю товар в временной таблице.

73 GhostAnton

06.05.15

✎

13:33

(69) я обратил внимание на это, но не знаю на сколько улучшится скорость поиска

74 Зеленый пень

06.05.15

✎

13:33

(71) Хоть одно Подобно, хоть 3 - разницы не будет, индексы ни там, ни тут не будут использоваться.
Индексировать по Товар - вряд ли что не даст.

75 GhostAnton

06.05.15

✎

13:34

извините опечатался в (73) *(71)

76 Loki Evil

06.05.15

✎

13:45

(74)
а я скромно проверил на своем справочнике, по одному полю проверка в 3 раза быстрей чем по 3-м.
Правда мне было лень заполнять все, в итоге я вместо общего поля для тестов использовал просто самое длинное из текстовых

77 Loki Evil

06.05.15

✎

13:46

Т.е. проверить то можно легко - убрать из условия 2 поля из 3-х и замерить, если эффект есть - попробовать добавить общее поле, заполнить его и проверить уже в готовом виде

78 GhostAnton

06.05.15

✎

13:55

Ну в принципе да, пока оставлю так, если не сутроит производительность то буду делать вариант с общим полем

79 GhostAnton

06.05.15

✎

13:57

Всем спасибо за помощь!

80 Salimbek

06.05.15

✎

14:04