Всем доброго времени суток.
Есть необходимость разработки ИС для организации со 3хуровневой структурой (головной офис, региональные (20шт) и местные(700 шт) представительства) с численностью потенциальных пользователей порядка 15 000. Совокупный объем данных порядка 400-500 Гб. Планируется следующая связка MS SQL 2005+IIS6.0+.Net+IE 6.0(тонкий клиент). Каналы от представительств до головного офиса 128/64-512/256 Кбит. БД будет разбита на 2 отдельных СУБД-сервера по функционалу (распределение данных 40% - 60%, репликация связующей части). Первая БД - 10 %пользователей, массовые вставки (импорт), мало CRUID-операций, отчеты. Вторая БД - оставшаяся часть пользователей, много CRUID-операций, регламентные "тяжелые" расчетные операции вовлекающие от 30 до 80 % процентов данных.
В связи с вышеописанным безобразием :) вопросы:
1. Есть ли примеры таких внедрений (ссылки, если можно).
2. Жизнеспособность выбранного решения.
3. Вобщем-то любые комментарии по теме :)
Спасибо.

Petro1231 БД - OLTP
2 БД - OLAP (денормализованная)...
Беспокоит не будет ли маловато одной БД(сервера? "размазанной" по нескольким серверам?) для таких нагрузок.


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

basВообще стандартное решение...
попробую погуглить именно в этом направлении.

basЕсли еще удасться и функционал разбить м/у двумя БД серверами, то вообще сказка будет ...
Хотелось бы соблюсти баланс между удобством разработки(отсутствия необходимости настройки репликации и поддержки ее работоспособности/схема данных будет меняться достаточно часто в силу специфики работы организации/) и быстродействия(сложно спрогнозировать поведение системы при планируемых нагрузках). Рассматриваются варианты выделения отдельного сервера под архивные данные(данные ушли и больше не используются), под "рассчеты"(данные перекачиваются на выделенный сервер, там происходят расчеты, результаты расчетов передаются обратно), выделенного отчетного сервера.

PVP Это еще одна проблема. Их же надо будет всех запустить в работу, обучить, потом исправлять глюки и, наконец, сопровождать. Надо обязательно продумать технологию ввода в эксплуатацию и последующего сопровождения.
Внедрение - это отдельная головная боль :) Планируется использовать веб-клиент(уменьшение проблематичности развертывания, невозможность доступа напрямую к БД на местах) + централизованная БД (уменьшение проблем с обновлением системы, отсутствие необходимости обмениваться данными с центральной БД).

PVPТоже, как с ней работать ... Мало ли что может случиться.
Вот потому и хотелось бы узнать о примерах внедрений для выбранных технологий/архитектуры.

Petro123 скока будет в граммах? (например активных транзакций в секунду?)
А то можно и ОДНИМ БД обойтись теоретически.

Точно оценить сложно. Приблизительно 60-100, хотя реально может быть и на порядок больше.