Доброго.
Регистр сведений независимый или подчинённый регистратору, что быстрее?
вроде независимый должен быть быстрее.
Но я что-то особо разницы не заметил.
Сделал два однотипных.
Ну в независимом ссылка на док.
И три измерения одинаковых.
Забил миллион записей.
при записи независимый процентов 20 быстрее.
12 минут против 14 минут.
При чтении как-бы разницы особо и нет.
А вот подчинённым регистратору работать проще, не надо в доках дополнительно следить за удалением данных при отмены проведения дока.
Кто глубже копал?

диски SSD/HDD больше влияют

(1) Это да. Но диски они как бы на все влияют. На БД HDD уже давно не ставим.
А первой раз такой прирост был. Аж прослезились.

(2) А что за регистр? Просто интересно, про что миллион записей.

Смысла в этом копании не вижу. Вам нужно доказательство что три колонки заполнить быстрее чем четыре, или что?

(4) + 100500
Опередил :)

(0) В любой непонятной ситуации смотри тут
https://its.1c.ru/db/metod8dev/content/1590/hdoc

(0) Для подчиненного РС кластерный индекс будет занят Регистратором.

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

(8) Будет.

(7) И что? Типа головка винчестера меньше при записи с ума сходит?

(10) Не понял вопроса. Как мое утверждение в (7) соотноситься с вашими ощущениями в (8) ?

(11) Как замена кластерного индекса на регистратора в первом поле приводит к ощутимому замедлению записи? Типа он в независимый регистр он писал в таком порядке, который лучше попадал в порядок кластерного индекса?

(9) Мне сложно представить ситуацию, когда мне нужен зависимый регистр, но из-за преимуществ более подходящего кластерного индекса я буду его эмулировать на независимом.

(12) Откуда я знаю? Может у вас там измерения Ведущие или Индексированные и 1С строит некластерные индексы для них, когда РС становится подчиненным?
Я про подчиненный сказал только то, что Кластерный индекс будет занят Регистратором.
Тоесть, ценный ресурс "получи быстро значение ресурса с отбором по измерению" будет приводить к keylookup.

(14) Из этого можно, кстати, выкрутиться, полностью отказавшись от ресурсов и перетаща все в Измерения.

Ясно. Ну а мне интересно, что конкретно у ТС привело к ощутимой разнице в скорости записи.

(14) Ценный ресурс "получить быстро значение ресурса с отбором по ПЕРВОМУ измерению".

// При чтении как-бы разницы особо и нет.

И не должно быть разницы, если это простое и одинаковое, как бы плоское чтение, без каких-то извращенных действий.

(14) А это интересно. Спасибо.

(0)http://catalog.mista.ru/1c/articles/527518/

независмый,неподчиненный самый быстрый

Ну ли с отбором по всем "первым"

(17) С отбором по Первому измерению, либо по ПервомуИВторому измерению, либо по ПервомВторомуТретьему, и.т.д.

ибо есть ОбъектРегистр.ОбменДанными.Загрузка = ИСТИНА;.когда тупо инсерт и всё.

Ну не знаю, я добавлял свои индексы с включенными полями для воих задач, чтоб избавиться от keylookup

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

(24) Это не по джентельменски

(24) С учетом отказа 1С от гибкого управления индексами из конфигуратора, вы должны были извернуться и родить конфетку.

Покрывающие индексы - это такое... Конкретные рецепты к конкретным проблемам.

Кстати, одно отраслевое решение хранит большие наборы марок на подчиненном регистре. Как их до сих пор не подвергли порицанию - я даже не представляю.

(27) ну на....:))
Лучше б на селезнёвке начали выпуск платформы под каждый формат хранения ИБ. Под скуль своя, под постриги своя, под файловую своя.
Где наконец, дали возможность в верси для скуля писать всё что угодно, хоть примитивный каст и конверт в тексте запроса, для начала.

(29) КТ-ники то ?

Там и марка...строка 150 :)) Там вообще жпо.

Можно и базу саму на себя помножать, можно и хардвер улучшать, можно и в память выносить - тут уже по обстоятельствам.

(32) Мы возможно, одному оптовику будем делать заплатку на это дело, так как из-за этих 150 символов в таблицах и индексах базка стала люто расти.

(34) ага, я такое же видел.. 140 млн записей в этом РС занимает 140 гигов, из которых данные занимают 30 гигов, всё остальное, индексы :))

ну а че, норм же ? :)

И на втором месте по размеру - ТЧ дока, в котором опять же эта строка в 150 :)

(29) КТ-2000? Есть у них такое.
А вот тут народ говорит да по барабану типа. Какого типа регистр.
Хотя да, колом оно быстро становится.
Отчего я и озадачился. Мне тоже много писать надо будет.
Не марки конечно, ссылки на справочник в основном будут.

(36) Щас диски - не проблема.

(37) Справочник тоже не без огрехов. 500 лишних мегабайт на 8 млн записей, так как есть по умолчанию избыточный индекс для предопределенных элементов, которых нет.
Вот сейчас пытаюсь на партнерке донести светлую мысль убрать его нафиг.

[ОРРХ | ОРНР1 +] PredefinedID
    

Индекс по идентификатору предопределенного объекта метаданных.

Реально стало интересно и как марки в 150 символов хранить?
Типовые тоже их в регистр сведений пихают.

(42) Ну в справочнике и в РС пихать ссылку.
Мы в справочнике храним в поле Код - КодАП
В наименовании - значение ШК (как раз 150 символов).

Индексы отлично подходят.

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

РС конечно, проектировали долго и упорно, но оно того стоило.

(43)Умно. А я все ушло выкидываю в архивную таблицу, разбиваю их по месяцам. Для каждого месяца свой регистр сведений.
Но как бы криптохвосты нужны. Иначе УТМ же ругается.

(45) Полный ШК можно хранить в реквизите рядом, вне индекса. А в индексном реквизите - тип, серия, номер марки, 14 символов. Но есть еще и старая марка, где 68 символов. Поэтому не стали возиться.

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

(47) Каким образом раз и навсегда запомнить что в 1С нумеруется с Нуля, а что с Единицы?

(47) коллекции с нуля, строки с 1..всё вроде

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

Есть еще табличные документы, текстовые документы, Табличные части, Наборы записей.

45 млн марок..это где-то 16 гигов (индексы + данные)

(51) ну и ? Это всё коллекции.. ==> 0

(53) Текстовый документ с единицы.

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

(46)Так можно и ресурс запихать, или вообще в реквизит регистра. Типа подальше от индексов.

(54) ну видать, тут по аналогии со Строкой... всё вроде, везде 0 в остальном

ну и в табличномДокументе, с 1..

Если не хочется 150 символов в индекс пихать,тогда hash его и хранить гуид,по нему поиск очень быстрый,но hash рассчитывать нужно,и сложно сказать,что отличается на одну букву.

Но,нужно помнить,что hash однозначности не даёт и по результатам поиска отбирать прямым сравнением.

Загнал 10 миллионов записей.
В общем на чтении особой разницы не заметил.
При записи независимый процентов 20 быстрее.
Так что вопрос можно закрыть наверное.

(23) с какой то версии убрали эту оптимизацию