Имя: Пароль:
1C
 
v8: Сравние способов соединения в запросе табличной части объектов
,
0 mirosh
 
14.07.12
16:47
В теме v8: Выборка элементов табличной части справочника у меня с одним уважаемым человеком возник спор о том, какой запрос выбора будет эффективнее. Я утверждал, что непосредственный выбор табличной части справочника без явного его соединения с таблицей самого справочника будет работать быстрее на больший объемах данных.

Я провел тестирование и мои слова подтвердились.

Подробности.
Файловая база 1С 8.1. Я завел справочник с табличной частью. У табличной части два реквизита: один строка, второй - ссылка на элемент другого справочника (везде одна и та же).

Я заполнил справочник 2000 элементами и каждую табличную часть этих элементов 500 строками.

Оказалось, что непосредственный выбор ТЧ в запросе работает на таких малых объемах данных уже быстрее на целых 0,5 секунд!

Скриншоты в качестве доказательства (закомментированный код - это как раз код начального заполнения справочников).

http://i056.radikal.ru/1207/5d/afd010d482a9.jpg - непосредственный выбор ТЧ в запросе

http://s51.radikal.ru/i131/1207/89/cbbaab8a0af4.jpg - через явное соединение
1 mirosh
 
14.07.12
16:52
Нет никакого смысла соединять табличную часть объекта с самим объектом явно в запросе (кроме каких-нибудь специфических задач с группировками, о которых речи не идет). Это ведет к усложнению запроса и снижению времени его работы
2 Kreont
 
14.07.12
17:01
0.5 сек. все таки мало что б утвеждать что один вариант быстрее от другого.
Попробуй еще так при случае:
Перегрузи комп (или сервер БД) и повтори то самое 3-5 раз для одного варианта, потом опять перегрузи комп(севрер) и опять 3-5 раз другой вариант. Будет точнее сравнение.

Как по мне, так разницы вообще не должно быть :)
3 mirosh
 
14.07.12
17:05
(2) сервер перезагружать нет возможности, я тестил два раза, вариант с непосредственным выбором быстрее примерно на 0,75 секунд в среднем.
Т.е. при каждом испытании непосредственный выбор из ТЧ происходит быстрее
4 mirosh
 
14.07.12
17:05
интересно будет потестить на серверном варианте при гораздо больших объемах
5 rs_trade
 
14.07.12
17:17
(0) После слов Файловая база, стало не интересно. Тестируй на клиент-сервере. Должно быть одинаково.
6 mirosh
 
14.07.12
17:17
(5) многие работают на файловой базе. смысл тестировать на ней определенно есть
7 izekia
 
14.07.12
17:22
(0) автор найди десять отличий между теми запросами которые ты привел и которые обсуждались

кому интересно могут пройти в ту тему о которой идет речь v8: Выборка элементов табличной части справочника
и потом составить мнение об авторе этой темы
8 rs_trade
 
14.07.12
17:22
(6) в файловых базах сидят там, где пол буха с базой работает. никому там эти 0.5 сек ниче не дадут.
9 rs_trade
 
14.07.12
17:23
а на клиент сервере даже тестить ниче не надо. просто запросы в профайлере глянуть, и все понятно будет.
10 izekia
 
14.07.12
17:24
и да, тестирование на файловой безусловно очень важно

по сути 1С формирует одинаковые запросы в том и другом случае, для MS SQL
в целом получается удобнее не писать лишнее соединение
11 Красный рассвет
 
14.07.12
17:25
(8) Ну зря ты. До десятка бухов файловый вариант тянет. Но лишние секунды там - действительно нах не стОит учитывать.
12 izekia
 
14.07.12
17:25
+(10) но про скорость - это очевидный бред
13 izekia
 
14.07.12
17:27
(8)(11) о чем весь этот бред? автор очевидно ступил и сейчас думает как оправдаться ... на файловой тоже не должно быть разницы
14 mirosh
 
14.07.12
17:28
(13) автор тестирует на серверной базе с большими таблицами
15 izekia
 
14.07.12
17:29
(14) автор, иди почитай тему с которой все началось, и покайся
16 izekia
 
