|
Работа с большим объемом информации | ☑ | ||
---|---|---|---|---|
0
yaroshenko_p
27.10.15
✎
19:13
|
Доброго времени суток!
У меня такая проблема, помогите, пожалуйста. Есть база УТ 11.1, подключена по технологии Клиент-сервер В ней большой справочник "Партнеры" - порядка 200000 записей. Есть выгруженная из внешнего источника данных таблица телефонных звонков с графами "Длительность звонка" и "Телефонный номер", количество строк может быть любым. Требуется по телефонному номеру найти партнеров для всех строк из этой таблицы. Я написал процедуру примерно такого вида: &НаСервере Процедура СопоставитьПартнеров() //Операторы загрузки данных из внешней таблицы в таблицу значений ВнешТЗ ... //Попытка найти партнеров по номеру телефона Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ * |ПОМЕСТИТЬ ВнешТЗ |ИЗ &ВнешТЗ КАК ВнешТЗ |; |ВнешТЗ.ДлительностьЗвонка КАК Длительность, |ВнешТЗ.ТелефонныйНомер КАК ТелефонныйНомер, |ПартнерыКИ.Ссылка КАК Партнер |ИЗ |ВнешТЗ КАК ВнешТЗ |ЛЕВОЕ СОЕДИНЕНИЕ |Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКИ |ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона)"; Запрос.Параметры.Вставить("ВнешТЗ", ВнешТЗ); Рез = Запрос.Выполнить(); //Дальнейшая обработка результата запроса ... КонецПроцедуры Проблема такая: Если во внешней таблицы записей немного (в пределах 1000), то запрос отрабатывает нормально. Но если их передано очень много (порядка 100000), то на выполнении запроса 1С мертво подвисает на несколько часов, и вместе с ней подвисает и сервер, на котором она установлена, т.е. не могут работать и другие пользователи этой базы, и даже пользователи других программ, установленных на этом сервере. Подскажите, пожалуйста, как грамотно получить данные из справочника партнеров, чтобы запрос выполнялся быстрее, или хотя бы чтобы он не подвешивал сервер. Заранее благодарен |
|||
1
Рэйв
27.10.15
✎
19:17
|
>"ВЫБРАТЬ * это конечно очень оптимистично...
|
|||
2
Casey1984
27.10.15
✎
19:20
|
Для начала определить когда зависает? Например попробовать просто передать внешнюю таблицу в запрос. Если все ОК, то работать с запросом - оптимизировать (индексы, строка ограниченой длины вместо неограниченной, номер телефона в виде числа и т.п.). Не должно так тормозить.
|
|||
3
yaroshenko_p
27.10.15
✎
19:28
|
Спасибо, Casey1984! Зависает при сравнении со справочником партнеров. Сама внешняя таблица передается в запрос моментально, уже пробовал. А вот индексы пока не использовал.
|
|||
4
Скай
27.10.15
✎
19:36
|
Думается, что проблема где-то тут.
|ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона) |
|||
5
МихаилМ
27.10.15
✎
19:40
|
представляю размер tempdb на сервере.
|
|||
6
Rlogin
27.10.15
✎
19:58
|
Из внешней ТЗ выбирай интервалами по 10000 записей например
|
|||
7
echo77
27.10.15
✎
20:18
|
Индексировать таблицу?
|
|||
8
GenV
27.10.15
✎
20:57
|
(0) Если привести телефонные номера к единому общему формату (преобразовав предварительно внешние данные и данные в базе кодом), то пропадет необходимость в ПОДОБНО. Это значительно ускорит запрос.
|
|||
9
Tateossian
27.10.15
✎
21:02
|
(5) Ты не дооцениваешь возможности СУБД.
|
|||
10
H A D G E H O G s
27.10.15
✎
21:07
|
Я один не понимаю смысла использовать ПОДОБНО вместо = в данном конкретном случае?
|
|||
11
Tateossian
27.10.15
✎
21:08
|
(0) Сделай так - сгруппируй внешнюю таблицу по телефонному номеру, соедини с партнёрами, а потом соединяй по равенству поля телефонный номер.И юзай ВЫРАЗИТЬ(ТелефонныйНомер КАК СТРОКА(15))ТелНомер
|
|||
12
Скай
27.10.15
✎
21:14
|
(10) ну у него в базе номера, может, то с 8, то с +7 начинаются, а во внешней таблице вообще без кода
|
|||
13
H A D G E H O G s
27.10.15
✎
21:21
|
(12) нет
|
|||
14
H A D G E H O G s
27.10.15
✎
21:22
|
(12) тогда условие выглядит так:
ПО ПартнерыКИ.НомерТелефона ПОДОБНО(ВнешТЗ.ТелефонныйНомер+""%"") |
|||
15
H A D G E H O G s
27.10.15
✎
21:24
|
Без подстановочных знаков ПОДОБНО не имеет смысл. Единственный вариант - эти знаки уже в самих таблицах, но чето врядли.
|
|||
16
H A D G E H O G s
27.10.15
✎
21:25
|
(14) Пардон, условие тогда
ПО ПартнерыКИ.НомерТелефона ПОДОБНО(""%""+ВнешТЗ.ТелефонныйНомер) |
|||
17
H A D G E H O G s
27.10.15
✎
21:26
|
(16) Об индексе при этом можно забыть. Тут индексы вообще не отработают от слова Никогда, пока ПОДОБНО не заменим на =. Но это не значит, что ПОДОБНО не может работать с индексами.
|
|||
18
roman52
27.10.15
✎
21:29
|
это разовая операция или нужно постоянно?
если разовая, то разбивай на порции как в (6) ессли постоянно, то пиши в РС, приводя телефонный номер к стандартному виду, потом соединяй с этим РС по индексированному полю безо всяких ПОДОБНО |
|||
19
miklenew
27.10.15
✎
21:52
|
|ЛЕВОЕ СОЕДИНЕНИЕ
|Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКИ |ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона) Убери во вложенный запрос. Только не спрашивай почему. Просто проверь. |
|||
20
yaroshenko_p
27.10.15
✎
22:10
|
Господа, спасибо за рекомендации!
Операция нужна будет постоянно. Прошу прощения, когда я печатал сообщение, пропустил строку ""%"". На самом деле, условие у меня выглядит именно так, как написал HADGEHOGs: ПО ПартнерыКИ.НомерТелефона ПОДОБНО(""%""+ВнешТЗ.ТелефонныйНомер) именно потому, что, как написал Скай, номера начинаются то с +7, то с 8. Про РС я уже думал - это же сильно раздует базу. Ведь на каждого партнера (а их порядка 200000, и будут еще) приходится несколько телефонов. |
|||
21
H A D G E H O G s
27.10.15
✎
22:12
|
(20)
Операция нужна будет постоянно. Добавить индексированное поле НомерТелефонаВнешний и искать сначало (первым запросом) по нему по точному соответствию. |
|||
22
RomanYS
27.10.15
✎
22:14
|
(20) 200000 элементов * 10 номеров * 100 байт (ссылка+номер и на комментарий останется) = 200 МБ
|
|||
23
yaroshenko_p
27.10.15
✎
22:23
|
Добавить индексированное поле
НомерТелефонаВнешний и искать сначало (первым запросом) по нему по точному соответствию. Я не упомянул, что мне запрещено менять объекты типовой (в т.ч. справочник "Партнеры") |
|||
24
France
27.10.15
✎
22:24
|
ут 11... и контактные данные... это, если мягко выражаться, очень жесткое место для приземления..
|
|||
25
Скай
27.10.15
✎
22:25
|
Регламентом выбирать только свежие записи. Какую-нить бд из телефонии парсишь?
|
|||
26
Скай
27.10.15
✎
22:25
|
Там же наверняка дата звонка есть. Вот и тягай только свежие
|
|||
27
yaroshenko_p
27.10.15
✎
22:30
|
Да, SQL-базу из Asterisk. Там в таблице еще много полей (даты начала и окончания звонка, код провайдера и т.д.), просто я указал в коде только два поля для того, чтобы объяснить суть проблемы.
|
|||
28
Скай
27.10.15
✎
22:31
|
Знакомо. Ну так все просто, первоначальное заполнение в 1С делаешь просто по периодам, в первом запросе через where выборку ограничить. А потом регламентное задание раз в день, к примеру, которое только сегодняшние звонки получает.
|
|||
29
Скай
27.10.15
✎
22:32
|
А так, проблема в ПОДОБНО помноженном на большое число записей.
|
|||
30
yaroshenko_p
27.10.15
✎
22:35
|
Уважаемый Скай! Дата звонка есть, и записи оттуда тягаются только свежие (раз в 15 минут), и процедура отрабатывала до сих пор нормально. Просто сейчас потребовалось провести повторную закачку звонков за месяц, вот тут-то и выяснилось, что код проблемный
|
|||
31
mistеr
27.10.15
✎
22:36
|
(23) Хочешь быстро - нормализуй номера там и там, и ищи по равенству иди хотя бы по префиксам.
(27) Или выгрузи партнеров в тот SQL, где Asterisk, и сопоставляй там. Там ты не будешь связан ограничением "запрещено менять объекты типовой" и сможешь делать любые преобразования создавать нужные индексы. |
|||
32
yaroshenko_p
27.10.15
✎
22:40
|
Или выгрузи партнеров в тот SQL, где Asterisk, и сопоставляй там
Тогда получается, что нужно будет регулярно выкачивать новых партнеров в SQL-базу Asterisk. Хотя тоже вариант... |
|||
33
Asirius
27.10.15
✎
22:52
|
я бы для начала выбрал РАЗЛИЧНЫЕ из ВнешТЗ.ТелефонныйНомер, может там из 200000 только 1000 постоянно названивают, потом бы заморочился с нормализацией
|
|||
34
mistеr
27.10.15
✎
23:45
|
(32) Прикинь, сколько появляется новых партнеров и сколько звонков. Звонков явно больше.
|
|||
35
GenV
28.10.15
✎
00:31
|
(23) Так в УТ 11 есть доп. реквизиты без изменения типовой или в прочую контактную информацию нормальный телефон записать. Трудозатраты на ведение внешней базы без ошибок и с правильной синхронизацией не соответствуют "лишней" записи для каждого нужного партнера.
|
|||
36
miklenew
29.10.15
✎
18:53
|
Человеку сказали попробуй вложенный запрос, ноль реакции. Баклан какой-то
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |