Как прикрутить ГУИД к регистру сведений

Публикация № 1044215

Разработка - Практика программирования

GUID ГУИД УникальныйИдентификатор Регистр сведений

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

Это абзац для тех, кто постоянно спрашивает "как это можно применить на практике?" (1). Мы пишем обмен между идентичными конфигурациями, основным требованием к которому является максимальная актуальность данных (задержка в пределах нескольких секунд). Из этого требования вытекает необходимость многопоточной обработки. Как следствие, требования к согласованности данных ослаблены до согласованности в конечном счете (2). Вследствие многопоточного режима, из источника могут отправиться две версии одного и того же объекта, которые на стороне получателя могут подхватиться двумя разными потоками разбора и какая версия окажется в итоге записанной последней - никому неизвестно. Это не соответствует принципу согласованности, пусть даже ослабленному. Поэтому, необходимо гарантировать запись именно последней версии объекта, с игнорированием предыдущих (3). Сделать это можно например так: в табличке, где лежат сырые данные для разбора - надо хранить номер сообщения, тип и идентификатор объекта. Соответственно, когда один из потоков будет подхватывать очередной объект для загрузки - нужно просто взять объект с максимальным номером сообщения, а остальным версиям поставить статус устаревших.
И в этой теории казалось бы все хорошо... Для объектных типов в качестве идентификатора идеально подходит гуид, для наборов записей регистров - гуид регистратора, константы идентифицируются типом (можно просто писать пустой гуид  00000000-0000-0000-0000-000000000000)... но черт возьми, набор записей регистра сведений, не подчиненного регистратору не имеет идентификатора!
Мы не могли позволить, чтобы это обстоятельство похоронило весь наш быстрый и красивый обмен, поэтому разработали схему, позволяющую назначить набору записей идентификатор и использовать его как гуид этого набора.

 

Почему мы идентифицируем именно наборы

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

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

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

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

Итак, приступим к прикручиванию идентификатора. План такой:

  1. Заводим общий реквизит типа УникальныйИдентификатор и подпиской заполням его.

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

Сигнатура, корзина и идентификатор

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

Сигнатура - это данные (строка, число), однозначно идентифицирующие что-либо. Например, сигнатура документа в 1С - это его тип и гуид. Сигнатура человека - это его ДНК. Сигнатура автомобиля - вин-номер. Продолжать можно долго, идея надеюсь понятна. Сигнатурой набора записей, его ДКН, естественным образом является набор значений основных измерений.

При этом, эта сигнатура будет обладать следующими замечательными качествами:

  • однозначность и непротиворечивость: от одного набора записей можно прийти к одной и только одной сигнатуре. Иными словами, сигнатура и значения основных измерений связаны друг с другом один-к-одному и имея один из них можно однозначно получить другой.
  • независимость от условий в которых выполняется алгоритм. Иными словами, алгоритм будет давать одинаковый результат на разных базах, в разное время, без интернета и т.п.

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

Корзинами будем называть хранилища сигнатур, при этом сигнатуры будут раскладываться по корзинам не абы как, а по жесткому правилу, обеспечивающему повторяемость. Например, если есть сигнатуры ААА, ААБ, БАА и ВВВ - то таким правилом может быть, например, взять первый символ. Т.е. мы однозначно определим, что в корзину А попадают сигнатуры ААА и ААБ, в корзину Б - сигнатура БАА, а в корзину В - сигнатура ВВВ. (4)

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

1. Основные изменения представим строкой вида <Название "Тип"="ЗначениеТипа" "Значение"="ИдентификаторЗначения">. Например:

  • <Период Тип="Дата" Значение="19.05.2019 19:02:08">
  • <ДокументОснование Тип="Неопределено" Значение="Неопределено">
  • <Номенклатура Тип="CatalogRef.Номенклатура" Значение="6F9619FF-8B86-D011-B42D-00CF4FC964FF">
  • <Характеристика Тип="CatalogRef.ХарактеристикиНоменклатуры" Значение="00000000-0000-0000-0000-000000000000">