14.07.12
17:29
черт, запятая лишняя
17 izekia
 
14.07.12
17:30
хотя нет, наоборот не хватает
18 mirosh
 
14.07.12
17:30
(16) не лишняя, наоборот, не хватает
19 andrewks
 
14.07.12
17:30
итак, во-первых: (пусть даже взять файловую базу, хоть это и эпик-фэйл)

чтобы говорить о более-менее приближённом к реальности тестировании, нужно сделать примерно так:
делаем 10 тысяч доков с ТЧ с разным кол-вом строк от 50 до 200.
далее перегружаем комп, выжидаем 5 минут, и запускаем цикл на 10000 итераций, в каждом шаге цикла делаем три запроса: по 1-му, 2-му, и по 3-му варианту (1-й - неявное соединение, 2-й - явное левое, 3-й - явное внутреннее).
по каждому варианту вычисляем время отработки запроса и суммируем в трёх переменных. потом делим каждую на кол-во итераций, получаем среднее время выполнения по каждому варианту.
20 izekia
 
14.07.12
17:31
(18) ты не отвлекайся, или ту тему почитай, потом возвращайся
21 izekia
 
14.07.12
17:31
или = иди
22 izekia
 
14.07.12
17:31
(19) да хоть есть над чем поржать в субботу
23 rs_trade
 
14.07.12
17:32
(13) а в чем он ступил? просто положился на умность движка 1С. по идее платформа в элементарных запросах точно так же должна дорисовть запрос. но как на самом деле хз. 1с не раз свинью подкладывава в очевидных вещах.
24 mirosh
 
14.07.12
17:32
(19) ну делай, делай, я что ли за тебя буду делать?
а почему файловая база эпик фейл? на ней тоже можно работать
25 izekia
 
14.07.12
17:33
(23) в ту тему ходил? отличий не видишь?
26 Красный рассвет
 
14.07.12
17:33
(22) Субботняя ветка детектид!
27 andrewks
 
14.07.12
17:34
(24) нет, это ты делай. это ты понтов накидал, что неявное соединение будет работать быстрее. я-то за своё вариант уверен и безо всяких тестов.  а то, что ты понаписал в (0) - ровным счётом ничего не доказывает
28 izekia
 
14.07.12
17:34
(24) ты еще здесь и не изучаешь текст запроса из v8: Выборка элементов табличной части справочника
чем он по-твоему отличается от местного первого варианта?
29 andrewks
 
14.07.12
17:35
кстати, чё-то у тебя тексты запросов стали какими-то левыми (и это я не про левое соединение)
30 izekia
 
14.07.12
17:35
(27) да посмотри, у него запросы здесь не те, блин, я один только это вижу?
31 izekia
 
14.07.12
17:36
(29) о наконец-то еще один прозревший)
32 izekia
 
14.07.12
17:36
(29) я думал под эпик фейлом ты это и имел в виду)
33 rs_trade
 
14.07.12
17:36
(25) хз. может спор о каких то конкретных деталях. я так, о теме в целом.
34 izekia
 
14.07.12
17:37
(33) угу, типичный одинэсник
35 izekia
 
14.07.12
17:37
нравится пообсуждать тему в целом)))
36 andrewks
 
14.07.12
17:38
(24) "а почему файловая база эпик фейл? на ней тоже можно работать"  файловая база реализована явно под потребности языка 1С, и не позволяет оперировать над ней скриптами на SQL. так что как там у них всё внутрях организовано - известно одному Нуралиеву (хотя и это не факт).

но, давай, пусть даже на файловой, потесть _по-честному_
37 izekia
 
14.07.12
17:39
(33) в (23) ты написал про конкретные детали, но я, хоть убей, не понимаю про какую ты дорисовку?
здесь не будет подстановки левого соединения по умолчанию, так как выборка ведется только из одной таблицы, когда в той теме джойнится вторая для выполнения сравнения
38 izekia
 
14.07.12
17:39
(36) так сейчас он потестит этот же вариант на серверной и будет убеждать всех что и на серверной такие же результаты)
39 mirosh
 
