Имя: Пароль:
1C
1С v8
тормозит список 2млн записей
Ø (Волшебник 03.06.2015 16:29)
,
0 ambez
 
31.05.15
22:35
обычные формы. в базе есть справочник примерно на 2 млн записей без иерархии. нужно делать в нем фильтрацию, поиск и т.п. все поля текстовые. с базой работает человек 10. что можно сделать для ускорения работы?
поможет ли апгрейд железа.
сейчас оно крутится на компе с 2 ядрамии и 4 гр оперы.
база в сиквеле.
может в регистр сведений переделать или на УФ переписать базку?
19 H A D G E H O G s
 
31.05.15
23:48
(11) Точно фиксированный - именно тип значений - Строка, фиксированная, 120 символов?
20 ambez
 
31.05.15
23:49
(19) да. фио строка 200, адрес 200, все остальное по мелочам 5-20
21 ambez
 
31.05.15
23:51
просто им надо какой-то универсальный механизм фильтрации сделать. стандартный механизм полностью подходит. за исключением того что тормозит
22 Drac0
 
31.05.15
23:52
(16) Ну, пару минут - это не смертельно. Кстати, поля поиска и фильтрации индексированы? А вообще, как изврат, можно предложить регистр сведений с этими строковыми полями как измерения и ссылка на справочник в ресурсе. При этом поля упорядочивания включить в кластерный индекс.
23 ambez
 
31.05.15
23:52
(18) да я тоже понимаю, что вроде как дин список не прокатит
24 ambez
 
31.05.15
23:53
(22) да, на все поля индексы стоят
25 ambez
 
31.05.15
23:54
(22) ну тогда точно мозгов надо побольше. там индексы одни нормально потянут
26 ambez
 
31.05.15
23:57
и еще там планируется рост этой байды до 10 млн.
и еще будет еще один такой же список и надо будет делать из них список 3, в котором будут записи из первого, но без записей из второго со связкой по телефону...
ну тут точно отчет придется делать или прямыми запросами джойнить это все
27 Lemkus
 
01.06.15
00:07
(23) Не могу представить себе, какому человеку нужно одновременно видеть 2 млн записей в списке или отчете, скорее всего нужно ставить доп. фильтры.
28 ambez
 
01.06.15
00:11
вобщем советуете в сторону отчета думать.
29 H A D G E H O G s
 
01.06.15
00:32
(20) Я про свойство ДопустимаяДлина - Фиксированная.
30 ambez
 
01.06.15
00:48
перменная стояла
31 ambez
 
01.06.15
00:52
млин, и еще 1 поле неограниченная строка есть
32 beaver1971
 
01.06.15
06:38
(0) (12) иногда на таких базах (я не только про 1С) бывает оптимально не только улицы в отдельный справочник, но и имена и отчества вынести. Вопрос только с добавлением к базе.
33 Drac0
 
01.06.15
08:08
(31) ты ж сказал, что все проиндексированы? Как ты безконечную строку в индекс запихнул? :-)
34 dubraver
 
01.06.15
08:18
У меня есть пара справочников с количеством несколько миллионов записей. В итоге сделал так:
На sql сервере создал отдельную базу под доп. справочники.
Создал там таблицы, загрузил данные из csv bulk'ом. А в 1С уже настроил внешний источник данных. Вполне быстро фильтрует по такому справочнику. Оно и понятно ведь это нативный доступ к бд sql. Но минус надо писать инфраструктуру по вставке/обновлению данных.
35 ambez
 
01.06.15
09:18
(33) да это без меня добавили. я даже внимания не обратил сразу
36 ambez
 
01.06.15
09:20
(34) я тоже так иногда делаю, но не думал, что тут тоже придется огород городить
37 vde69
 
01.06.15
09:21
для начала надо проверить индексы, добавить нужные и убрать лишние
38 Rlogin
 
01.06.15
09:22
Фильтр можно задавать не после открытия справочника, а до.
Т.е. хочешь посмотреть записи - сначала задай условие. Иначе не посмотришь. Так например в SAP реализовано.
39 vde69
 
01.06.15
09:24
а вообще 2 ляма - это не много...
40 ambez
 
01.06.15
09:25
а с сохранением списка справочника с наложенным отбором в табличный документ можно что-то сделать для ускорения?
(39) вроде как да
41 eklmn
 
гуру
01.06.15
09:51
(40) у тебя условия фильтра должны быть такие, чтоб кол-во записей не привышало 1000 хотя бы
42 Sasha_H
 
01.06.15
09:56
(0) для таких объемов если это возможно надо пользоваться регистрами сведений
43 Sasha_H
 
