Имя: Пароль:
1C
1С v8
Регистр сведений, медленный запрос
, ,
0 AntonU
 
19.11.14
11:14
Здравствуйте!
Есть непериодический независимый регистр сведений РегистрДанных
Требуется делать много запросов вида

        Запрос=Новый Запрос;
    Запрос.Текст="ВЫБРАТЬ ПЕРВЫЕ 1
                 |    РегистрДанных.ПроцентВозн
                 |ИЗ
                 |    РегистрСведений.РегистрДанных КАК РегистрДанных
                 |ГДЕ
                 |    РегистрДанных.Дата <= &ДатаОт
                 |    И РегистрДанных.Договор = &Договор
                 |    И РегистрДанных.ТипСтр = &ТипСтр
                 |
                 |УПОРЯДОЧИТЬ ПО
                 |    РегистрДанных.Дата УБЫВ";

Эти запросы работают слишком медленно. Можно ли как-то оптимизировать запрос/структуру регистра для ускорения работы запроса?
Как я понимаю, замедляет работу условие РегистрДанных.Дата <= &ДатаОт, но что можно сделать?
1 AntonU
 
19.11.14
11:15
Структура регистра - измерения дата, договор, ТипСтр (строка), ресурс - ПроцентВозн (число)
2 Галахад
 
гуру
19.11.14
11:16
Срезпоследних
3 Галахад
 
гуру
19.11.14
11:17
И регистр переодическим.
4 Ненавижу 1С
 
гуру
19.11.14
11:18
зачем МНОГО?
5 pessok
 
19.11.14
11:18
+(3) и убрать Дата из измерений
6 Иоканаан
 
19.11.14
11:20
+(3) И в запросе по СрезПоследних условия отбора задавать в параметрах Среза, а не в ГДЕ.
7 Крошка Ру
 
19.11.14
11:30
(0) А "делать много запросов" - это ты чисто случайно не в цикле их делаешь? По каждому договору, например?
8 Крошка Ру
 
19.11.14
11:30
На всякий случай спросил
9 User_Agronom
 
19.11.14
11:35
(7) Да. Поясни этот момент.
10 AntonU
 
19.11.14
11:36
Да, в цикле, т.к. разные даты и ТипСтр
11 pessok
 
19.11.14
11:37
ПриВыводеСтроки :D
12 Wobland
 
19.11.14
11:39
(10) и даже не догадался попробовать разом получить всё нужное? я уж помолчу о наименованиях
13 pavelul73
 
19.11.14
11:39
Делай условие в запросе Договор В (&ТвоиДогвора)
14 piter3
 
19.11.14
11:40
ТипСтр (строка) зачем? неограниченная небось еще
15 Wobland
 
19.11.14
11:41
(14) это тип страданий, перечисление
16 ssh2QQ6
 
19.11.14
11:42
(0) > Эти запросы работают слишком медленно.

Нормальный запрос. Другое дело может ты ими заваливаешь сервер или железо слабое. Другой подход нужен - уменьшить число запросов.
17 pessok
 
19.11.14
11:42
ну может там комментарии к документам хранятся
18 AntonU
 
19.11.14
11:44
Разом можно получить таблицу значений, но поторм как-то из нее в цикле нужные строки извлекать кажется тоже не слишком удобным.
ТипСтр - да, перечисление
19 User_Agronom
 
19.11.14
11:45
(10) Сформируй ТаблицуЗначений и передавай её в запрос.
Таким образом запрос будет один.
20 ssh2QQ6
 
19.11.14
11:45
(18) протестируй, сравни результат. Нужные колонки в таблице значений можно проиндексировать
21 hhhh
 
19.11.14
11:52
(18) зато это будет в 1000 раз быстрее. Или в 10000 раз. Наплюй на неудобства. Производительность рулит.
22 pessok
 
19.11.14
11:55
а еще можно сделать пакет, и отдельно выгрузить таблицы по типстр
23 Drac0
 
19.11.14
11:57
(0) А индексы-то есть?
24 Drac0
 
19.11.14
11:57
(19) +100500
25 18_plus
 
19.11.14
11:58
"Разом можно получить таблицу значений, но поторм как-то из нее в цикле нужные строки извлекать кажется тоже не слишком удобным."

это просто прекрасно.
26 ssh2QQ6
 
19.11.14
11:58
(23) см (1) [Структура регистра - измерения дата, договор,]
27 GANR
 
19.11.14
11:58
(16) Я считаю, что сейчас плохого железа нет - бывают плохие структуры данных. Индексы, денормализация и все такое прочее прекрасно решают эти проблемы. Вот как легче в бибилиотеке найти книгу - перекопать всю библиотеку или подойти к каталогу (считай, индексу)? Вот то-то же...
28 AntonU
 