На что обратить внимание:

  • Если кому-то нравится использовать псевдо-json вместо псевдо-xml синтаксиса или придумать полностью новый формат записи - это на скорость не влияет, главное чтобы не получилось что строка "11.02.2019 12:00:00" и дата "11.02.2019 12:00:00" - это одно и тоже
  • Также можно креативить на предмет наличия значения типа Неопределено и пустых ссылок.
  • Тип здесь - это не тип поля, а тип значения. т.е. независимо от того сколько типов может лежать в этом поле - мы пишем только тот, который реально лежит.
  • Неопределено и пустая ссылка - это не одно и тоже и оба значения могут встречаться в полях множественного типа.
  • Для получения строкового представления типа - мне известен один способ: XMLТипЗнч.
  • Лучше добавить ко всему этому название самого регистра, поскольку при некоторых условиях это может сильно облегчить нам жизнь, об этом пойдет речь ниже.

2. Далее просто конкатенируем (сцепляем) полученные строки и получаем саму сигнатуру:

<РегистрСведений.НазваниеНашегоРегистра><Период Тип="Дата" Значение="19.05.2019 19:02:08"><ДокументОснование Тип="Неопределено" Значение="Неопределено"><Номенклатура Тип="CatalogRef.Номенклатура" Значение="6F9619FF-8B86-D011-B42D-00CF4FC964FF"><Характеристика Тип="CatalogRef.ХарактеристикиНоменклатуры" Значение="00000000-0000-0000-0000-000000000000">

Чтобы поберечь нервы ресурсы СУБД - ее можно поджать каким-нибудь алгоритмом сжатия (методы, не выходящие за пределы 1С гуглятся на ИС), "качество" сигнатуры при этом не пострадает, но глазами ее читать станет невозможно.

3. Далее надо разобраться с корзинами. Для них создадим отдельный справочник: один элемент справочника = одна корзина. Идентификатор корзины = ГУИД элемента справочника. Чтобы определить идентификатор корзины по сигнатуре - нужно ее хэшировать алгоритмом MD5 (5). В табличной части сделаем две колонки: сигнатура и ГУИД. В первую колонку будем складывать сигнатуры наборов записей, а во вторую идентификаторы этих наборов (просто Новый УникальныйИдентификатор). Далее, в корзине (табличной части) перебираем все строки - ищем есть ли там наша сигнатура, если нет - добавляем строку и назначаем ей новый гуид, который и будет идентифицировать наш набор записей, если есть - берем ранее созданный.

Вот в общем то и все.

Производительность

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

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

А что если...

... изменить в наборе записей значение одного из измерений. Кодом такое сделать не получится, а если провернуть это через пользовательский интерфейс - в таблице изменений появятся две записи: старого набора и нового набора. Одна будет сигнализировать об удалении старого набора, вторая - о появлении нового. Сигнатуры так же окажутся разными: на удаленный набор своя и на новый набор своя. В этом смысле наш механизм работает абсолютно "синхронно" с платформой.

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

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

... в двух узлах почти одновременно запишут одинаковые записи - у них будет одинаковая сигнатура, одна и таже корзина, но разные идентификаторы. Такие конфликты разрулить автоматически не составит труда. Более того, для этого не нужно иметь сложной синхронизации разных баз, а сделать это можно независимо в разных узлах (например, если предположить, что сгенерированный идентификатор из базы 1 отправился в базу 2, а из базы 2 в базу 1). Для этого нужно иметь специфическую логику в обмене (7).

 
 Мелкий шрифт

 

(1) На самом деле, я считаю, что "стоящая мысль" достойна быть озвученной, независимо от того, видно ли для нее достойное применение. Если 100 человек не знают как применить что-то на практике - это не означает, что не найдется 101-й, который давно мучается соответствующей проблемой. Математики не дадут соврать.

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

(3) Вопрос о том, важна ли последовательность объектов или важны только сами объекты, весьма неоднозначен и имеет глубокие теоретические корни. Можно сформулировать два более конкретных вопроса, ответы на которые имеют ключевое значение для любого обмена:

  1. можем ли мы нарушить последовательность записи разных объектов? Имеет ли при этом значение одного типа объекты или разного?
  2. можем ли мы нарушить последовательность записи одного объекта? (т.е. из версии 1 перевести его в версию 3, минуя версию 2, в которой он пребывал в источнике)