14.07.12
17:39
"ВЫБРАТЬ
   |    РеализацияТоваровУслугТовары.Ссылка,
   |    РеализацияТоваровУслугТовары.Номенклатура,
   |    РеализацияТоваровУслугТовары.Ссылка.Дата
   |ИЗ
   |    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары";

и

ВЫБРАТЬ
   |    РеализацияТоваровУслугТовары.Ссылка,
   |    РеализацияТоваровУслугТовары.Номенклатура,
   |    РеализацияТоваровУслуг.Дата
   |ИЗ
   |    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
   |        ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
   |        ПО РеализацияТоваровУслугТовары.Ссылка = РеализацияТоваровУслуг.Ссылка

на серверной работают одинаково.
Так что да, не быстрее
40 andrewks
 
14.07.12
17:40
(39) результаты внутреннего давай
41 izekia
 
14.07.12
17:40
(39) а знаешь почему? потому что пля, сиквел, оптимизировал второй запрос и откинул накуй никому не нужное соединие
42 izekia
 
14.07.12
17:41
(39) ну реально скажи, ну сколько можно тупить? уже ведь не смешно
43 mirosh
 
14.07.12
17:41
и да в теме
v8: Выборка элементов табличной части справочника

(41) наоборот, в первом запросе он создал НУЖНОЕ соединение
44 mirosh
 
14.07.12
17:42
в теме
v8: Выборка элементов табличной части справочника
andrewks говорил об эффективности явного соединения, так что обоюдный слив, я считаю
45 izekia
 
14.07.12
17:42
(43) сиквел создал?? нуну
46 mirosh
 
14.07.12
17:42
(45) а ты не видешь там строчку
РеализацияТоваровУслугТовары.Ссылка.Дата  ?
47 andrewks
 
14.07.12
17:43
(44) ты фигуры-то в кармане не прячь, на ничью не выводи, давай результат явного иннер джойна
48 rs_trade
 
14.07.12
17:43
(39) быстрее быть и не могло. правда пример какой то, не айс.
49 izekia
 
14.07.12
17:43
(46) а, она меня выпала, пропустил, просто в (0) у тебя совершенно другие запросы
50 mirosh
 
14.07.12
17:43
(40) а больше тебе ничего не дать?
сначала научись общаться нормально
это относится и к товарищу izekia
51 izekia
 
14.07.12
17:44
(46) 1С генерит, а не сиквел
52 mirosh
 
14.07.12
17:44
(49) да, в (0) запросы другие, поэтому я сделал нормальные в серверном варианте
53 andrewks
 
14.07.12
17:44
(48) ну да, примеры не совсем удачные, но пусть даже с такими, для начала
54 mirosh
 
14.07.12
17:44
(51) тогда сервер 1С их и убирает
55 mirosh
 
14.07.12
17:44
(48) что с примером
56 izekia
 
14.07.12
17:44
(50) да ты просто посмотри на свои запросы в шапке, там и ослу будет ясно, что на файловой первый будет быстрее, если 1С его не соптимизирует, но на это не хочется полагаться
57 mirosh
 
14.07.12
17:45
(56) про шапку все понятно уже вроде всем
58 andrewks
 
14.07.12
17:45
(50) не хами. ты завёл ветку, ты и доказывай. я вообще всё сказал ещё в той ветке, и добавлять больше нечего
59 mirosh
 
14.07.12
17:45
(58) где хамство?
60 izekia
 
14.07.12
17:45
(47) не, иннер будет медленнее, посмотри на план, там просто индекс
61 izekia
 
14.07.12
17:46
(57) ну та запусти ради приличия те же запросы на файловой
62 rs_trade
 
14.07.12
17:47
(56) 1С не оптимизирует запросы. У них бюджета такого нет, что бы такое написать.
63 mirosh
 
14.07.12
17:47
(61) я не спорю, они если и будут различаться, то незначительно.лучше иннер на серверной сделать
64 izekia
 
14.07.12
17:47
(60) + а вот кстати на файловой интересно посмотреть результат иннера
65 mirosh
 
14.07.12
17:47
(62) сервер 1С создает план запроса. подозреваю, у субд свой оптимизатор
66 izekia
 
