Имя: Пароль:
1C
1С v8
Оптимизация дин. списка на УФ с отборами по индексируемым полям
,
0 Nikifforoff96
 
01.02.19
11:54
Здравствуйте!

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

Платформа 8.3.12

Вот сам запрос:


ВЫБРАТЬ
    СправочникКнигаЗахоронений.Ссылка КАК Ссылка,
    СправочникКнигаЗахоронений.ПометкаУдаления КАК ПометкаУдаления,
    СправочникКнигаЗахоронений.Год КАК Год,
    СправочникКнигаЗахоронений.Фамилия КАК Фамилия,
    СправочникКнигаЗахоронений.Имя КАК Имя,
    СправочникКнигаЗахоронений.Отчество КАК Отчество,
    СправочникКнигаЗахоронений.Комментарий КАК Комментарий,
    СправочникКнигаЗахоронений.Кладбище КАК Кладбище,
    СправочникКнигаЗахоронений.Возраст КАК Возраст,
    СправочникКнигаЗахоронений.ДатаРождения КАК ДатаРождения,
    СправочникКнигаЗахоронений.ДатаСмерти КАК ДатаСмерти,
    СправочникКнигаЗахоронений.ДатаЗахоронения КАК ДатаЗахоронения,
    СправочникКнигаЗахоронений.ДатаОформления КАК ДатаОформления,
    СправочникКнигаЗахоронений.АдресПодачиКатафалка КАК АдресПодачиКатафалка,
    СправочникКнигаЗахоронений.Квартал КАК Квартал,
    СправочникКнигаЗахоронений.Участок КАК Участок,
    СправочникКнигаЗахоронений.Ряд КАК Ряд,
    СправочникКнигаЗахоронений.Могила КАК Могила,
    СправочникКнигаЗахоронений.НомерСвидетельства КАК НомерСвидетельства,
    СправочникКнигаЗахоронений.Заказчик КАК Заказчик
ИЗ
    Справочник.КнигаЗахоронений КАК СправочникКнигаЗахоронений


Во-первых, открывается справочник секунд 20-30. Во-вторых, отборы (со знаком равенства) по фамилии, имени, отчеству работают медленно, иногда до 3-5 секунд. Если ставить в отборе знак "содержит" база зависает на несколько минут при попытке что-либо найти, а это очень нужно заказчику. В-третьих, если снять все галочки с отборов база тоже зависает на минуту или больше.

Пробовал индексирование с доп. упорядочиванием - ничего не меняет.

Кроме ФИО заказчику необходимо искать и по другим полям, по ним также стоит индексирование. Всего на 11 реквизитах этого справочника.
Делал реиндексацию таблиц ИБ.

Как можно оптимизировать этот динамический список и ускорить поиск по нему?
1 Радим1987
 
01.02.19
12:19
Может в справочнике индексировать эти поля
2 Радим1987
 
01.02.19
12:20
Галка установлена "Динамическое считывание данных"?
3 Nikifforoff96
 
01.02.19
12:37
(2) Да, установлена. Что значит в справочнике индексировать эти поля?
4 Вафель
 
01.02.19
12:38
тут все равно фулл скан, если с отборами
5 Вафель
 
01.02.19
12:39
отдельные индексы по полям смысла имеют мало. фамилии достаточно
6 Nikifforoff96
 
01.02.19
12:45
(5) Иногда заказчик ищет только по имени и отчеству или только по адресу захоронения, состоящего из нескольких полей, не зная ФИО. На эти поля точно не нужна индексация?
7 unregistered
 
01.02.19
12:51
Полнотекстовый поиск включен? Если да, то индекс ППД актуален?

Если полнотекстовый поиск выключен, то включить его, настроить нормально его обновление и слияние. Убрать индексирование у лишних полей справочника (11 индексируемых полей для справочника - это дофуя).