Мы более-менее нашли для себя ответы на эти вопросы. Сразу оговорюсь, что тема довольно скользкая и мы не претендуем, что эти ответы безупречно подходят даже для РТ, не говоря уж о любых других конфигурациях. Итак:

  1. можем ли мы нарушить последовательность записи разных объектов? да, но только при условии что мы имеем обмен между идентичными конфигурациями и движения по регистрам передаем "как есть", без перепроведения документов. Все что может помешать такому ответу - противоречит принципу, принятому при разработке типовых конфигураций 1С: "если документ не менялся - результат проведения при перепроведении меняться не должен" (sic!). Иными словами, у нас может быть какая-то проверка по ссылке (например попытка проверить ставку ндс у номенлатуры, которой еще нет в этой базе), но это будет означать, что такая проверка может изменить результат проведения документа при изменении номенклатуры, что противоречит сформулированному принципу. В крайнем случае - такая ситуация окончится исключением и автоматическим повтором загрузки, которая, после загрузки номенклатуры, окончится успехом с какой-то попытки.
  2. можем ли мы нарушить последовательность записи одного объекта? нет, но мы все равно так сделаем ) Строго говоря, нет принципа по которому результат записи объекта не должен зависеть от предыдущего состояния этого объекта. Например, документ может быть создан только в статусе "новый", из него переведен только в статус "проверен". Соответственно запись в приемник сразу в статусе "проверен" окончится неудачей. Но есть два но: первое - типовой механизм регистрации объектов "съедает" подобные случаи, второе - таки есть разница между записью пользователем и записью в режиме обмена данными. Соответственно, любые подобные случаи мы отлавливаем "по факту" и выносим проверку за пределы обмена данными.

(4) Вообще, весь этот алгоритм - это творчески преработаный алгоритм Хэш-таблиц. Так что это компьютер-саенс, бэст-практикс и все такое, а не "костылей понаставили"

(5) На самом деле не обязательно именно так. Можно придумать любой свой алгоритм, вплоть до такого: взять строку в двоичном коде, разбить на 128 участков, из каждого взять по первому биту - слепить их в гуид, главное чтобы он обеспечивал повторяемость. Но такой алгоритм не будет давать хорошего распределения, потому что на определенных позициях будут всегда будут определенные символы (например первые символы очень часто будут повторяться вследствие вставки названия регистра), что неизбежно сделает одни куче больше других, а MD5 дает хорошее распределение и вероятность появления больших куч крайне мала.

(6) Вопрос о том, требуется ли идентифицировать наборы разных регистров, имеющие одинаковые значения основных измерений одним идентификатором или разными упирается в вопрос о том, какую постобработку изменения метаданных регистра вы хотите писать.
Если идентификатор будет один - алгоритм постобработки должен буть запущен после изменения состава основных измерений и он должен уметь "расщеплять" записи, т.е. для записей неизменного регистра идентификатор останется тот же, а для записей измененного регистра идентификаторы будут новые и их нужно раскидать по всем зависимым местам, при этом понимая где мы имеем дело с идентификатором набора неизменного регистра, а где - измененного.
Если же идентификатор зависит от имени регистра - алгоритм должен запуститься как в случае изменения состава основных измерений, так и в случае изменения имени регистра (от последнего нас бы избавило знание идентификатора метаданных регистра, но нам его достать негде. или есть где?..). Но этот недостаток компенсируется отсутствием необходимости расщеплять и замещать: изменится только сигнатура и корзина в которой она лежит, идентификатор останется тот же, что избавит от необходимости заменять его по другим местам.
Хорошего ответа на этот вопрос нет - каждый подход имеет свои минусы. Вероятно, если получить идентификатор регистра (как объекта метаданных) и идентификаторы его основных измерений (в том же смысле) - эту проблему можно разрешить. Если кто-то предложит способ как это сделать - я возьмусь протестировать предложенный подход и сообщу результаты. Пока же остается писать длинную инструкцию на случай, если кто-то будет трогать регистр "после нас", разрабатывать отдельный механизм, в котором "запомнить" количество и порядок измерений, задействованных в сигнатуре каждого регистра и если оно вдруг изменилось - сыпать исключениями (вплоть до отказа от начала сеанса) и надеяться, что "после нас" не посчитают это странной фигней, которую можно игнорировать.

