1C 8.3 файловая версия.
Есть запрос


То есть, выходной набор отсортирован по полю ссылки. 1c (его движок БД) умеет однозначно сравнивать две ссылки между собой на больше меньше. Я сделал такой вывод на основание того, что порядок записей в выборке меняется строго на противоположный, если заменить asc на desc. Как известно, ссылка представляет собой 16-байтную структуру - так называемый Guid. Просьба помочь с решением 2 вопросов.
1. Какое правило использует 1С-движок для сравнения двух ссылок на больше\меньше при выполнении сортировки запроса?
2. Различается ли это правило для разных версий 1с (8.1, 8.2,8.3) или для разных, используемых ее БД (файловая, MS-SQL, Postgree) ?

МодальноеОкно, спасибо за участие.

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

Но вы правы в том, что вероятно в разных движках разные функции, и как именно работает MS SQL можно будет выяснить сделав прямые запросы и почитав документацию сравнения binary(16), а как работает файловый движок не ответит никто.

Спасибо.
Вот меня в пределах одной базы данных полностью устраивает!
Просто нужно знать как в пределах каждой из баз данных это гарантируется. То есть знaть правило сравнения для файловой, MSSql и Postgree.

Программист 1с,

это проверялось в первую очередь, к сожалению нет. Сравнивал так же побайтно в прямом и обратном порядке, тоже нет.

Бралась строка, которую дает 1с по полю ссылки, и смотрелось расположены ли выходные данные запроса согласно правилу сортировке строк. Не соответствуют


MSSQL пока не занимаюсь. Но если текстовое представление GUID в 1С отличается от общепринятого, то конечно можно\нужно на это мне указать. См. Ниже.
Если есть возможность, смотрите запрос к SQL, возможно, там тупо по 16-байтному значению сортируется.
Мне вообще конечно надо разобраться со всеми движками 1С, но я сейчас разбираюсь с файловой версий, как наиболее сложной. Если по ней не будет решения, то наличие решения по SQL мне не нужно. Пойдем другим путем. Но пока не теряю надежды.

Так вот, я беру строку, которую дает 1С по полю ссылки из запроса. Используя метод XMLString.
Проверяю отсортирован ли запрос по этой строке, не отсортирован. Дальше я транслирую эту строку в 16 байтовое представление GUID (StringToGuid Delphi), и то же проверяю соответствует ли сортировка по байтному сравнению двух Guid. Не соответствует. В обратном порядке следования байте - не соответствует. По стандартному сравнению Guid исходя из структуры


то же не соответствует.
Отсюда я делаю вывод.
Либо 1с как то странно (по особому) формирует возвращаемый строкой Guid, и я при его обратном преобразование из строки через StringToGuid получаю не правильную последовательность байт, либо 1с использует какой то дьявольский collate для побайтного сравнения Guid в сортировках.

МодальноеОкно, тепло!

Понял для себя правило сравнения 16 байтной структуры, полученной из 1С строки, с помощь стандартной трансляции (С#, delphi ) в Guid. Сравнивать по байтно в такой последовательности байт
6,7,
8,9,10,11,12,13,14,15,
4,5,
0,1,2,3

На моей небольшой демо базе (файловый движок) работает. Будут базы по больше и на других движках, проверю, отпишусь.
Спасибо всем, особенно WildSery и МодальноеОкно!

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

МодальноеОкно, периодическая синхронизация двух наборов данных (источник -> приемник) алгоритмом сложностью N (однопроходный алгоритм без бинарного поиска).
Источник - запрос из 1С, приемник таблица во внешней (не 1с) базе данных.
Для реализации такого алгоритма необходимо иметь отсортированные данные из источника и применика.
При условии, что эти отсортированные данные из источника и из приемника получены за счет навигации по подходящему индексу (без сортировки результата), такой алгоритм слияния самый экономичный. Что для моей задачи важно.

Естественно, что функция сравнения должна работать одинаково. Вот тут и столкнулся с проблемой,
БД приемника давала другой порядок записей.

1.Есть два одинаковых произвольных запроса с уникальной сортировкой (перечень полей, в том числе ссылки).
2.Один из базы источник (1С), другой из базы приемник (не 1С).
3.Открыли запросы.
4 Сравнили значения полей сортировки.
5.Если они равны, сравниваются все остальные поля запроса источника с полями запроса. Если они не равны, то выполняется изменение этой записи в базе приемнике. После чего переход на следующую запись и в запросе из базы источник и в запросе из базы приемник. На шаг 4.
6. Если поля сортировки из источника больше, то надо удалить запись в базе приемнике и в запросе из нее перейти на следующую запись. На шаг 4.
7. Если поля сортировки из источника меньше, то надо вставить запись из источника в базу приемник. А в запросе из базы источник перейти на следующую запись. На шаг 4.

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

Это упрощенный алгоритм используемой нами для синхронизации. Его сложность ~R*F, где R кол-во записей, а F количество полей. Реальный алгоритм, несколько сложней тем, что он допускает не уникальную сортировку наборов.

Программист Может правильнее в обоих базах записывать изменные или новые обьекты и потом уже только ими обмениваться?

Здесь речь идет об одностороннем обмене, то есть запись только в базу приемник. Но это пустяк.
Важно то, что репликация (синхронизация) по приращениям, которую Вы предлагаете, конечно намного эффективнее, чем полная перечитка (описанная выше).
Но она применима лишь в варианте, когда производиться передача в базу приемник таблиц, в том виде и в том составе, в котором они есть в базе источнике. Для этого в базе источнике обеспечивается логирование (журнал операций) этих таблиц, с помощью которого из нее вычитываются только новые и измененные записи. Эта схема мне известна, но она мне не подходит.
Так как в моем случае синхронизации подвергаются результаты произвольного (написанного пользователем)
сложного запроса, в котором потенциально есть join, в том числе (если это есть в 1с) с хранимыми процедурами и
всякие другие SQL штуки. Это запрос некая выжимка нужных пользователю данных.
Результат данного и любого запроса - это таблица, и вот эта таблица
заливается в базу приемник, а потом синхронизируется, описанным выше алгоритмом.

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


А в базе приемнике этому запросу ставиться в соответствие таблица. Наприимер с именем Запрос1.
Состав полей - все поля из запроса 1С.
То есть для базы приемник открывается запрос


А дальше происходит то, что описано выше. Программа бежит по обоим запросам и
выдает при необходимости в базу приемник команды update\insert\delete.

Если бы мне в базе приемнике нужны были бы по отдельности таблицы
РегистрНакопления.Продажи, РегистрНакопления.ПартииТоваровНаСкладах, Справочник.Номенклатура и т.д.
то конечно нужно \ можно использовать репликацию по приращениям. Но они мне там не нужны, мне там нужен результат вот такого запроса. Передавать по приращениям отдельные таблицы, а потом все равно открывать запрос (уже только в базе примник), смысла нет. Да на 1 запрос будет меньше, но и репликация по приращением, в общем случае, не бесплатное удовольствие.


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

Но пока хватит того что есть с головой.


Та нет, во общем то понятно, что такое бывает. На это случай, пока, есть другие инструменты.
Сюда кто то дочитал? :)

Программист 1с, респект!

Теперь, мы можем только дискутировать в единственном вопросе, что же именно делать опционально. ;)
Полную перегрузку\сверку или специальный регистр учета, который закачивать по приращению.

Оба варианта рабочие, но второй специфичен (реализуем) только для 1С.
А так как система, которую мы сейчас делаем, носит универсальный характер, то есть предназначена для
закачки из различных SQL баз, потенциально могут быть и все, обсуждаемые на данном сайте,
то естественно, мы, для начала, опираемся на универсальный рецепт, то есть на полную перезагрузку \ сверку.

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

Да можно подключится к моей базе, но я не пойму зачем мне проводить сверку изнутри 1с. А если в качестве базы источника не 1с-база, а что то другое? Вы поймите, мы пишем BI-систему (аналог qlkickview , microsoft power bi и т п) Для любой такой системы нужна загрузка исходных данных в свое промежуточное хранилище (буква E в аббревиатуре ETL ) и дальнейшая синхронизация этого хранилища. В качестве исходной базы может выступать в принципе любая базай любой информационной системы. Поэтому один из главных принципов предъявляемых к загрузчику - это его универсальность

В том то и дело, что алгоритм который я Вам нарисовал, без всяких хэшей и прочего сравнивает быстрее некуда два больших набора данных, и записывает (вставляет, удаляет, изменяет ) данные в базу приемник. Поэтому открывать запрос из 1c к моей базе, или из моей базы к 1с, смысла нет никакого. Это только может усложнить реализацию из за относительной бедности языков 1С и T-SQL. Например, мы, в своей реализации этого алгоритма, разбиваем задачу на два потока, один сравнивает данные, другой записывает обнаруженные расхождения в базу приемник.

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



На 120%.

Нет, конечно. Но мы будем бороться. Надо же кому то сделать хорошую православную BI-систему? ;)

Здесь нет никаких сомнений. Нужно универсальное решение.
Как и многие другие системы, наша развивается от частного решения к универсальному продукту.
Этап частного решения пройден . Система успешно внедрена на 1 крупном предприятии и трех поменьше.
Теперь хотелось бы сделать тиражируемый продукт, это на порядок или даже два сложнее. Но зато интересно.
Может мы с Вами или с каким нибудь другим участником этого форума еще партнерами станем. Чем черт не шутит! ;)

Это не долго. Сравнения полей одной записи - это алгоритм линейной сложности F. Где F количество полей. Ведь мы сравниваем 1 поле с первым, второе со вторым и так далее, пока не найдем хоть одно различие или не проверим все поля. Я уже писал, что общая сложность всего алгоритма N*F, и где N это количество уникальных id, а F это количество полей (размерность подмассива). Массивы мы не сортируем, а получаем в готовом отсортированном виде из СУБД с использованием индекса.
Допустим есть массив 1 и массив 2, как в вашем примере, пусть они не отличаются. Размер каждого массива 100 млн. В каждом элементе подмассив (остальные реквизиты) размером 20. Значит сложность 100 000 000*20=2 000 000 000. Два миллиарда. Соотвественно все сравнение этим алгоритмом займет считанные секунды (гораздо больше уйдет времени на считывание таких объемов с базы источника и базы приемника.

Не беря во внимание, что хеш для записи из источника нужно еще посчитать (он ведь не известен),
допустим хеш записи из первого массива совпал с хешом записи из второго массива и что дальше ? ;)

1. Сортировки не будет. Посмотрите материалы, в которых рассказывается как выполняются запросы с order by при наличии подходящего индекса.
2. Копирование в temp то же не будет. Скорее всего, я не уверен на счет MS SQL, но в firebird например точно не будет. Не думаю что MS ему уступает
3. Почему обязательно по сети? Кто мешает расположить загрузчик там же где и база
4. Загрузка может осуществляться с зеркальной базы, предназначенной для чтения. Эту базу можно расположить на том же компьютере что и загрузчик. Нет загрузки сети, нет загрузки основного сервера. Mirroring в MS SQL server - штатное средство
5. Загрузка в BI систему - это периодическая загрузка. Она может выполнятся в интервале времени когда аппаратная часть системы низко нагружена.

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

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

BI-системы и OLAP системы в больших таблицах (таблицы фактов), как правило оперируют всего 3 типами данных. целое число, число с плавающей точкой и дата.
В таблицах справочниках (таблицы измерений) 4 тип - строки и возможно blob, для хранения например фотографий, например сотрудников для красивого дашборд (но это уже экзотика). Записей в таблицах справочников не много.

Исходя из всего выше сказанного, я могу утверждать, что для 80% фирм, которым нужна BI-система, которой у них сегодня нет, принцип полной перечитки базы источника, полностью подойдет. Для оставшихся 20% нужно настраивать (программировать) загрузку по сегментам. Дело это, в общем случае не совсем простое, проще купить сервер помощней. См. ниже


:)

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

Если части компаний даже сегменты не помогут, ну что, надо будет тогда программировать классическую загрузку по приращением. Пока это для нас очень мало вероятно, так как те гиганты, которым это может понадобиться, уже обзавелись datawarehouse и BI-системами со своим блек-джеком и шлюхами. Мы нацелены не на них.
Наша идея - BI в массы, для тех кто вырос из excel, а qlickview дорого!

Абсолютно правильно. И то, что в было в постскриптуме, то же верно.

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

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

Если уж сравнение полей так уж хочется побороть, то эту подзадачу можно винести в отдельный поток.
Как правильно отметил AHDP, весь алгоритм хорошо параллелится. Сейчас у нас 4 потока,
1. поток чтение из базы приемника.
2. поток чтение из источника,
3. поток сравнения
4. поток записи отличий в базу приемник.

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

Вероятность появление 2 одинаковых гуидов в 1с - это проблем 1с, ну или гуидов.
А вот появление в BI-системе не тех данных, что в источнике, будет моей проблемой.

Причем трудно отлавливаемой.
Ну и зачем мне эта проблема?

Зачем лишний геморой с настройкой для пользователя как в полях, созданного им произвольного запроса,
где разрешено все, что угодно его синтаксису , делать хеш (из другого хеша или из чего нибудь еще) ?

И все это на пустом месте, так выигрыша не будет. См. выше про потоки.

Это будет. Чуть выше я писал про сегменты. Как правило, разделение на сегменты связанно с датами.

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


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


Для исторического



Как видно в качестве критерия разделения выступает логическое выражение Продажи.Период>=&Border.
Где Border это параметр запроса чье значение в нашем случае равно '01.01.2020'
В оперативном сегменте результат выражения берется как есть, в историческом его результат инвертируется.
То есть каждая запись общего извлекаемого набора попадает только в один из сегментов (в один из запросов ).
Если в таблице РегистрНакопления.Продажи есть индекс начинающийся с поля Период,
то такой запрос выполниться гораздо быстрей , почти прямо пропорционально количеству записей продаж в 2020 году к общему кол-ву записей продаж во всей базе.

Запрос по историческому сегменту (с условием not (Продажи.Период>=&Border)) делается по прежнему долго (часы, сутки) но нам не надо его делать часто. Кому то будет достаточно и 1 раз.

я этого не говорил. Как же без этого, все на этом и стоит.

Не совсем уверен, что Вас понял, но попробую ответить.
В контексте данного топика, они могут выступать в качестве полей, используемых для сортировки запросов извлекающих данные из 1С. Сам алгоритм синхронизации, который мы здесь поневоле обсуждаем, опирается на то, что входной набор отсортирован.
Еще Guid нужны для связи между таблицами фактов и таблицами измерений. Если прикладная система использует идентификацию записи и связи записей на основе типа Guid, то BI-система должна уметь работать с этим типом, так же как и целочисленными ключами. Не больше и не меньше, а в прикладном плане конечно он ей не нужен.

Этого достаточно. Глобальной уникальности не требуется.