Порекомендуйте возможные реализации такой задачи:
есть большая система с одной центральной ДБ (А) и несколькими инстансами ДБ другого типа (B) для накопления и кэширования данных. Сейчас количество баз типа B может быть до 50 и все работает сбалансированно.
Следующая версия должна поддерживать 1000 баз типа B. Поскольку все они ходят в базу A я вижу в этом проблему. Логично было бы поддерживать копии A для нескольких баз типа B. (95% запросов B->A на чтение из пяти таблиц по милиону записей, запросы A->B 100% параллельный вызов процедур).

Какие возможны технологии реализации?

я несколько удивлен отсутсвием реакции ??????
- в моем вопросе много букав и никто не в силах дочитать до конца
- новичкам форума не отвечают в принципе?
- никто никогда не делал репликации?

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

softwarerТо есть в среднем - 11'500 записей в секунду, в пике - порядка 50'000. Боюсь, системе с "центральной БД" при такой нагрузке придется нелегко даже при коротких записях; это конечно существенно зависит от того, из скольких источников и какими порциями приходят данные, но вполне вероятно, я бы сразу задумался о кардинально распределенной системе. Также цифры не очень бьются с основной операцией "чтение из пяти таблиц по миллиону записей" - маловато будет, получается глубина не более получаса.

Совершенно прав. Система изначально распределенная и гибкая. Позволяет переаспределять нагрузку. Центральная база события не получает вообще.

softwarer
Суммируя - вообще-то я сомневаюсь, что задачу таких размеров стоит проектировать в форуме. Далее, я весьма сомневаюсь в целесообразности таскания (с копированием) миллиарда записей по маршруту центральная бд (А) - промежуточные полуцентральные бд (А') - оконечные бд (B); имеет смысл сокращать пути, делать сколь возможно полносвязку (хотя это, конечно, зависит от специфики данных). Возможно, будет иметь смысл промежуточный кэш (то есть, грубо говоря, миллиард записей приходит на A, потоки по сто миллионов приходят на десяток A', оттуда их запрашивают B). Далее - в такой системе я бы ожидал других требований - по надежности-бесперебойности-безопасности-итд, что тоже повлияет на архитектуру и технические решения.

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

softwarer
В общем, не верю я, что сейчас некто ГУРУ коротко и полно раскроет рецепт "как строить подобные системы", тем более сомневаюсь я, что на форуме много людей, не понаслышке знакомых с такой нагрузкой (я, например, к таким не отношусь).
у меня нет опыта построения репликаций тем более в SQL 2005 поэтому пришел за советом.

andsmУ нас имеется подобная система, даже более сложная в плане репликации. Возможные проблемы достаточно очевидные - восстановление репликации после сбоев и первоначальная синхронизация данных. Эти вопросы нужно продумывать еще на стадии дизайна.
у вас SQL 2005?
используете ли вы встроенные средства или что то еще?
почему получаются сбои?
работает ли аддтивный апдейт?
в случае редактирования репликации как работает мердж?
как это работает с транзакциями?

как оно реально работает? Может там еще пять сервисПаков нужно ждать пока на это можно будет полагаться.

модЭтих прямо подключить к ЦБД как клиенты и ничего не реплицировать.
так система сейчас и работает

проблема будет когда тысяча баз типа "B" (сейчас 50) одновременно начнут делать джойны с миллионными таблицами ЦДБ. Распределить такие запросы по времени не возможно "by design"
значит нужно кэшировать сами данные.

ВМоисеев>мод
>N серверов БД собирают события, агрегируют их и записывают в ЦБД ...

Что такое - агрегация?
Нельзя ли передать события (события можно представить SQL предложениями INSERT, UPDATE. DELETE ?) в ЦБД для обработки не агрегируя?

С уважением, Владимир.

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

или мой вопрос не проходит по профилю данного форума или просто нет опытных репликаторов

softwarerЕсли Вам нужна репликация именно в MSSQL2005, резонно спрашивать о ней в форуме по MSSQL, isn't it?

sure
но поскольку я нахожусь на стадии выбора средств и уточнения проблемы мне интересно узнать возможные альтернативы

модНадо сделать так, чтобы базы типа "B" только писали в ЦБД, т.е. только сбор данных, а вся работа на ЦБД.
согласен, только для осуществления этого мне нужно реплицировать интенсивно используемые данные из ЦБД поближе к базам типа "В", причем желательно размножить их.

модА зачем ? 1000 юзеров могут работать на одной ЦБД - вопрос железа. Я так понял, что это в основном отчеты.
половина отчетов, работает на данных из ДБ типа "В". причем они должны джойнить таблицы из ЦБД.

уважаемые softwarer и ВМоисеев пожалуйста откройте отдельную тему для вашей дискуссии, а ВМоисеев попробуйте понять суть проблемы прежде чем давать рекомендации.