14.07.12
17:48
(62) под оптимизацией я имел в виду оптимизацию текста и отбрасывание явно ненужного куска
67 rs_trade
 
14.07.12
17:48
(62) да это наверное и не нужно. оптимизатор субд сделает это за них.
68 izekia
 
14.07.12
17:48
(65) план запроса все же у субд, серверу 1С там делать нечего
69 andrewks
 
14.07.12
17:49
(59) хамство в том, что ты меня поучаешь, указываешь на то, что я не умею общаться. а я, между прочим, в этой ветке общаюсь абсолютно корректно, да и в той позволил себе только один пост на грани фола. уж извини, но ты там сам нарвался со своей самоуверенностью про эффективность
70 mirosh
 
14.07.12
17:49
(67) оптимизация на уровне субд зависит от плана запросов, который создаст сервер 1С
71 izekia
 
14.07.12
17:49
(63) посмотри профайлер, если интересно, иннер - это плохая идея
72 izekia
 
14.07.12
17:49
(70) чопростите?
73 izekia
 
14.07.12
17:50
давай ты сначала перестанешь нести чудесную чушь, а потом уже будешь требовать, чтобы с тобой общались уважительно
74 andrewks
 
14.07.12
17:51
(72) наверное, он хотел сказать: план запроса, который построит СУБД, зависит от того текста низкоуровневого запроса, который отдаст сервер 1С
75 rs_trade
 
14.07.12
17:51
(70) с терминами то поаккуратней )) а то щас какашками закидают. или с терминами все точно?
76 andrewks
 
14.07.12
17:52
(71) не факт. надо тестить
77 izekia
 
14.07.12
17:52
(74) ну да, веселый чувак ... в целом, если так подумать, то несомненно в какой-то мере зависит ))
78 izekia
 
14.07.12
17:53
(76) что тестить ... в одном кластер скан, в другом два кластерскана и слияние
79 mirosh
 
14.07.12
17:55
имеется в виду, что нельзя полагаться на оптимизатор запроса SQL, если сам текст запроса на языке 1С "неоптимизирован"
80 izekia
 
14.07.12
17:55
индекс там у тч, что и естественно
81 izekia
 
14.07.12
17:56
(79) это ты про план запроса на сервере 1С?
82 mirosh
 
14.07.12
17:57
(81) про него
83 andrewks
 
14.07.12
17:58
(81)(82) О_о  субботница?
84 Torquader
 
14.07.12
17:58
Вы ещё вспомните потом про результат обработки запроса - если его не будут выгружать в таблицу, а будут обходить построчно (при этом ещё чего-то выполняя), то может оказаться, что разбив на несколько независимых запросов мы получим ускорение, так как блокировок не будет.
85 izekia
 
14.07.12
17:58
(82) на уровне конструктора запроса может быть)
86 rs_trade
 
14.07.12
17:59
(84) мощно. такое было да? наверное это было весело.
87 izekia
 
14.07.12
18:00
(84) а если блокировки начнутся как раз на момент обхода?
88 mirosh
 
14.07.12
18:00
(84) про это речи не идет
89 izekia
 
14.07.12
18:04
(79) + (82) текст оптимизируется только в голове у автора, и соответственно в коде, даже конструктор запроса не помогает в этом прекрасном деле, вполне пропустил такое:
ВЫБРАТЬ
   ПользователиКонтактнаяИнформация.Тип,
   ПользователиКонтактнаяИнформация.Представление
ИЗ
   Справочник.Пользователи.КонтактнаяИнформация КАК ПользователиКонтактнаяИнформация
       ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Пользователи КАК Пользователи
       ПО ПользователиКонтактнаяИнформация.Ссылка = Пользователи.Ссылка
и сервер 1С тоже не помогает оптимизировать текст запроса:
SELECT
T1._Fld422RRef,
T1._Fld424
FROM _Reference49_VT420 T1 WITH(NOLOCK)
LEFT OUTER JOIN _Reference49 T2 WITH(NOLOCK)
ON (T1._Reference49_IDRRef = T2._IDRRef)