19.11.14
11:59
Индексы есть, буду пытаться пакеты по типстр и договору формировать, но это не слишком удобно реализовывать к сожалению.
29 18_plus
 
19.11.14
12:02
(25) подозреваю, что ТС получит ТаблицуЗначений и будет делать
тз.НайтиСтроки(ПредварительноСозданныйОтборС_ДатаОт_Договор_ТипСтр)
30 User_Agronom
 
19.11.14
12:03
(29) Ни в коем разе. Он правильно сгруппирует и выгрузит деревом. А потом сделает обход по группировкам.
31 GANR
 
19.11.14
12:03
(28) И еще оптимизация базируется на неожиданно простых вещах, например: есть условия A and B, так вот если A = false, то B - не проверяется, если речь идет A or B тогда если A = true B не проверяется (на проверку может тратиться оооочень немало времени. Улавливаете?
32 GANR
 
19.11.14
12:04
+(31) Может, попробовать условия местами поменять - запрос быстрее может пойти существенно.
33 ssh2QQ6
 
19.11.14
12:05
(27) плохого нет, бывает железо неподходящее под задачи. Запрос в (0) попадает в индекс. Проблемы в их количестве в еденицу времени.
34 ssh2QQ6
 
19.11.14
12:06
(32) в этом случае это конечно это никак не повлияет на результирующий запрос в бд
35 User_Agronom
 
19.11.14
12:07
Это не так. Если выражение-операнд B имеет синтаксическую или логическую ошибку, то она вывалится даже в случае описанном в (31)
36 GANR
 
19.11.14
12:09
(34) Это может точно знать только ТС - форум не видит его данные. (10) Тогда стоит возможно стоит попробовать состряпать ТЗ, потом загнать ее в запрос и соединить с данными регистра.
37 Drac0
 
19.11.14
12:09
(26) И что? Он не мог сделать неиндексируемые измерения?
38 GANR
 
19.11.14
12:10
(27) Да, запрос в цикле - в большинстве случаев это беда
39 GANR
 
19.11.14
12:11
(38) к (33)
40 ssh2QQ6
 
19.11.14
12:11
(37) > Он не мог сделать неиндексируемые измерения?

Для такого запроса не нужно специально индексировать. Достаточно "платформенного" индекса

Измерение1 + [Измерение2 +...] (Кластерный)
41 Drac0
 
19.11.14
12:23
(40) Условие <= попадет в кластерный индекс?
42 vogenut
 
19.11.14
12:25
(0) Измерение Дата должно быть последним в регистре.
43 vogenut
 
19.11.14
12:26
(42) Индексировать измерения не нужно. Основной индекс по умолчанию идеально подойдет.
44 Крошка Ру
 
19.11.14
12:26
О, ну пошли советы по оптимизации...

Пусть ТС сначала запрос из цикла вытащить. Ставлю 10 баксов, что ему такого выигрыша в производительности с головой хватит.
45 Широкий
 
19.11.14
12:27
(0) Думается что проблема из-за измерения ТипСтр (строка) - у него размерная какая?
46 Wobland
 
19.11.14
12:28
я гляжу, тут никто никто не обратил внимание ни на тип ТипСтра, ни на непериодичность регистра
47 hhhh
 
19.11.14
12:28
(45) ну, ему неудобно вытаскивать.
48 18_plus
 
19.11.14
12:29
(44) сначала надо вытащить запросы в цикле из программиста :)
49 ssh2QQ6
 
19.11.14
12:33
(41) да
50 H A D G E H O G s
 
19.11.14
12:36
(49) Да, но для неподчиненного регистратору.
Для РС подчиненного регистратору, SQL чаще предпочтет clastered index scan, нежели indexseek по некластерному по измерениям + keylookup.
51 AntonU
 
19.11.14
12:40
ТипСтр - перечисление.
Без цикла - легко могу вытащить таблицу данных регистра по договорам с колонками
Договор, Дата, ТипСтр, ПроцентВозн.

Но как потом из этой таблицы извлекать данные по конкретному договору, дате, типуСтр ? Или получится один огромный запрос, подозреваю, систему повесит... очень много данных
52 AntonU
 
19.11.14
12:42
В таблице данных регистра - строк не слишком много, а вот входяще данные договор/дата/типстр - там много тысяч элементов...
53 AntonU
 
19.11.14
12:42
Даже сотни тысяч могут быть
54 hhhh
 
19.11.14
12:43
(53) если данных меньше 10 миллионов строк, то по- любому один запрос будет быстрее.
55 AntonU
 
