Как уменьшить размер индексной таблицы РС
 

Прошу помощи у 1с сообщества. Суть вопроса база много переписанная УТ 10,3. В файловом варианте при выгрузке натолкнулись на ошибку:

Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла 'G:\base/1Cv8.1CD'
по причине:
Превышен максимально допустимый размер внутреннего файла 'G:\base/1Cv8.1CD'

Начали копать. Средствами Tool_1CD.exe выяснили что 99% занимает индексная таблицы нашего РС (переодичный не подчиненный регистратору) причем сами данные этого регистра занимают 70мб, а Индексный файл >4 гб. Не могу понять из-за чего это получилось и как оптимизировать... Тестирование исправление (переиндексация, сжатие, реструктуризация) не уменьшает таблицу эту...

Сам РС таков (периодичность- в пределах секунды, режим записи независимый)

Измерения:
Изм1 - тип перечисление, ведущее-ложь, основной отбор-истина, не индексировать;
Изм2 - тип Строка 100, ведущее-ложь, основной отбор-истина, не индексировать;
Изм3 - тип Строка 200, ведущее-ложь, основной отбор-истина, не индексировать;
Изм4 - тип Строка 100, ведущее-ложь, основной отбор-истина, не индексировать;

Ресурсы:
Рес1 - тип Строка 100, не индексировать;
Рес2 - тип Строка 100, не индексировать;
Рес3 - тип Булево, не индексировать;
Рес4 - тип Строка 100, не индексировать;
Рес5 - тип Дата+Время, не индексировать;

Реквизиты
Коментарий - Строка неограниченной длины.

Думали все из-за Коментария, но сколько не читаю о том как индексируются таблицы нигде подтверждения этому не нашел. Подскажите, что можно еще сделать чтобы таблица индексов была меньше кроме удаления записей этого регистра? Если еще нужно что-то прояснить пишите. Заранее спасибо за помощь...

(0) Как мне кажется, нужно просто правильно определить индексы по измерениям. У тебя сейчас РС не индексирует измерения, соответственно индексная таблица и пухнет.

в данном случае в таблице индексов должны присутствовать индексы по измерениям и периоду, как я понимаю

(2) Естественно, для 2,3,4 измерения. Для первого я смысла не вижу.

ну да пишут что таблица индексируется в нашем случае как период + Изм1+изм2+изм3+изм4.... Если на каком то измерении поставить индексировать то просто оно на 1 место сдвинется по идее. Но откуда блин 4гб О_о если таблица данных 70мб... Странно как то это все...

строки в 100, 200 символов индексировать?
я понимаю ещё в 10-20

(4) Ничего тут странного нет.

Немного не понимаю как вы предлагаете установить признаки индексации? На одном из измерении (самом точно характеризующем запись...Допустим это будет Изм2)? Тогда индекс разве будет Изм2+Период? или Изм2+Период+Изм1+Изм3+Изм4? я просто сколько читал понял что таким образом произойдет...

ниче себе конфа! строки в справочник вынести не ?

8-Jimbo >На это были свои причины и содержимое этого регистра с данным набором полей и измерений нужно (возможно есть вариант убрать поле неограниченной длинны в комментарии, если дело именно в нем, в чем я сильно сомневаюсь и никаких подтверждений не найдено этому).

2(8) +1

Уникальность записей

Система обеспечивает контроль уникальности записей, хранящихся в регистре сведений. Таким образом, в регистре сведений не может находиться двух одинаковых записей. Одинаковыми считаются записи, у которых совпадает ключ записи. Ключ записи формируется системой автоматически, на основании значений, содержащихся в полях записи, и зависит от вида регистра сведений.

В общем случае в формировании ключа записи будут участвовать значения регистратора, периода [b]и значения измерений[/b]. Таким образом, например, в непериодическом регистре сведений ЦеныКомпании с независимым режимом записи не может существовать двух записей о розничной цене конфет ассорти. Точно так же, как в периодическом регистре сведений ЦеныКомпании, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом ИзменениеЦенКомпании.

[url]http://v8.1c.ru/overview/InformationReg.htm[/url][u][/u]

[quote=Зелёный тролль;30731456]Точно так же, как в периодическом регистре сведений ЦеныКомпании, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом ИзменениеЦенКомпании.[/quote]
Вранье! Можно! Если сделать период до секунды и заносить цены разным моментом времени!!! Кстати, ингода это нужно...

12-bma1 > регистратор один и тот же? и как это? и зачем?

2(13) регистратор тот же, а периоды разные (а если периодичность до секунды - то и в пределах одних суток). В принципе мне надо было переделать документ установки цен так, чтоб иногда в нем было две даты - на одну дату цена устанавливалась новая, а на вторую - возвращалась прежняя.

Погодите. или я че-то не понимаю или не о том речь уже. При чем тут Уникальность? Вопрос у меня почему таблица данных регистра занимает 70 мб а его индексов 4гб? И что может так адски влиять на размер таблицы индексов в моем случае?

14-bma1 > извращенец )))

попробуй на копии одному из измерений установить длину в 1000 символов например. увидишь.

[quote=Зелёный тролль;30731984]извращенец[/quote]
Это пока еще не запрещено законом!!!

[quote=Зелёный тролль;30732732]попробуй на копии одному из измерений установить длину в 1000 символов например. увидишь[/quote]
А не 255? Или в файловой нет лимита на длину строки?

19-bma1 > фиксированная - максимальная длина до 100, далее переменная - до 536. файловую смотрю 8.2.18.61

автор. ТИИ полное делал?

хотя что я глупые вопросы задаю...

20-Зелёный тролль > + нагнал я на длину строковых измерений. то есть немножко по другому сохранить не даёт.
тут при построении индекса влияет суммарная длина всех измерений + периодичность и видимо регистратор.

предельная суммарная длина для только строковых измерений в районе 640 символов.

неверная архитектура - 4 измерения никогда шибко быстро то и так не работали, а тут строки еще. Переводите на SQL - проживет чуть-чуть еще ваша конфа

Несколько тестов на копии. Уменьшил размер строки одного из измерений с 100 до 80. Выигрыша в размере после Сжатия таблиц не было. Я так думаю из-за того что Строки переменной длины и просто не было значений больше 80. А вот когда уменьшил все измерения 50 тогда база после ТИИ сжалась до 1.5Гб... Не могу все равно понять почему так АДСКИ влияет на размер длина измерений...

24-Jimbo > в СКЮЭЛЕ все вообще отлично. проблем с этим регистром нет абсолютно. А вот именно на файловой такая ерунда имеет место быть. И к сожалению sql в данном варианте не выход. Надо думать что-то с оптимизацией этих данных...

SQL видимо не Express? а то и там были бы проблемы.
в SQL проблем нет в каком плане: не ругается или размер таблиц меньше?

(3,6) Ух какой вымахал!9-MiniMuk23 > ;)

7-MiniMuk23 > Не было ни одной причины. Все твои измерения должны быть справочниками. Если строка может повторять свое содержимое - значит индекс имеет смысл, и имеет смысл сделать справочник со значением. Если строка не повторяется - индексирование ее не имеет значения и помещать ее в измерения нет смысла.

Правильно так:[quote=Reaper;30738812](3,6) Ух какой вымахал! ;)
7-MiniMuk23 > Не было ни одной причины. Все твои измерения должны быть справочниками. Если строка может повторять свое содержимое - значит индекс имеет смысл, и имеет смысл сделать справочник со значением. Если строка не повторяется - индексирование ее не имеет значения и помещать ее в измерения нет смысла.[/quote]

27-Зелёный тролль > смотрели утилитами сколько занимает эта таблица в sql - очень мало. А вот в Файловом неадекватно много. То что в sql ошибки нет это ясное дело :)

29-Reaper >Справочник вести не хотим, тк суть этого регистра информативная и должна сохраняться после сверток очисток и прочих подобных операций. База глюкнула ссылки поломались а строки нет. В общем суть вашего предложения понял и учел на будущее. :) Понимаем, что наш способ не оптимален и все такое, но осознано пошли на такой вариант и не предвидели подобных проблем.

В общем спасибо всем за ответы и помощь. Вчерашние тесты на копии привели меня к интересным фактам которые могут помочь в дальнейшем кому-нибудь...

Значит так неоднократные попытки изменить размер длины строки у измерений регистра показал следующие вещи.
Если мы Делаем строчные измерения Изм1=100,Изм2=200,Изм3=100 Размер базы 5,5Гб
Изм1=100,Изм2=200,Изм3=40 Размер базы 5,5Гб
Изм1=60, Изм2=200,Изм3=100 Размер базы 5,5Гб
Изм1=60 ,Изм2=200,Изм3=80 Размер базы 5,5Гб
Изм1=60, Изм2=200,Изм3=70 Размер базы 5,5Гб
Изм1=60, Изм2=200,Изм3=60 Размер базы 1,8Гб
Изм1=60, Изм2=200,Изм3=70 Размер базы 1,8Гб
Изм1=100,Изм2=160,Изм3=60 Размер базы 1,8Гб

В общем суть если уменьшить в любом сочетании размер строк на 80- происходит снижение размера индексной таблицы до адекватного. При этом мы проверяли что фактически данные никакие на пострадают т.к размеры были выбранны с запасом. Поэтому размер индексной таблицы меняется нелинейно, а резким скачком при достижение некого порогового значения... В общем такая ерунда. Т.к данной информации я не находил думаю может эти наблюдения помогут кому-нибудь.

[quote=MiniMuk23;30745560]Справочник вести не хотим, тк суть этого регистра информативная и должна сохраняться после сверток очисток и прочих подобных операций. [/quote]
Тогда строки должны храниться не в измерениях а в реквизитах регистра. Они не индексируются.

31-bma1 >К сожелению если перенести в ресурсы информацию о измерениях мы не добьемся уникальности записей :( и не обеспечим то что надо.

2(32) Уникальность может быть достигнута массой иных способов. Менее затратных и более гибких.

Зелёный тролль Вам отдельное спасибо, т.к. именно ваши советы помогли понять суть проблемы и разобраться с ней.