01.06.15
09:59
Если тормозит на сервере покруче, не делайте поспешных выводов. Во-первых попробуйте все это перенести на регистр сведений, проинтексировать поля которые Вам важны, в скл обновить стастистику и сделать это все на регламенте и отписаться.
44 vde69
 
01.06.15
10:12
(42) чем регистр отличается от справочника без иерархии?

физически и то и другое одна таблица, и  индекс то же одинаковый...
45 rsv
 
01.06.15
10:15
(0) Вьюху в скуле ... и делов. Вызывать можно из скуля штатным образом через XLS. Microsoft Query встроен в Excel.
46 DexterMorgan
 
01.06.15
10:20
(44) Вообще вроде как ничем, но например в УТ11 есть справочник КлючиАналитикиНоменклатуры и РС АналитикаНоменклатуры, так во всех типовых запросах делают соединение именно с РС
47 Sasha_H
 
01.06.15
10:30
(44) справочники намного медленные и менее поворотки чем РС вот и тем и отличаются! РС совершенно другую структуру имеет на уровне СУБД.
48 Timon1405
 
01.06.15
10:35
(47) Пруф, ор диднт хэппен
49 Timon1405
 
01.06.15
10:47
(47) про индексы http://its.1c.ru/db/metod8dev#content:1590
Так че, у вас доказательства будут или слив защщитан?
50 Drac0
 
01.06.15
10:52
(44) ну, для РС можно удобный кластерный индекс построить разве что.
51 vde69
 
01.06.15
10:53
(50) для справочника то же можно сделать кластерный индекс
52 Sasha_H
 
01.06.15
10:55
(49) Собственно говоря ответ лежит в кластерном индексе, так что зачислите себе слив! Поскольку в справочнике кластерного индекса не построить! Ой...
53 degot
 
01.06.15
10:55
(0) попробуй 8.3.6 + Полнотекстовый поиск+ дин. список
54 Sasha_H
 
01.06.15
10:56
(51) нет нельзя..... Кластерный индекс там только по-умолчанию
55 vogenut
 
01.06.15
10:57
(0) Попробуй на все реквизиты, по которым фильтрация и сортировка установить индексирование с доп. упорядочиванием
56 vde69
 
01.06.15
10:58
(54) можно... например разделитель учета попадет в него

по сабжу поля текстовые, по этому кластерный индекс вообще не катит.... ни для регистра ни для справочника...

прикинь как будет работать регистр с текстовыми измерениями :)
57 Sasha_H
 
01.06.15
10:59
(56) нормально он будет работать. А как по вашему работают другие СУБД /:)
58 Drac0
 
01.06.15
11:00
(56) это же РС, а не РН. Для такой залачи приемлемое решение, если результат даст хороший :-) Правда, не факт, что кластерный индекс вообще сможет построиться по строковым измерениям.
59 Sasha_H
 
01.06.15
11:01
Далеко ходить ненадо, смотрим примеры из книги SQL-запросы для простых смертных или другие книги, вы увидите, что все примеры на строках.

Если пойти чуть дальше и взять базу ТЕКДОК то там масса текстов и ищется быстро.
60 vde69
 
01.06.15
11:02
(57) ту теоретик? я практик у меня был такой регистр и примерно на 2 ляма записей, тормозил...

причина простая: размер кластерного индекса... у него банально не влезет в него все... и будет построен доп индекс...
61 rsv
 
01.06.15
11:02
(47) На уровне СУБД все равны в виде отношений и атрибутов .  Различиие в индексах если только. Индексированная вьюха рулит.
62 Гёдза
 
01.06.15
11:03
Добавить полнотекстовый поиск и юзать его, а не отборы
63 rsv
 
01.06.15
11:04
+(61) И то ... как оптимизатор решит. Не случайно вендор вводит понятие подсказок оптимизатору... Ну как то так ..
64 Гёдза
 
01.06.15
11:04
(60) а сколько у тебя ресурсов было в регистре?
65 Sasha_H
 
01.06.15
11:05
(60) практик. Кластерный индекс будет использован только в том случае, когда я запросом в условии ГДЕ наложу последовательно поля

ГДЕ Измерение1=..., Измерение2=... и т.д

Вот только тогда применится в поиске кластерный индекс. В другий случаях надо индексировать поля отдельно!

Все зависит от задачи как он будет искать информацию и как накладывать условия.
66 Sasha_H
 
01.06.15
11:06
Почему люди забывают о таких вещах как обновить статистику на СУБД и дефрагментировать индексы.

Надо смотреть планы запросов, о чем тут споры вообще пальцем в небо тыкать.
67 vde69
 
