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

Распределённость возникает по 2м причинам:
1. Сбор исторических данных на центральном сервере для анализа (тут всё логично).
2. Продажа билетов с центрального сервера. Т.е. каждый автовокзал обслуживает свои рейсы самостоятельно (продажи внутри при помощи своей базы), но при этом выделает квоты на продажу для распространителей.

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

У меня возникают следующие сомнения:

- Как центральный сервак справится с таким потоком данных репликации (даже если он кластер) и как он будет в то же самое время отвечать на запросы реального времени ? (есть подозрение, что загнётся)

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

- В какую цену вы бы оценили такой проект ? (Функционал в основном должен быть построен на процедурах SQL. Все клиенты тонкие.)

Очень интересно и одновременно необходимо ваше мнение.
Прошу высказываться.

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

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

При обрыве связи центрального с автовокзалом на автовокзале продажа продолжается, но без квоты.
Например, на рейс нужно продать всего 35 билетов из них 5 квота. Т.е. автовокзал при любом раскладе продаст 30 (даже без связи).

Edd.Dragon,

Т.е. наружные продажи не будут идти, а внутри автовокзала всё будет функционировать.

P/S/ Больше всего меня интересует сама архитектура: один центральный с нагрузкой со всех регионов и много маленьких. Как оно будет ?

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

SERG1257slay82 1. Сбор исторических данных на центральном сервере для анализа (тут всё логично).Это выносите за скобки, ибо к репликации не имеет отношения.

Предполагается что сбор происходит в реальном времени и при помощи репликации. Почему же не имеет ? (и будет влиять на выбор схемы)

SERG1257slay82 - Как центральный сервак справится с таким потоком данных репликации (даже если он кластер) и как он будет в то же самое время отвечать на запросы реального времени ? (есть подозрение, что загнётся)
Зависит от нагрузки, железа и сети. Кластер совсем не в кассу.
Всегда полагал (может и не прав), что кластерная система способна распределять нагрузку. Тем более если база внутри него хранится на нескольких серваках в вертикально разделённом виде.

SERG1257slay82 Как отслеживать и разруливать коллизии типа продажи одного билета одновременно в обоих местах ?Это вам должен ответить заказчик
Это-да. Однако на данный момент более интересует принципиальное наличие такой возможности в MsSQL. Если более точно, то вопрос звучит так: "Есть ли в какой-то из систем репликации возможность обнаруживать в реальном времени подобную коллизию, вмешиваться в неё, разрешать и сразу же извещать одну из сторон, что она не права (и обязана повторить продажу)".

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

SERG1257Вообще складывается впечатление что задача не проработана. Для успешной реализации надо расписать реакцию системы на ВСЕ возможные случаи - например если потеряна связь с периферией что будет видеть веб-юзер: Server is down, последнее известное состояние, только квота. Что будет видеть пользователь отключенной системы. Что считается потерей связи, какие действия, и кто будет предпринимать после восстановления связи и т.д. Причем это будет успешная реализация только с вашей стороны, со стороны пользователя это может считаться провалом.
Это в точку. Ещё как не проработана. Да ещё и я не профи в репликации (мягко говоря). Вот и достаю всех подряд. Чтобы результат не получился в стиле "хотели как лучше...".
Ещё раз спасибо за мнение.

Спасибо, SERG1257.