А вообще стрёмная структура справочника. Нежели кто-то делает поиск, например, по 10-му участку всех кварталов всех кладбищ? Или по отчеству "Иванович" среди всех захороненных?
8 Nikifforoff96
 
10.07.19
11:24
(7) Забыл отписаться, слияние, обновление настроил. Структура справочника стрёмная, но вынужденная. Поиск ведётся как угодно, например, бывает ищут все участки, оканчивающиеся буквой "п". Или же не знают ничего, кроме Отчества и примерного участка.
9 Cyberhawk
 
10.07.19
11:26
Если ищешь через ППД, то индексы БД пофиг какие
10 FIXXXL
 
10.07.19
12:06
(0) напиши поиск ссылок запросом, отбор - только по ссылкам
11 H A D G E H O G s
 
10.07.19
12:09
(0) Можно узнать название конфишурации? Это типовое/отраслевое решение?
12 Eg0rkas
 
10.07.19
12:20
(0) на каком железе все это работает?
13 Nikifforoff96
 
24.10.19
09:26
(11) (12) Самописная конфа на БСП (из БСП только контактная информация и файлы). Файловая база, железо приличное intel i5, оперативки тоже хватает
14 hhhh
 
24.10.19
09:54
(13) что-то непонятно, 350000 покойников, это же денег, миллиарды рублей. И база, файловая, самописка, на i5. На ноуте небось.
15 xXeNoNx
 
24.10.19
09:55
(0) Мля, жестяк...
16 Ёпрст
 
24.10.19
10:03
Пометка удаления в таком справочнике.. зачет
17 unregistered
 
24.10.19
10:21
(8) >>Поиск ведётся как угодно, например, бывает ищут все участки, оканчивающиеся буквой "п".

Пи*дежь. Все участки, оканчивающиеся на "п" будут искать на определённом кладбище. На ВСЕХ кладбищах такой поиск нафиг не нужен.

>>  Или же не знают ничего, кроме Отчества и примерного участка.

Опять таки такой поиск будет с отбором по кладбищу или же с ещё какими-либо дополнительными отборами.
18 GROOVY
 
24.10.19
10:28
1. Не делать дин.списком, делать отчетом.
2. Поля проиндексировать (без доп упорядочивания, они примитивные)
3. "открывается справочник секунд 20-30" - это очень странно для приведенного запроса, с динамически считываемыми данными.
!!! Кстати, галка "произвольный запрос" установлена? Если да - убрать нафиг.
19 sqr4
 
24.10.19
10:32
Мне кажется это должен быть регистр
20 GROOVY
 
24.10.19
10:33
(19) И что изменится?
21 unregistered
 
24.10.19
10:34
(0) А какой тип имеют поля Фамилия, Имя, Отчество, Комментарий, Кладбище, АдресПодачиКатафалка, Квартал, Участок, Ряд, Могила, НомерСвидетельства, Заказчик?

Это случайно не строки неограниченной длинны?

А зачем поле Возраст при наличии ДатаРождения и ДатаСмерти?
Зачем в этой таблице поля ДатаОформления и АдресПодачиКатафалка. Это текущая "оперативная" информация. Вряд ли важен АдресПодачиКатафалка для клиентов, захороненных десять лет назад.
А какой смысл поля Год, если есть все даты - и смерти, и рождения, и захоронения?

Короче говоря, структура данных в вашей базе - это полный пи*дец.
Пригласите архитектора.

А вообще склоняюсь к тому, что полнотекстовый поиск у вас нифига не настроен нормально. Или постоянно находится в неактуальном состоянии.
22 unregistered
 
24.10.19
10:36
(19) >> ...это должен быть регистр.

Обоснуй! (с).

Лично я не вижу никакого особого смысла.
23 ptiz
 
24.10.19
10:39
ИМХО, поможет только перевод на SQL.
24 lodger
 
24.10.19
10:42
(0) фио - строковые поля? бесконечные? по другому и не будет. поставьте разумные лимиты (ну там 100 знаков), и индексирование этих полей.
25 ptiz
 
24.10.19
10:44
(13) Работа с базой идет локально или по сети?
26 pechkin
 
24.10.19
10:46
для содержит юзайте полнотекстовый поиск
27 pechkin
 
24.10.19
10:47
хотя остальных поисков можно индексов поднакидать в скл.
посмотреть какие чаве всего нужны и их добавить
28 unregistered
 
24.10.19
10:49
(23) Перевод на SQL конечно поможет.
Но всё равно, по-моему, даже на файловой не должно так жестко тупить.
29 unenu
 
24.10.19
11:25
350К записей и файловая база на i5, что тут можно оптимизировать?

ответ - ничего.
30 unenu
 
24.10.19
11:25
вероятно еще и диск не SSD
31 Nikifforoff96
 
21.11.19
14:19
(14) это ж всё государственное, как в поликлинике обстановка

(17) Да, по одному кладбищу. Только проблема в том, что у них оно огромное кладбище (примерно 80% всех записей) и штук 10 маленьких кладбищ. Понятное дело, они ищут чаще всего по огромному, поставив отбор. Только это не спасает ситуацию.

(18) Уверен насчет отчета? Мне кажется, что дин. список намного быстрее получает свои 10-50 записей и подгружает их во время прокрутки, чем отчет будет получать все записи. Доп. упорядочивание убрал.

(21) Все эти поля - строки длиной до 50 символов. Есть два неограниченных, но они не индексируются и по ним не ведётся поиск. По всем полям с датами поиск ведётся. Дата смерти, дата рождения, возраст. Если что-то убрать. то придётся рассчитывать недостающее значение в запросе, чтобы поставить на него условие, ведь так? А с таким количеством записей запрос с арифметической операцией будет работать ещё дольше.
Какой смысл поля "Год" - не помню. Заказчик вообще обратился за тем, чтобы я перевёл им самописную базу с обычных форм на управляемые. Архитектуру я не менял.

(24) 50 символов стоит на каждое поле

(25) локально

(30) да, обычный hdd

В общем, я убрал им отборы платформенные, чтобы при изменении полей не производился поиск раньше времени (пока все поля для поиска не будут заполнены).
Настройка индекса ППД, слияние и т д помогла.
Поиск, конечно, всё равно медленный очень, секунд по 5.
32 МихаилМ
 
21.11.19
14:25
(0) почитайте про про индексы бд. под вашу задачу больше подойдут РС.
33 acht
 
21.11.19
14:45
Адресное хранение, пересортица и восстановление последовательности, простигосподи.
34 Glup0sti
 
21.11.19
14:51
Адресный склад на кладбище
Надо менять структуру БД: добавить справочник физлица(ФИО,....), справочник местоположений(ряд, ячейка, помещение) видимо подчиненный справочнику кладбищ.
Заменить в книге реквизиты на ссылки этих справочников, проиндексировать необходимые поля справочников(надо делать собрав статистику по запросам по каким полям чаще отбирают, тж в помощь). Делать ли вместо справочников РС(что усложнит разработку) это вопрос, база файловая, индексы свои не добавить. Делай тестовую базу, забивай еще рандомными данными и экспериментируй со структурой метаданных
35 МихаилМ
 
21.11.19
14:53
+(33) сроки годности, правила хранения (шиитов с суннитами нельзя)
плюс оптимизация зон приёмки , до кучи оптимизация двумерного раскроя участков а в перспективе 3-х мерного размещения урн.
36 cons24
 
21.11.19
17:56
(31) "В общем, я убрал им отборы платформенные, чтобы при изменении полей не производился поиск раньше времени (пока все поля для поиска не будут заполнены). "

Говорил же умный человек: делай отчет. Раз сразу по 10050 полей в условие надо им вводить - так отчет тут и подходит.
Ну или установка отборов через обработчик ожидания - когда пользователь точно закончил ввод параметров (так вроде для вебклиентов делали).