но это и правильно, потому что субд чаще всего не будет отрабатывать соединение и сама откинет все ненужное
90 andrewks
 
14.07.12
18:05
собственно, основной момент: конспирологический. нет уверенности, что 1С протранслирует любой сложный запрос с неявными соединениями идентично аккуратным явным соединениям
91 izekia
 
14.07.12
18:05
(90) ну да, я пробовал простенькие, но там все корректно, думаю буду переходить на такой вариант
92 Torquader
 
14.07.12
18:06
На самом деле - очень интересно, что получит запрос, если в момент его исполнения мы поменяем какой-то элемент справочника.
(87) Если объект заблокирован транзакцией на запись, то всё будет зависеть от режима выполнения транзакций - мы же читаем в другой транзакции - в "правильном" случае мы будем ждать окончания записи - в остальных - получим что-то или до или после.
93 mirosh
 
14.07.12
18:07
(92) "На самом деле - очень интересно, что получит запрос, если в момент его исполнения мы поменяем какой-то элемент справочника. "
Все что угодно :). Модно ведь использовать ДЛЯ ИЗМЕНЕНИЯ
94 Torquader
 
14.07.12
18:07
(90) А как она его ещё может выполнить ? Табличная часть - это соединение один на много и как ни крути, его придётся как-то выбирать.
95 izekia
 
14.07.12
18:08
(93) не отвлекайся, теперь меня интересует что ты имел в виду под оптимизацией запроса на сервере 1С
96 mirosh
 
14.07.12
18:08
(95) где я говорил про оптимизацию за сервере 1С?
97 izekia
 
14.07.12
18:09
(94) речь идет о степени доверия генератору, тем более в свое время рекомендовали писать соединения явно
98 Torquader
 
14.07.12
18:09
(93) Просто в случае параллельной работы весь спор о быстроте - это рассуждения ни о чём - нужно же получать правильные данные и создавать наименьшую нагрузку на базу при этом.
99 izekia
 
14.07.12
18:09
(96) план запроса, простите
100 izekia
 
14.07.12
18:10
(70) + (82) ты про какой план запроса?
101 Torquader
 
14.07.12
18:10
(97) А почему они тогда запрещают писать запросы напрямую в SQL, где можно ещё и план выполнения задать.
102 mirosh
 
14.07.12
18:12
(99) имелся в виду текст, сгенерированный сервером 1С, который не всегда просто берет и копирует текст, написанный в модуле
103 andrewks
 
14.07.12
18:12
(101) потому, что тогда 1С начнёт работать сразу очень быстро, и ихние обновления никому нафиг не нужны будут :)
104 izekia
 
14.07.12
18:12
(102) это не план запроса, а просто сгенерированный запрос, аккуратнее с терминами
105 izekia
 
14.07.12
18:13
(103) лол)
106 izekia
 
14.07.12
18:13
(101) потому что 1С - это орм
107 izekia
 
14.07.12
18:14
в 9.0 думаю появится такое
108 Torquader
 
14.07.12
18:14
Она же позволяет узнать имя таблицы, в которой живут данные - значит - подразумевается, что мы туда можем заглянуть.
109 izekia
 
14.07.12
18:15
(108) в целях анализа узких мест, а не работы с субд
110 Torquader
 
14.07.12
18:16
Кстати, разница в производительности может быть не только из-за текста запроса и скорости его выполнения, но и из-за способа хранения результата в памяти программы - если просто соединение - это линейная таблица, то выбор табличной части подразумевает дерево.
111 izekia
 
14.07.12
18:22
(110) это вообще зло, на мой взгляд
112 izekia
 
14.07.12
18:23
да и простите, в (41) погорячился
113 Torquader
 
14.07.12
19:42
(111) Просто обсуждать скорость выполнения SQL-запроса, когда в реальности происходит сначала передача запроса на сервер, потом трансляция запроса из 1С в SQL, выполнение его SQL-сервером, передача результата обратно (чаще всего по сети), потом выдача результата запроса на клиента, где информация уже будет отображаться.
Так что нужно анализировать весь путь.
Основная теорема систематики: Новые системы плодят новые проблемы.