19.11.14
12:44
По одному договору. ПроцентВозн меняется не часто.
56 Drac0
 
19.11.14
12:44
(51) Ты в цикле еще и данные через точку извлекаешь? 0_0
57 Любопытная
 
19.11.14
12:45
(51) Может озвучишь задачу, а не твое видение ее решения?
58 Крошка Ру
 
19.11.14
12:45
(51) То есть у тебя лучше получается с запросами, чем с таблицами значений?
(53) Ну и что? А так у тебя каждый запрос по каждому договору считывает тот миллион записей, что находится в регистре.
59 AntonU
 
19.11.14
12:45
(53) - думаю, меньше, а в таблицу сколько строк можно класть по максимуму?
60 Крошка Ру
 
19.11.14
12:47
(59) Этот вопрос регулируется исключительно твоей совестью
61 hhhh
 
19.11.14
12:47
(59) да, и все данные договора тоже в запрос кинь. Это еще раз в 70 уменьшит время запроса.
62 Bober
 
19.11.14
12:48
(0)
- сколько записей в регистре
- какой длины строка в  измерении ТипСтр
- когда последний раз было обновление индексов
63 Bober
 
19.11.14
12:49
(0)
какой порядок измерений в регистре?
64 Крошка Ру
 
19.11.14
12:51
(62)(63) "... и в забег включается новый участник!"
65 hhhh
 
19.11.14
12:54
(62) "ТипСтр - перечисление."
66 AntonU
 
19.11.14
12:55
Измерения
Договор - СправочникСсылка
ТипСтр - Перечисление

Ресурсы
ПроцентВозн - Число

Есть много (за месяц - около миллиона) элементов справочника "ВходящиеДанные" с реквизитами "Дата (дата+время), Договор, ТипСтр (перечисление), Сумма".

Нужно для каждого элемента справочника найти соотв. ресурс регистра процентВозн (по дате/договору/типСтр) и сосчитать Сумма*ПроцентВозн с итогами по договорам
67 Bober
 
19.11.14
12:57
(66) Дата из периодичности регистра?
68 AntonU
 
19.11.14
12:57
Причем соотв. ресурс регистра процентВозн ищется по условию
ДатаВРегистре <= ДатаВход (т.е. ближайшая дата из регистра).

Регистр сделадл периодическим
69 AntonU
 
19.11.14
12:57
Но записи в регистре не за все даты
70 Bober
 
19.11.14
12:58
(66) тормозит выполнение одного запроса или запросов в цикле?
71 Bober
 
19.11.14
12:59
(69)  когда в запросе (0) идет упорядочивание, то нужна будет только первая запись или просто подготавливается таблица в выводу?
72 Drac0
 
19.11.14
13:00
(66) "Есть много (за месяц - около миллиона) элементов справочника "ВходящиеДанные" "

Таак ,а зачем вообще тогда нужна ТЗ или еще что? Почему в запросе бы не работать с этим справочником?
73 AntonU
 
19.11.14
13:02
Со справчоником работа в запросе ведется итак, но по каждому элементу справочника нужно извлекать соотв. данные из регистра, если это делать поэлементно, то слишком долго запрос работает. Я и пытаюсь понять, как это ускорить
74 AntonU
 
19.11.14
13:03
(71) - только первая запись для конкретного элемента справочника в зав-ти от даты
75 Любопытная
 
19.11.14
13:03
(73) Т.е. ты получаешь список элементов справочника и тебе каждому элементу списка надо подобрать запись в регистре?
76 AntonU
 
19.11.14
13:06
973) - да, так
77 AntonU
 
19.11.14
13:07
Записей в справочнике - очень много, в регистре - мало
78 AntonU
 
19.11.14
13:07
(75) - да, так
79 Drac0
 
19.11.14
13:16
(78) Ты знаешь, что в запросе можно использовать ЛЕВОЕ СОЕДИНЕНИЕ или ВНУТРЕННЕЕ СОЕДИНЕНИЕ? (Про другие не буду лучше говорить)
80 AntonU
 
19.11.14
13:25
А в ТЗ.НайтиСтроки (Отбор) в отборе можно задавать условие "<=" ? Или только "равно"?
81 18_plus
 
19.11.14
13:27
(80) это шутка была, не нужно так делать
82 AntonU
 
19.11.14
13:30
(79) - понял, буду переделывать запрос
83 Drac0
 
19.11.14
13:51
(82) О, как. Даже неожиданно.
84 Bober
 
19.11.14
14:18
(82) из выше рассказанного тебе нужно заливать содержимое цикла во временную таблицу и делать срез последних по нескольким датам
http://kb.mista.ru/article.php?id=92