|
Есть ли способ ускорить выполнения запроса? | ☑ | ||
---|---|---|---|---|
0
ytex
16.11.16
✎
11:50
|
Добрый день.
В справочнике Партнеров, есть реквизиты: телефон и почтовый адрес. Необходимо запретить создание и сохранение нового партнера, если уже использовался данный номер телефона или почты. ВЫБРАТЬ ПартнерыКонтактнаяИнформация.Тип, ПартнерыКонтактнаяИнформация.Представление ИЗ Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКонтактнаяИнформация ГДЕ ПартнерыКонтактнаяИнформация.Тип = &Тип И ПартнерыКонтактнаяИнформация.Представление = &Представление В справочнике содержаться 3-4 тыс элементов, понятно что запрос по поиску совпадений выполняется долго, подскажите можно ли ускорить запрос? что можно сделать, чтобы поиск выполнялся быстрее? |
|||
1
Господин ПЖ
16.11.16
✎
11:51
|
в индекс не попадаешь
|
|||
2
Лефмихалыч
16.11.16
✎
11:53
|
(1) а его и не может быть, индекса - представление неограниченной длины.
Решение - вынести "использованные" телефоны в отдельный РС, где они будут храниться в индексированном поле ограниченной длины. И искать по нему перед записью, а не по ТЧ. В РЧ записывать при записи партнера |
|||
3
Лефмихалыч
16.11.16
✎
11:57
|
а если представление ограниченной длины, то можно просто индексирование включить у полей Тип и Представление.
|
|||
4
mistеr
16.11.16
✎
12:52
|
(0) Можно попробовать полнотекстовый поиск.
|
|||
5
HardBall
16.11.16
✎
15:33
|
(0) Почему должно быть понятно, что запрос выполняется долго?
Где Номер телефона и почты в запросе? 3-4 тысячи элементов это много? Что творится? |
|||
6
MrStomak
16.11.16
✎
15:40
|
(0) А давай использовать для поиска не Представление, и НомерТелефона (если мы говорим про подсистему КИ из БСП)?
Индекс по нему включил и всё, проблемы нет. |
|||
7
MrStomak
16.11.16
✎
15:42
|
(3) Вот это плохой совет.
Если индексирование включить у "Тип" и "представление", то будет 2 индекса, которые не пересекаются. Фактически СУБД сможет использовать для поиска только 1 из них. Нужно самому выбирать наиболее селективный реквезит, т.е. "Представление" (но на самом деле - НомерТелефона =]) |
|||
8
rphosts
16.11.16
✎
15:42
|
>ПартнерыКонтактнаяИнформация.Представление = &Представление
ужас! |
|||
9
rphosts
16.11.16
✎
15:42
|
хотя юзера со своими хотелками такие юзера...
|
|||
10
rphosts
16.11.16
✎
15:44
|
(3) достаточно по типу... представление в 8.3.5 и далее можно менять программно.
|
|||
11
MrStomak
16.11.16
✎
15:45
|
(10) Представление - это реквизит табличной части. Строка(500).
|
|||
12
Лефмихалыч
16.11.16
✎
15:46
|
(7) вообще да. Но, кстати, отбор по типу в запросе тут нах не нужен, раз там равенство.
|
|||
13
rphosts
16.11.16
✎
15:48
|
(11) да лана, модуль магнагера справочника:
Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка) бла-бла-бла КонецПроцедуры 8.3.6.2152 если чё |
|||
14
H A D G E H O G s
16.11.16
✎
15:49
|
Интересно, СУБД когда-нибудь допилят до хранения хэша поля, которое указал программер в дизайнере?
|
|||
15
MrStomak
16.11.16
✎
15:50
|
(13) Ты еще раз перечитай, чтоли - Представление - это реквизит табличной части конкретного справочника. Его так назвали. А могли назвать ПредставлениеКотороеНеФункцияПредставленияСправочникаЧтобыНиктоНеПерепутал. Но не стали.
|
|||
16
MrStomak
16.11.16
✎
15:51
|
(14) Не понял тебя, раскрой мысль
|
|||
17
rphosts
16.11.16
✎
15:51
|
(14) это анрил, я-ж могу какой угодно код в зависимости от чего угодно туда запихать...
(11) хотя если конфа под желтым замков - можно и так, но без гарантий, что после очередного обновления не перестанет работать |
|||
18
H A D G E H O G s
16.11.16
✎
15:52
|
(14) Ну и его асинхронное обновление. И глобальные флаг у таблицы "ХешПоляПредставлениеАдресаАктуален". И искать уже по нему, а не по мегабайтам сырых данных.
|
|||
19
MrStomak
16.11.16
✎
15:52
|
(12)
Ну как бы да. Тут только есть чисто техническая возможность указать адрес в номере телефона и получить два разных типа на одном представлении... Так что на всякий случай лучше доотбирать тип... |
|||
20
H A D G E H O G s
16.11.16
✎
15:53
|
(18) Это технически на порядок проще, чем полнотекстовый поиск.
|
|||
21
H A D G E H O G s
16.11.16
✎
15:54
|
(17) По моему ты чет не вкурил. Или я не понял твоих мыслей.
|
|||
22
Лефмихалыч
16.11.16
✎
15:54
|
(19) если так будут делать, то их ни чего не спасет
|
|||
23
H A D G E H O G s
16.11.16
✎
15:55
|
При этом хеш - тип данных - фиксированный, хранится в самих страницах данных таблицы, за ним не надо лезть в страницы потоковых данных как с сырыми данными, вот он тут.
|
|||
24
MrStomak
16.11.16
✎
15:56
|
(23) Какую задачу всё это будет решать? Поиск - а есть ли уже такое? Опиши сценарий использования, непонятно.
|
|||
25
H A D G E H O G s
16.11.16
✎
16:00
|
(24) Поиск по "сырому" полю. Для искомого значения строим хеш и ищем по колонке "хеш", которую можно (и нужно) проиндексировать. Ну а потом keylookup, что лучше чем scan.
|
|||
26
H A D G E H O G s
16.11.16
✎
16:01
|
Соединение по сырым полям 2-х таблиц. Вместо сырых полей подставляются поля с из хешем.
|
|||
27
H A D G E H O G s
16.11.16
✎
16:02
|
Да и сам алгоритм сравнения 2 х хешей занимает меньше ресурсного времени чем сравнение 2-х сырых данных.
|
|||
28
MrStomak
16.11.16
✎
16:02
|
(25) В чем принципиальное отличие от индекса, кроме невозможности использования условий на больше-меньше?
|
|||
29
MrStomak
16.11.16
✎
16:03
|
(25) Для keylookup нужно знать позицию строки в таблице. Где она будет? Как будет поддерживаться актуальность этой информации?
|
|||
30
H A D G E H O G s
16.11.16
✎
16:05
|
Мне лениво пытаться тебе объяснять. Я уже все объяснил и не понимаю, что тебе не понятно.
|
|||
31
MrStomak
16.11.16
✎
16:47
|
(30)
Ну сложно понять твою мысль. Судя по упоминанию неких "потоковых страниц" и "просто" страниц - речь идёт о LOB-объектах, т.е. мы говорим про поле неограниченной длины, т.е. про текст. Ну, возможно, просто поля большой длины в отдельные страницы попадают. При использовании отдельного поля хэша сократится размер поля и оно будет хранится на тех же страницах, что и данные. Выигрыш в алгоритме сравнения тут будет из-за меньшей длины хэша. Получается, сценарий поиска по большим текстовым полям можно ускорить за счет использования хэша. По другим полям - число, ссылка, дата и т.д. работать не будет, их размер едва ли будет больше хэша. Невозможен частичный поиск. Вывод - полнотекстовый поиск тут предоставляет большую гибкость и функциональность, задача поиска по большим текстам на равенство достаточно редкая. |
|||
32
Вафель
16.11.16
✎
17:02
|
Так хэш можно и самому сделать, не нужно платформу ждать
|
|||
33
MrStomak
16.11.16
✎
17:09
|
(32) Нужно тогда будет вручную предусматривать коллизии, т.е. хэш не обладает уникальностью, нужно выполнять поиск по хэшу, потом догонять сравнение уже по исходным полям, удаляя оттуда ошибочные записи из-за дублей хэша.
Всё это конечно можно сделать, но в реальности зачем это применять, не совсем понятно. Точнее как - кейс из (0) как раз может быть ускорен таким образом, но есть и более простые способы оптимизировать такой поиск... |
|||
34
H A D G E H O G s
16.11.16
✎
17:55
|
(31) Ну вот отлично, ты понял :-)
Полнотекстовый поиск работает для текстов или и для бинарных данных? |
|||
35
Вафель
16.11.16
✎
17:56
|
(33) А можно справочник замутить тогда, где хэш будет - гуид )))
|
|||
36
H A D G E H O G s
16.11.16
✎
17:57
|
(31) nvarchar храниться в блоб объектах при любом своем размере.
|
|||
37
H A D G E H O G s
16.11.16
✎
18:04
|
(31) Ну и как плюс - можно вообще не записывать новые сырые данные, если их хэш не поменялся. Что до коллизий - их вероятность крайне мала, их можно отслеживать но вот что делать при их возникновении - мне не понятно.
|
|||
38
MrStomak
16.11.16
✎
20:04
|
(34) Уж не знаю ли, можно ли заставить поднотекстовый поиск индексировать двоичные данные, но смысла в этом не вижу никакого. Сохранится одно большое слово и места будет занимать в несколько раз больше, чем сами двоичные данные.
(36) Ну нет же! Тогда НайтиПоКоду работал бы через задницу. nvarchar(n) хранит себя в строке данных, nvarchar(max) по умолчанию - тоже, если не превысит 8Кб или для таблицы явно не задано свойство хранить его снаружи. (37) Ну это уже первая нормальная форма, или вторая - не помню. Понятно, что любые повторяющиеся значения имеет смысл хранить в отдельной таблице. Вероятность коллизий, понятно, зависит от алгоритма, на таблицах с миллионами записей получать дубли более чем реально. Делать с ними то же, что движок ms sql делает при hash match - найденные по хэшу записи дополнительно отфильтровать на совпадение "сырых", как ты говоришь, полей. |
|||
39
EvgeniuXP
16.11.16
✎
20:44
|
У меня фотки быстро одинаковые ищет если присвоена другому сотруднику, а тут "представление" с типом строка длиной 500 долго :) и в 3ххх :)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |