Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Какой механизм обмена данными лучше использовать в этом случае?  [new]
uaggster
Member

Откуда:
Сообщений: 770
Коллеги, помогите концептуальным, т.с., советом!
На центральном сервере имеется БД, которая содержит одну большую секционированную таблицу.
Имеется N периферийных серверов, каждый из которых тоже содержит БД с такой же таблицей, но в этой таблице заполнена, фактически, только одна секция таблицы, относящиеся к другим серверам, можно игнорировать.
Изменения производятся только на периферийных серверах.
Необходимо организовать восходящий обмен от периферии в центр.
Положение сильно осложняется тем, что табличка содержит блоб поля, и одна запись может весит сотни мегабайт, а связь с периферией - иногда очень не быстрая (т.е. тупо выгружать секцию в csv и гнать ее в центр, чтобы заменить секцию - не вариант).
Я так понимаю, что стандартные механизмы, как то репликация, миррор и т.д. применить не получится?
Как выйти из положения?
17 янв 18, 20:33    [21114895]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
доставлять блобы размером > 100K отдельно чере ftp.

Достаточно будет 1-way replication.
17 янв 18, 20:57    [21114932]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Massa52
Member

Откуда:
Сообщений: 373
uaggster,

7z, в зависимости от данных существенно может сократить объем передаваемых данных.
18 янв 18, 07:35    [21115295]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
uaggster
Member

Откуда:
Сообщений: 770
Massa52
uaggster,

7z, в зависимости от данных существенно может сократить объем передаваемых данных.

Они уже хранятся зазипленные в виде varbinary(max).
18 янв 18, 09:34    [21115542]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
uaggster
Member

Откуда:
Сообщений: 770
Lepsik
доставлять блобы размером > 100K отдельно чере ftp.

Достаточно будет 1-way replication.

Не понимаю, как это можно реализовать.
Поясните, если возможно, на пальцах!
18 янв 18, 09:35    [21115546]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Massa52
Member

Откуда:
Сообщений: 373
uaggster,
У нас, примерно, такая задача решается в два этапа,
На первом этапе скидывается запись за записью с csv/xml формате в определенную папку и заворачивается 7z.
На втором этапе скриптом(bat/cmd), который использует клиентf FTP/SFTP отправляется в пункт назначения(FTP/SFTP server).
Ну а там все разворачивается и пузырится в центральный SQL.
18 янв 18, 09:56    [21115603]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
uaggster
Member

Откуда:
Сообщений: 770
Massa52
uaggster,
У нас, примерно, такая задача решается в два этапа,
На первом этапе скидывается запись за записью с csv/xml формате в определенную папку и заворачивается 7z.
На втором этапе скриптом(bat/cmd), который использует клиентf FTP/SFTP отправляется в пункт назначения(FTP/SFTP server).
Ну а там все разворачивается и пузырится в центральный SQL.

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

И, кстати, если сразу выливать данные "по записи, в формате xml" в filetable?
Я так думаю, что средствами 2016 их можно и паковать на лету.
... а отправлять на центральный сервер - натравив на виртуальную папку filetable что-нибудь типа btsync или sinting.

Вроде, складывается с минимальными вложениями в программирование, как Вы считаете?
18 янв 18, 12:29    [21116105]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Massa52
Member

Откуда:
Сообщений: 373
uaggster,

Это не совсем репликация. Данные рождаются на Remote Site и там собираются в локальной базе.
И каждая запись уникальна по времени. Так что мы не используем суррогатные ключи и используем естественный - типа datetime.
Все вновь родившиеся/сформировавшиеся записи тупо отправляются на центральный сервер.
И там по ключу(datetime) либо update при совпадении либо insert. Вот такова специфика данных.
Так как это все у нас уже много лет эксплутируется - и проблем нет, то у нас никто не заморачивается чтот обновлять.
18 янв 18, 12:48    [21116178]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Massa52
Member

Откуда:
Сообщений: 373
Да - забыл написать - скрипты, которые это все выполняют небольшие - их непроблем состряпать.
Как FTP сервер исползуется Filezilla, а клиенский FTP(я уже не помню какое приложение мы использовали).
На одном из сайтов вроде сделали RestAPI и там по HTTP JSONы гонят.
18 янв 18, 13:03    [21116261]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
uaggster
Lepsik
доставлять блобы размером > 100K отдельно чере ftp.

Достаточно будет 1-way replication.

Не понимаю, как это можно реализовать.
Поясните, если возможно, на пальцах!



https://www.linkedin.com/learning/microsoft-sql-server-2016-installation-and-administration/database-replication
18 янв 18, 19:35    [21117925]     Ответить | Цитировать Сообщить модератору
 Re: Какой механизм обмена данными лучше использовать в этом случае?  [new]
uaggster
Member

Откуда:
Сообщений: 770
Lepsik
uaggster
пропущено...

Не понимаю, как это можно реализовать.
Поясните, если возможно, на пальцах!



https://www.linkedin.com/learning/microsoft-sql-server-2016-installation-and-administration/database-replication

Битая ссылка :-(
19 янв 18, 16:00    [21120865]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить