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-система должна уметь работать с этим типом, так же как и целочисленными ключами. Не больше и не меньше, а в прикладном плане конечно он ей не нужен.

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