Репликация вложений

[morpheus]

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

т.к. пользователи удалённые, промеж. серверов нет, то все конектяться на главны сервер и в режиме раел-тайм сливают всё файло.
сами понимаете сколько времени это может занимать при плохом соединении.

Как сделано сейчас: для каждого типа вложений создаться отдельный документ на сервере ( всё в UI ) - куда скидываються все вложения данного типа и документ уже c вложениями сохраняеться на сервера. При этом к данному документу может быть прилеплена различная инфа ( дата принятия и т.д. )

Какие у Вас могут быть предложения по оптимизации данного процеса?

мои мысли:
у каждого на локале держать реплику бд "файлы" - в которую все вложения кидать и реплицировать только по необходимости ( или в ручную ).

 

[ToxaRat]

Morpheus

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

я бы еще добавил - по расписанию

так как черег УИ лучше им на сервер не лезть вообще, а по расписанию будут передавать исключительно сухие данные
неплохо будет если еще включишь сетевое ужимание и LZ1

 

[morpheus]

продолжая тему, вопрос:


возможно ЛИ ? :
создавать такую реплику на клиенте скриптом по запросу пользователя? с правильной формулой репликации(в одну сторону)?

 

[Akupaka]

и реплицировать только по необходимости ( или в ручную )

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

Желательно использовать формулы репликации, чтобы в случае чего плохие данные не расползались по всем репликам (иногда находятся народные умельцы, любящие автоматизировать процессы самостоятельно, и пишут свои скрипты, которые загоняют данные в базу).

Какие у Вас могут быть предложения по оптимизации данного процеса?

А что там можно оптимизировать, если сжатие с большим коеффициентом не применимо?
Разве что рассмотреть вариант расскладывать все вложения отдельными доками, а не группировать по типам, тогда доки будут меньше, и больше вероятность успешной передачи данных.
Еще обязать пользователей применять нужные параметры создания сканокопий, а то иногда людишки лепят копии паспортов в максимальном качестве, хотя достаточно серого и т.п.

 

[nvyush]

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

Можно ввести квоты на размер вложений и при превышении блокировать сохранение, а пользователю выводить сообщение с подсказкой, как сжать.

 

[Akupaka]

Можно ввести квоты на размер вложений

Я бы сказал нужно!

 

[morpheus]

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

проблема в скорости передачи (логично что размер влияет на скорость).

открытый вопрос про создании реплики базы скриптом с определённой реплик. формулой ( клиент ->> сервер )

Добавлено: nvy
учту, спасибо

сечас в поиска инструмента автоматизации процесса переворачивания фото и очернобелывании скан копий(которые не требуют цветных сканов)

 

[Akupaka]

да и не с квотами проблема

Дык, никто и не учитывает проблем с диском ))
У нас так поступали: предполагаешь какой должен быть максимальный размер документа определенного типа, и забиваешь в каком-то профиле, потом проверяешь и ругаешься, если выше.

открытый вопрос про создании реплики базы скриптом с определённой реплик. формулой

Set notesReplication = notesDatabase.ReplicationInfo
Set notesReplicationEntry = notesReplication.GetEntry( source$ , destination$ [ , createflag ] )

formula$ = notesReplicationEntry.Formula
notesReplicationEntry.Formula = formula$

 

[lmike]

сечас в поиска инструмента автоматизации процесса переворачивания фото и очернобелывании скан копий(которые не требуют цветных сканов)

а чего искать - java
вот афинные преобразование

Ссылка скрыта от гостей

там куча всяких..., даже в iText есть какой-то тул

 

[lmike]

вот интересный метод (в т.ч. для "безголовых" вариантов)

Ссылка скрыта от гостей

Добавлено: вот преобразование в грэйскэйл -

Ссылка скрыта от гостей

 

[ToxaRat]

возможно ЛИ ? :
создавать такую реплику на клиенте скриптом по запросу пользователя? с правильной формулой репликации(в одну сторону)?

где твоя фантазия?
на открытие базы скрипт по созданию или открытию локальной реплике (кроме админа только)
и на формулу репликации я бы на твоём месте не лез, разрули всё красиво ридер полями, иначе потом будешь играть в игру "а почему формула репликации уползла в другую реплику"

 

[Akupaka]

и на формулу репликации я бы на твоём месте не лез, разрули всё красиво ридер полями, иначе потом будешь играть в игру "а почему формула репликации уползла в другую реплику"

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

 

[morpheus]

где твоя фантазия?
на открытие базы скрипт по созданию или открытию локальной реплике (кроме админа только)

зачем??? не у всех говёный и-нет, это надо выборочно по желанию юзверя

 

[ToxaRat]

зачем??? не у всех говёный и-нет, это надо выборочно по желанию юзверя

тем более, создай на каждого профайл, закороти его на открытие базы и будет реплика только у тех кому нужно

 

[Akupaka]

создай на каждого профайл

А если пользователь работает из двух мест вызова? Одно с репликой, другое напрямую.
Имхо, такое нельзя/не нужно автоматизировать.

 

[ToxaRat]

А если пользователь работает из двух мест вызова? Одно с репликой, другое напрямую.

зачем ему два места вызова, когда он может решить одни одним щелчком?

 

[Akupaka]

зачем ему два места вызова, когда он может решить одни одним щелчком?

вот ничего не понял что он должен решать, щелчком чего? мутишь ))

 

[morpheus]

Akupaka
не мутит, Вы оба говорите на разных языках


ты говориш о физическом расположении пользователя, а Тоха про "места вызова" - клиентские настройки


кароче то что предложеил Антон - просто напросто не нужно в рамках моей задачи, т.к. промежуточную локальную базу необходимо создавать только если пользователь так решит