01.06.15
11:07
68 rsv
 
01.06.15
11:07
(65) Это только оптимизатор знает при условии достаточной статистики...
69 Sasha_H
 
01.06.15
11:09
(68) + да забыл дописать и как решит оптимизатор. Это то что янаписал в (66)
70 Гёдза
 
01.06.15
11:11
(65) Не прав. Отдельные индексы не помогут, если в ГДЕ несколько условий
71 Sasha_H
 
01.06.15
11:12
Ответ лежит в (66)
72 Sasha_H
 
01.06.15
11:13
(70) кто такое сказал, чем докажете? Еще раз подчеркну, что все проверяется только на месте. Вот попробует человек сделать все , что ему хорошие люди здесь порекомендовали. Скажет, что у него статистика в порядке и индексы фрагментированы, выложит план запроса вот только тогда можно утверждать что-то и двигаться куда-то еще...
73 Sasha_H
 
01.06.15
11:20
(0) я не знаю как у Вас сделано, но по тексту понимаю, что вы ищете по номеру телефона.

можно в таком случае использовать номер телефона в Наименование или в код сделать уникальным справочник. Платформа сама создаст необходимые индексы. На другие поля обвесить индексы и обязательно смотреть план. Пробовать вариации разные.
74 Sasha_H
 
01.06.15
11:21
В отчетах не применять конструкцию СОРТИРОВАТЬ.
75 ЧеловекДуши
 
01.06.15
11:52
(11) (0)Код покажи, как ты фильтруешь?
1с на УФ или только Толстый клиент?
Как реализовал поиск в текстовых полях?
76 ЧеловекДуши
 
01.06.15
11:55
(40) Да, можно, можно чисто в запросе отобрать элементы, и в список выводить маленький список самих элементов, а не отбор по какой либо части текста :)

Так же можно править сам запрос, но для Динамического списка.
77 ambez
 
01.06.15
12:57
экспорт списка в текущем варианте похоже виснет намертво
78 ambez
 
01.06.15
13:12
(75) кода вообще нет, тупо стнадартный 1ский механизм фильтрации списка по условиям, который вызывается кнопкой на командной панели

толстый клиент

поиск через ctrl+f )
79 vogenut
 
01.06.15
13:14
(78) Реквизиты проиндексированы?
80 H A D G E H O G s
 
01.06.15
13:16
(78) Естественно будет тормозить, осотенно при поиске по подстроке. Это же скан.
81 H A D G E H O G s
 
01.06.15
13:16
(78) Тебе поможет только полнотекстовый поиск
82 H A D G E H O G s
 
01.06.15
13:17
Никакие индексы тебе не помогут при поиске по подстроке.
83 ambez
 
01.06.15
13:20
то есть сделать им окошко для полнотекстового поиска
84 H A D G E H O G s
 
01.06.15
13:21
(83) Да
85 ambez
 
01.06.15
13:27
(79) ага
86 vogenut
 
01.06.15
15:29
(85) А как проиндесированы - просто или с дополнительным упорядочиванием?
87 ambez
 
01.06.15
15:51
(86) просто
88 ambez
 
01.06.15
15:52
экспорт списка думал 2часа и 1с вылетела с ошибкой)
89 Jokero
 
01.06.15
15:57
у меня винда на 4гб оперативы тормозит, не то что 1с)))
90 vogenut
 
01.06.15
15:59
(87) Замени все на дополнительное упорядочивание
91 H A D G E H O G s
 
01.06.15
16:11
(90) Вы прикалываетесь?
92 vogenut
 
01.06.15
16:18
(91) Нет, совершенно серьезно
93 Гёдза
 
01.06.15
16:24
(92) Доп упорядочивание - это индекс: реквизит + наименование
94 vogenut
 
01.06.15
17:59
(93) Вот именно. А точнее, зависит еще и от версии платформы. В новых версиях туда еще и другие реквизиты могут записываться. Проблема списков в том, что нужно фильтровать по реквизиту, а выводить записи в порядке наименования, например. По обычному индексу по реквизиту можно только отфильтровать. По индексу с доп упорядочиванием можно отфильтровать и сразу получить записи в порядке наименования. Поэтому он для списков и нужен.
95 Гёдза
 
01.06.15
18:02
если записей не много после отбора, то операция сортировки не особо влияет
96 vogenut
 
01.06.15
18:03
(95) А если много? Что скорее всего в данном случае...
97 Гёдза
 
01.06.15
18:05
(96) я больше склоняюсь к (91)
98 vogenut
 
01.06.15
18:12
99 R41
 
01.06.15
18:26
(0)Посмотри в профайлере какие SQL-запросы тормозят. Сделай составной индекс средствами скуля (с теми колонками, которые участвуют в выражении WHERE).
100 R41
 
01.06.15
18:27
Простые индексы (т.е. индексы на одно поле) в случаях,  когда используется несколько колонок в фильтрах не используются, т.е. практически бессмысленно их устанавливать.
101 R41
 
01.06.15
18:29
К сожалению 1С стандартными средствами не дает создавать составные индексы - видимо считает 1С-ков тупыми для такого сложного понятия :)
102 Лефмихалыч
 
01.06.15
20:16
прочитал. о*уел от некоторых советов с допупорядочиванием.

(0) нужны нормализация и иерархия. Пока оно все в тексте, будет печаль.
103 Фрэнки
 
01.06.15
21:30
Имел счастье наблюдать крах приложения клиента всегда, когда делалась попытка отобразить форму списка от регистра сведений на несколько миллионов записей. Только не помню точно сколько там было миллионов. С учетом высказанного предположения, что количество записей еще вырастет в несколько раз, то думаю, что иных вариантов не будет, кроме замены поля списка на пере-заполняемую отчетную форму. И при этом, из отчетной формы можно легко и сразу же выполнить сохранение во внешнюю таблицу.

И еще непонятный момент - в эксель слишшком много строк не получалось сохранить.
104 romix
 
01.06.15
22:08
(11)
>>>там грубо говоря колонки - фио, адрес (удица, дом), телефон, год рождения
им надо фильтровать эту байду по улице и по возрасту. а также искать там телефон или фио (телефон уникальное поле)

Военкомат что ли там у вас? На АТО призыв идет???
105 romix
 
01.06.15
22:10
Вот зачем на Украине еще нужно фильтровать по улице и возрасту огромные базы.
106 Armando
 
01.06.15
22:47
>> и еще там планируется рост этой байды до 10 млн.
>> и еще будет еще один такой же список и надо будет делать из них список 3, в котором будут записи из первого, но без записей из второго со связкой по телефону...

Точно!
Всего вна Украине мужчин 46% от общего количества. Численность возрастной группы 18-60 примерно 27 млн. Мужчин в этом возрасте примерно 12,5 млн. Можно догадаться, что 10 млн это боеспособные мужчины Украины.
http://ukrstat.gov.ua/operativ/operativ2007/ds/nas_rik/nas_r/nas_rik_r.html
107 romix
 
01.06.15
23:30
(106) Связка по телефону - это, видимо, те, кто уже звонил из зоны проведения АТО за некоторый период.
108 l123456789
 
02.06.15
02:18
Можете пинать, но я бы вынес эту ботву во внешний источник.
2М записей для постреса - фигня в общем.
Загнать в редис и прогнать тупой фильтр на чем-нибудь пригодном - офигейте от разницы.
Кэшируйте в редисе ваши запросы через что нравится и ухватитесь за гениталии от восторга.
PS: redis = InMemoryВсеЧтоВамНравиццо
109 romix
 
02.06.15
03:30
(108) По числовым признакам и фильтрам (улица, возраст) это база укро-мобилизации.
110 фобка
 
02.06.15
12:41
(106) уникальный номер телефона, означает скорее всего что источник данных - базы мобильных операторов. Увеличение с 2 до 10 миллионов означает что планируется догрузить базу от еще одного или нескольких операторов
111 фобка
 
02.06.15
12:44
+110 и это не базы киевстара и мтс-украина

http://e-finance.com.ua/show/185733.html
Осторожно укро-сми
112 Armando
 
02.06.15
14:49
(111) Интересно, откуда они взяли 60,6 млн абонентов, если общая численность не более 45 млн. Почему такой большой разрыв? В России так же интересно?
113 Drac0
 
02.06.15
14:59
(112) У многих по 2-3 симки бывает.
114 фобка
 
02.06.15
14:59
(112) у кого-то несколько номеров + туристы могли купить для местных звонков
115 фобка
 
02.06.15
15:02
Это всё конечно версии, но romix , нужно признать, нестандартно мыслит - сложил 2 плюс 2
116 ambez
 
02.06.15
21:35
не военкомат, но идея интересная
117 romix
 
03.06.15
16:21
(116) Общенациональная (судя по размерам) база Украины с фильтром по улице и возрасту — что бы еще это могло быть...

То есть, некоторые люди имеют определенный возраст и живут на одной улице — это кто?

Разрешите мои сомнения, а то у меня фантазия уже иссякла — кроме военкомата АТО ничего не могу придумать.
118 Волшебник
 
модератор
03.06.15
16:29
(0) в бан