(7) Во-первых для справочника содержащего корзины, мы никогда не затираем таб.часть, а только добавляем новые записи, во-вторых, при назначении идентификатора первой сигнатуре в корзине - его можно сделать идентичным идентификатору корзины (это не привнесет никаких гарантий, просто избавит от 99% дополнительной нагрузки на БД), в-третьих, если в элементе оказалось две строки с одинаковой сигнатурой - из двух конкурирующих гуидов выбрать тот который меньше, а тот что больше пометить как неактуальный, в-четвертых, везде, где мог быть записан конкурирующий гуид - исправить его на нужный. Все описанное должно происходить в первые же секунды после создания соответствующего набора, и "плохой" идентификатор не успеет слишком "расползтизь" по базе, однако, если включить паранойю рассмотреть самый негативный сценарий - "плохой" идентификатор может закэшироваться где-то в повторноиспользуемых значениях и продолжить свое существование (собственно для последующих разборов полетов и предлагалось не просто удалять, а помечать их неактуальными). Честно признаюсь, у меня реализовано только "во-вторых" из написанного в этом пункте и полет пока нормальный.

 

21

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. VmvLer 16.04.19 13:15 Сейчас в теме
много текста и сразу необходимо вникать в чьи-то проблемы

не логичнее ли в первой строке простынь ответить понятно и просто одной строкой зачем это нужно?
zurapa; sergey_garin; lukyan; the1; Идальго; Xershi; +6 1 Ответить
2. Xershi 694 16.04.19 13:57 Сейчас в теме
В 1С для этого хеш используют. Возможно вы про это не слышали?
Статью не читал!
3. m-rv 763 16.04.19 14:59 Сейчас в теме
(2) нет, не слышал, расскажите пожалуйста подробнее: от чего вычисляется хэш и какие гарантии это даёт?
4. Xershi 694 16.04.19 16:24 Сейчас в теме
(3) ну хеш это как у пароля есть контрольная сумма, которая шифруется.
Как простой пример. Зашифровать дату записи и его значения измерений. Если изменилось хоть одна запись, то хеш будет другой.
Сам не применял, но например в обработке игры в шахматы видел алгоритм.
Плюс есть регистры в типовых или нет, не скажу, которые как раз используют реквизит с одноименным названием.
На 8.3 вычисления хеша кажись уже можно платформой делать. До этого использовали компоненту.
5. m-rv 763 16.04.19 20:30 Сейчас в теме
(4) да, эта история понятна, но хэширование не дает гарантировано уникальный хэш на каждое новое значение. Хэширование дает очень высокую вероятность уникального значения, но не гарантию, поэтому в строгих алгоритмах его использовать нельзя, только для вспомогательных нужд. Об этом собственно и статья )
6. Xershi 694 16.04.19 21:35 Сейчас в теме
(5) что на 1 хеш можно 2 пароля придумать и авторизуешься?
Где такое вычитали?
7. m-rv 763 17.04.19 07:41 Сейчас в теме
(6) к этому вопросу можно подойти с двух сторон: гугла и логики.
пример двух строк с одинаковым хэшем MD5 можно найти например тут: https://en.wikipedia.org/wiki/MD5
логически можно рассудить, что MD5 состоит из 32 шеснадцатиричных цифр 0-9,a-f. Соответственно, если мы хэшируем все варианты строк, состоящих из 33 шеснадцатиричных цифр - количества вариантов хэшей не хватит на все варианты исходных строк и какие-то строки неизбежно будут иметь одинаковые хэши
8. Xershi 694 17.04.19 11:37 Сейчас в теме
(7) да про Коллизии MD5 не слышал. Теперь в курсе.
Но там говорится про суффиксы. Не думаю что они будут отличаться в 1С. Также есть же и другие алгоритмы шифрования? И там говорится только про 128 битный ключ. А про 256 ничего.
10. m-rv 763 18.04.19 09:12 Сейчас в теме
(8) 128, 256, 512... все это будет уменьшать вероятность дублей, но не исключать их
11. Xershi 694 18.04.19 09:15 Сейчас в теме
(10) вы не поняли. хеш я так представляю формируется по перфиксам из 1С, а суффикс остается всегда один. Поэтому коллизий не будет.
Алгоритм формирования не читал.
9. o.nikolaev 193 17.04.19 23:38 Сейчас в теме
По разделу "Мелкий шрифт", есть же концепция CRDT - бесконфликтная синхронизация данных, где данная возможность зашивается в прям в сам тип который передается.
13. vdmkvrshn 13 19.04.19 11:05 Сейчас в теме
Статью прочитал на 80-90% - всё надеялся найти в тексте обоснование, для чего это нужно в реальной задаче и не нашел.
Единственная описанная проблема: "записали набор с одной записью, выгружаем 100500". Ну допустим... А как Ваше решение поможет этого избежать? Может я что-то пропустил по тексту, но я ответа на этот вопрос не нашел.
По-моему, если надо идентифицировать набор записей ссылкой, то хорош способ, применяемый в типовых конфигурациях на УФ для контроля уникальности элементов справочника по значениям реквизитов. Это регистр сведений и справочник с одинаковым набором измерений регистра и ключевых реквизитов справочника, по которым необходимо контролировать уникальность. Я говорю про справочники КлючиАналитикиУчетаХХХХХ и регистры сведений АналитикаУчетаХХХХХ.

Ещё, так сказать, замечание не по теме.
Вы пишете такое:
В первую колонку будем складывать сигнатуры наборов записей, а во вторую идентификаторы этих наборов (просто Новый УникальныйИдентификатор)

На своем опыте могу утверждать, что "Новый УникальныйИдентификатор()" дает дубли при циклическом вызове. Была как-то необходимость связать строки нескольких деревьев значений на форме: при изменении значения в строке одного дерева менять также в другом дереве. Было решено для простоты генерации ключа строки использовать УникальныйИдентификатор. В общем практика показала, что он иногда НЕ уникальный. Его 99.(9)% уникальность гарантирована только в составе ссылок в рамках одной таблицы базы данных. (За годы работы более десяти баз по модели РИБ не появилось ни одного дубля ссылки среди документов одного типа, но была один раз группа номенклатуры с такой же ссылкой, как элемент в другой базе, что привело к останоке обмена, естественно).
14. m-rv 763 19.04.19 13:10 Сейчас в теме
(13)
Зачем мне это нужно - я постарался описать в спойлере «суть моей проблемы».
Вести пару РС-справочник для каждого регистра - это довольно нудное мероприятие (хотя для задачи, где задействовано 1-2-3 регистра - может подойти), плюс такой подход будет довольно затратным с точки зрения производительности
Про неуникальность ГУИДа - мое мнение - все такие случаи - это недорасследованные ошибки в коде. Я не хочу вас обидеть, у всех есть факапы, а сам я так иногда косячу, что аж п-ц, но когда в следующий раз такое увидите - ищите свой баг
15. vdmkvrshn 13 19.04.19 14:17 Сейчас в теме
(14) Я понимаю Ваше подозрение на мой баг, но после замены гуида на последовательно назначаемые номера все проблемы ушли сразу без прочих правок кода. Минус такого подхода - необходимость вести глобальный счетчик этих номеров в реквизите формы, например. Поэтому хотелось использовать гуиды.
12. m-rv 763 18.04.19 09:23 Сейчас в теме
Интересная концепция, спасибо. У меня получается state-based CRDT, я в тренде ))
Но основная то проблема в том, что когда писали РТ имели в виду strong consistency и то, что все работает - весьма интересный результат
16. shiaju 08.07.19 13:17 Сейчас в теме
Самое полезное, что я вынес из этой статьи - это пассаж про компьютер сайенс, и да, я этим буду пользоваться, спасибо большое! xD
Оставьте свое сообщение