Количество измерений в регистре #405269

Стало вот интересно, это нормально вообще создавать регистры с количеством измерений больше десятка например? Скорость работы от этого не сильно страдает? А то смотрю например в типовой УТ в регистре ЗаказыПокупателей аж 12 измерений... О-0

Сам то как думаешь?

сам думаю, что не хорошо это. Но не настолько хорошо знаю внутренние механизмы, чтобы утверждать что-то уверенно..

скорости это не добавляет - факт, но иногда по-другому ни как

всегда есть варианты. Было бы желание.

то, что не добавляет - вопроса нет. Вопрос - на сколько убавляет. А вот насчет по-другому никак - можно бы поспорить. Сдается мне, что такие регистры-монстры появляются скорее от неграмотного проектирования системы...

от тож...

Никакого отношения количество измерений не имеет к скорости, имеет отношение лишь количество комбинаций. Если большинство измерений не заполняются или заполняются парой тройкой значений, то большого влияния на производительность не будет.

вопрос ни о чем...

(4,5) но зачем-то же их можно больше трех создать :) сам не пробовал

Главное индексировать измерения по которым будут в основном остатки получаться.

Хм, автор только час назах хвастался что всегда задает четккие и понятные вопросы :)

это мнение из опыта с использованием тестов, из каких-либо статей о внутренней архитектуре 1С или из чего такой вывод? Звучит весьма правдоподобно, но хотелось бы обоснования услышать. Кроме того, это означает, что если таки все (или большая часть) измерений задействуется для работы, то на скорости это очень даже должно сказываться. А в таком случае может быть стоило бы продумать другую струтуру регистров? Ибо зачем строить то, что не расчитано на полноценное использование всех возможностей?

а что неясного и нечеткого в моем вопросе?

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

Это мнение из простейшей логики. Что делает механизм? 1. При проведении ищет строку итогов по комбинации измерений, пишет туда новое значение. Станет ли он дольше искать, если добавленные измерения не имеют большого количества возможных значений? 2. При запросе ищет в таблице остатков строки остатков по комбинации иизмерений, то же что и 1, зависит от того сколько дополнительных строк в таблице остатков способно создать измерение. "А в таком случае может быть стоило бы продумать другую струтуру регистров?" Имеет смысл говорить о конкретном регистре.

Шучу.

полагаю, ты не указал, в каких попугайских крыльях измеряется твое "сильно страдает". Да и критериев нормальности при проектировании структутры регистра ты тоже не определил. Исходя из этого, ответить на вопрос адекватно довольно трудно. Я  просто предположил

тогда зачем столько?

я указал парметр, который меня интересует. Скорость работы...

видишь ли, пустое значение измерения - это тоже значение. Соответственно, ищет и пишет он с учетом и тех измерений, которые пользователь может вообще не использовать. Во всяком случае мне так кажется...

+20 я уже не раз сталкивался с тем, что простейшая логика (наша логика) не всегда соответствует реальным механизмам платформы. Поэтому хотелось бы более существенных подтверждений этому...

Чтобы ты мог получать полную аналитику. Давай возьмем регистр упомянутый в . Там реально засоряет регистр только измерения Номенклатура и ЗаказПокупателя, все остальные: Характеристика, Ед.изм, Проценты всяких скидок, они для комбинации Номенклатура, ЗаказПокупателя будут единственные, соответственно увыеличения числа записей не будет, но зато по ним ты сможешь делать любые отборы, почему нет?

Если некоторым вопрос кажется неконкретным, давайте его сформулируем так. Есть регистр, предположим с 5 измерениями. Предположим, что реально используются все. И хочется туда добавить еще одно, которое тоже будет использоваться. Можно ли заранее предсказать, насколько это может повлиять на скорость работы с регистром...

Пишет и пишет, это просто лишнее поле в регистре остатков, на производительность влияет не более, чем лишнее поле в таблице документа. Почитай внимательно и медитативно 22.

Ответ в 22, проанализирую насколько это увеличит общее количество записей таблицы остатков. В примере с Заказ покупателя реально только два измерения его увеличивают, ну может ещё хаарактеристика, если в одном заказе может быть одна тноменклатура с кучей разных характеристик. Все остальные не увеличивают число записей, а анналитику получать позволяют.

прочитал. И насколько я знаю, системе по барабану - что это конкретно за измерение. Будет ли это номенклатура с заказом или что-то второстепенное. На скорость может повлиять только индексированность измерения, а не его смысл...

т.е. ты считаешь, что на скорост работы регистра влияет только размер (количество записей), а количество аналитических разрезов не важно? О-0

мне кажется в этом вопросе нужно смотреть в сторону скуля, сколько полей он сможет проиндексировать? а так же на возможные блокировки

+ да и вообще мне кажется нужно отдельно рассматривать вопросы чтения и записи.

согласен, это должно существенно влиять...

Кол-во записей в регистре остатков. О каких блокировках речь? Какие поля он индексирует?

Значит ты вообще не понял что написано в 22

ну так в таблице итогов индексируется все вот нарыл Индексы таблиц базы  данных Регистр накопления Основная таблица регистра Индекс    Условие Период + Регистратор + НомерСтроки (Кластерный)    Всегда. Регистратор + НомерСтроки    Всегда. Измерение + Период + Регистратор + НомерСтроки    Измерению "Измерение" задано свойство "Индексировать". Реквизит + Период + Регистратор + НомерСтроки    Реквизиту "Реквизит" задано свойство "Индексировать". Таблица остатков Индекс    Условие Период + Измерение1 + ... + ИзмерениеN (Кластерный)    Для регистров вида "Остатки". Таблица оборотов Индекс    Условие Период + Измерение1 + ... + ИзмерениеN (Кластерный)    Для регистров вида "Обороты".

моя твоя не ферштейн. Еще раз вопрос в . тоже верно. Блокировки еще никто не отменял...

+ т.е. если измерения регистра только ссылочного типа, то имеем 13 полей для индексирования.

+ если в измерениях встречаются простые типы, то еще больше

Вообще-то если добавить измерение, то запись замедлится - потому что по этому измерению нужно еще и индекс построить... то сделать дополнительную операцию записи на диск... Но если это клиент-серверный вариант, то построением индексов занимается СКЛ-сервер.. как и когда он строит индексы - нужно его читать...

А, не знал, все равно мне кажется на скорость не сильно влияет. Ответил в 31.

на скорость чтения да, возможно и не влияет...

А какой процент времени занимает построение индекса от общего времени записи данных?

На скорость чтения вообще не влияет

(38.2) не понял ответа. То, что количество записей влияет на скорость - вопросов нет. Вопрос был в том, считаешь ли ты, что количество аналитических разрезов на нее не влияет...

А что, таблица остатков не индексируется отдельно по измерениям с флагом индексировать? Это было бы очень и очень странно.

На скорость влияет размер таблицы остатков, никакого пряямого отношения к количеству записей он не имеет.

не знаю... Могу сделать регистр с 50 измерениями и записать в него 100 по 1000 записей... Потом добавить еще 50 измерений и повторить запись.. в Обоих случаях замерить время... Правда на файловой версии... сделать?

Записей может быть миллион, а размер таблицы остатков может составлять 2 записи, а может и миллион. Я утверждаю, что на размер таблицы остатков регистра ЗаказыПокупателей влияет только количество комбинаций Заказ покупателя -> Номенклатура, все остальные измерения не создают дополнительных записей.

было б интересно.

+46 И посему увеличивают время работы только на увеличение времени составления индекса при записи в регистр остатков.

вот что нашел "Принципиальным отличием кластерного индекса от индексов других типов является то, что при его определении в таблице физическое расположение данных перестраивается в соответствии со структурой индекса." т.е. имеем большой индекс, имеем тормоза на запись "Ограничения индексов Индекс может быть создан на основании нескольких полей. В этом случае существует ограничение – длина ключа индекса не должна превышать 900 байтов и не более 16 ключевых столбцов. На практике это означает что при создании индекса, включающего более 16 полей, индекс усекается." + если переползаем за ограничение, то получим тормоза на чтение PS. цитаты отсюда

а размеры таблиц и скорость для MS SQL скорее всего очень слабо связаны, обход проблем с размером эт же одна из его функций.

"Принципиальным отличием кластерного индекса от индексов других типов является то, что при его определении в таблице физическое расположение данных перестраивается в соответствии со структурой индекса." т.е. имеем большой индекс, имеем тормоза на запись ==== Не понял вывода, не каждый же раз кластер переопределяется. Толькко при изменении числа измерений.

там далее есть "Необходимо избегать создания кластерного индекса для часто изменяемых столбцов, поскольку сервер должен будет выполнять физическое перемещение всех данных в таблице, чтобы они находились в упорядоченном состоянии, как того требует кластерный индекс. Для интенсивно изменяемых столбцов лучше подходит некластерный индекс."

ну, все-таки связаны конечно. Обход этих проблем связан как раз с использованием индексов. И взаимосвязь объема с временем получения информации при этом выражается логарифмическим законом....

+ если переползаем за ограничение, то получим тормоза на чтение = Только если конец индекса может быть симльно различным, если поставить измерения в нужной последовательности подобного не будет. Только что посмотрел измерения Заказа покупателя, именно два упомянутые мною индексированы.

Что такое "часто изменяемые столбцы"?

а у меня ЗаказПокупателя не индексирован. Только номенклатура...

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

для таблицы остатков кластерный индекс строится по всем измерениям независимо от признака "индексировать"? Это получается тогда, что только порядок следования измерений влияет на скорость работы с таблицей остатков?

да.

очень интересно...

хотя MS SQL "вещь в себе" что там на что влияет, 100% утверждать не получиться ;)

насколько я помню еще в 7ке рекомендовали часто используемые измерения располагать первыми.

да, я тоже припоминаю...

вообще можно посмотреть для примера УПП, где проектирую новую подсистему затрат 1С-ики (учитывая проблемы производительности) создали регистры УчетЗатрат и УчетЗатратРегл, всего с 4мя измерениями, вместо 8-9 в старой подсистеме.

"поля, т.е. в нашем случаи измерения, т.е. при каждой новой записи (появление нового значения измерения) в такую таблицу, идет перестроение таблицы остатков." Таким образом опять же возвращаемся к тому с чего начали - количество измерений неважно, важно насколько часто появляются новые комбинации.

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

мое мнение, что для записи скорее всего да, для чтения и блокировок безразлично.

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

+ хотя возможно, чем меньше индекс, тем меньше будет перестроения таблицы... у кого бы спросить?

так вроде блокировки на запись как раз более сильные, чем на чтение...

а я про блокировки на запись и говорил. в 1С читается в основном, вообще не смотря на блокировки.

Так, давайте ка все-таки уточним для особо продвинутых типа меня. Есть два измерения. Одно из них принимает мало различных значений, другое - много. В каком порядке их следует поставить в конфигураторе, чтобы сократить перестроения в таблице остатков?

О каких релизах речь? Испокон веку там 4 измерения. Не глупи, совершенно разные регистры с разным назначением. В Учет затрат вообще крайне специфиический набор измерений.

Да Они реально используются, почитай ещё раз внимательно 22. Их использоввание не увеличивает количество записей. По барабану. На перестроения не повилияет.

(73.2) про учет затрат я ничего не знаю, поскольку с УПП не работал. Я сейчас говорю об идеологии. Согласись, что даже резервирование товара можно сделать при помощи дополнительного измерения в регистре остатков. Ан нет, выделяют в отдельный регистр. Это к вопросу о разных возможностях проектирования одной и той же задачи...

+74 "Их использоввание не увеличивает количество записей" = Их использоввание не увеличивает количество записей в таблице остатков

Скажи какое из измерений регистра Заказы покупателей лишнее и почему? Я обосновал в 22 что ни одно из неиндексированных измерений этого регистра на производительность не повлияет.

да почему же не увеличивает количество записей? Не увеличивает, если есть измерения, которые не используются. Для используемых измерений возникают новые комбинации, которые может быть грамотнее было бы вводить через дополнительный регистр, а не измерение в этом?

это для РАУ, страрая подсистема использует регистры: Затраты, Незавершенное производство, Брак в производстве, Затраты на выпуск продукции ... для каждого учета в отдельности ... :)) а еще забыл про наработку, тоже отдельные регистры и еще Партии товаров... вместо всего этого созданы только 2 регистра УчетЗатрат и УчетЗатратРегл

+ просто 1С-ики использовали старый прием, для уменьшения количества измерений применил "кортежи"

что есть "кортежи"?

ну пример у тебя есть 4 измерения: организация, контрагент,договор, заказ .. Создаешь справочник, с такими же полями, и вместо 4 измерений делаешь регистр с 1 измерением этого справочника.

ага, ясно.

только эти засранцы, сделали хитрее, они использовали не поля справочника, а механизм аналогичный механизму свойств, что бы уменьшить количество блокировок, + возможность легко расширить разрезы учета.

(74.3) не повлияет или просто невозможно предсказать - как повлияет в каждом конкретном случае?

разумно. Хотя программно работать с этим сложнее...

Я правильно понимаю, что перестроение данных в соответствии с кластерным индексом идет в момент записи данных в регистр. Вот кстати, если взять регистр ОстаткиТоваровНаСкладах. Там сначала идет склад (складов заведомо у всех не много), потом уже Номенклатура, характеристика и т.д. Интересно было бы посмотреть на скорость, если номенклатуру перестроить выше склада...

отлучусь ненадолго...

лови France он вроде у нас спец по этим вопросам, хотя в последнее время его не видно :(

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

Смотри, Измерение единица измерения используется? Да. Но увеличит ли оно количество записей, если все равно в одном документе Заказ покупателя редчайший случай чтобы одна номенклатура продавалась по двум разным единицам измерения. Цена то же самое, скидкка то же самое. Договор контрагента увеличит? Нет. На каждый заказ один договор.

спасибо! согласен. Я действительно не рассматривал внимательно конкретные измерения этого регистра, хотя именно его приводил в качестве примера в . А сам подразумеваю при этом использование независимых друг от друга измерений. Т.е. ты все это время говорил, что при при наличие таких вот зависимых измерений, их количество не имеет значения. Так? В этом случае скорость чтения данных из таблицы остатков зависит только от порядка следования измерений. Но если рассматривать независимые между собой измерения, то наверное все-таки имеет значение их количество, поскольку количество комбинаций их значений увеличивается. Так?

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

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

Прошу прощения за перерыв, эксперименты отняли больше времени, чем я планировал... И сам план по ходу пришлось изменить... Пока статистика такая:

то есть индексированность может влиять довольно существенно... Я бы так сказал...

для каждой версии скуля существует рекомендация по количеству измерений.

а где про это подробнее можно почитать...