Добрый всем день.

Я сейчас разрабатываю структуры хранилища данных под SQL Server 2005.
Планируется очень большая нагрузка до 3.000 транзакций с сек.
Или до 30.000 батчей в секунду, если дальше разложить на логические операции.
Запросы не тяжелые, но очень много (работа с точечными записями и не большими наборами).
Размер базы огромен ~ 1-10TB (VLDB).
Это полностью интерактивный web-проект.
Из-за чего решать вопрос отчетными "Off-Line" серверами нельзя, данные должны быть актуальными всегда с минимальной задержкой (1/10 - запись/чтение).

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

Самый простой, но дорогой и топорный вариант - купить мега сервер (с кучей CPU),
но я оставляю это на последний случай.

Можете что либо порекомендовать по этому поводу?
Или у кого то уже были случаи реализации подобных проектов?
С какой стороны лучше зайти, что бы не промахнутся?

Заранее спасибо за совет.

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

Если есть, что сказать, то говорите по существу.
А так зачем этоа грязь?
Все принципиальные приемы к данному подходу мне известны.
Интересует каковы особенности следует учесть при проектировании, что бы получить максимум масштабируемости, какие пути возможны, но не желательны из-за проблем.
Простой пример - завязываться на репликацию данных при синхронизации больших объемов, есть самоубийство, из-за вытекающих проблем поддержки и т.д.
Я говорю о концептуальном подходе.

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

to bas.

Количество пользовательских запросов, как я и говорил 3.000.
На уровне базы все это раскладывается до 30.000 батчей.
Задержка между чтением и записью минимальна, секунды.
Железо хорошее, деньги есть.
Количество информации для получения небольшое, но невозможно предсказать ее распределение по базе.
Разработка C# + SQL Server 2005
Соотношение записи к чтению 1/10
Основная концепия системы - добавили объект, он сразу же учавствует в выборках наборов данных (+ сортировка, пейджинг и т.д.).

Думаю над возможностью логического разделения контента на разные сервера, для обеспечения масштабируемости. Но возникают проблемы целостности, так как данные могут быть перекрестно связанными друг с другом (так сказать логические связи объектов).
Маячит супер сервер, с дополнительными серверами, реалезующими только чтение данных, дублируемое зеркалированием при помощи SQL Server 2005.

to guest_20040621 - респект, ничего не скажешь.
Вы ничего не ответили! И не юлите, делая важный вид.

Софтинка не на коленке. Работает группа разработчиков и проектирвщиков.

Меня конкретно интересовал опыт народа по выбору СТРАТЕГИИ распределенного хранения информации, для горизонтального увеличения мощности.

Если нечего сказать - молчите.
Что тут еще добавить?
Нечего.

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

to guest_20040621
как может быть вопрос закрыт, если мы и не начали его обсуждать?

Ваши разговоры лежат в совершенно иной плоскости, в отличие от моего вопроса.
Не понятно, зачем вы лезите с аппраратной стороны? Это все равно, что чесать левое ухо правой рукой, через голову...

> Пока Ваша задача видится мне
Только не надо фантазировать на тему, что там видится. Я же четко сказал - распределенное хранилище, с такой то нагрузкой.
И не закладываясь изначально на возможность горизонтального масштабирования, вы получите полный зад при увеличении нагрузки, так что не надо тут говорить, что нужно для начала, а что нет. Вы предлагаете совершенно тупой, топорный подход.

> Попрошу воздержаться от указаний, что мне делать
Я не указываю вам, а рекомендую сделать розумный выбор.
Знаете выражение - "на нет и суда нет"?
То-то же.


Из общения с вами guest_20040621, я вообще ничего вынести не могу,
так что хватит заниматься демагогией.

to bas

нагрузка со стороны Application 3.000 релоадов web-страниц.
на стороне SQL Server все это раскладывается в 30.000 транзакций.

Соотношение записи к чтению 1/10
Запись делится 50/50 вставка/обновление

Железо планирую от IBM, G3 сервера (x450), хорошая вертикальная масштабируемость. Имел опыт работы с ними - строил Failover кластер из 2-х серверов по 8 CPU в каждом, с возможностью еще наращивать. + SAN от HDS или EMC с хороше проработаной конфигурацией.

С индексами проблем не будет, опыт есть большой.

Выбор платформы сделан руководством и до меня (C# + SQL Server 2005 + Windows), так что это не вопрос. Хотя проектировать я могу и под nix системы, но не вижу принципиальных преград в построении большой системы на Win.

Процес изменения данных в базе таков:
Имеем портал развлекательного характера, в котором добовляются новости и подобного рода информация. Пользователи эти новости (объекты) могут коментировать + работать с ними на основе так называемых "Тегов", привязывать последнии к объектам, производить по ним поиск.
5% всех запросов к хранилищу, это вставка объектов + 5% это обновление счетчиков тех же объектов.
Все остальное, это выборка точечных объектов (70% запросов) + выбор наборов данных (20% запросов).

Что бы погасить нагрузку на SQL Server - разработывается кеш объектов на Application, но он сможет гасить только запросы на точечные объекты, которые простые, но их очень много (70% от всех запросов). (2/3 планируем гасить кешем из запросов на точечный объект).
В итоге остается выборка наборов, которую не за кешируеш.
Из за этого и планирую горизонтыльно масштабировать нагрузку.

Данные часто одни и те же требуются, так что кеширование данных будет:
1. со стороны SAN контроллеров (4GB на контроллер (разные контроллеры под разрые типы данных (текст, image ...)))
2. со стороны SQL Server (16GB и более)
3. со стороны Application (16GB и более)
80% всех запросов в сутки, это работа с одними и теме же данными,
но 20% из них могут быть по любому контенту и все, что есть. Постепенно появляются новые объекты, и фокус данных перемещается на них.
Скользащее окно, зависимое от времени построить невозможно.

Мощность основных таблиц большая - 1.000.000.000 и более, но основной объем базы дают не они, а текставая и бинарная информация, хранение которой будет выделено.

Думаю, что ответил на вопросы, которые задавал bas.

Задача осложнена тем, что очень сложно или практически не возможно логически разделить данные, так как совершенно разные по хорактеру объекны могут быть связаны друг с другом связями "многие ко многим".
В результате, если не получится раздалить данные, будем тиражировать последнии на "читающие" сервера, которые можно подбрасывать в NLB кластеры как в топку (но будем иметь небольшую задержку в обновлении данных).

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

Я так и планирую.
Будет 1 точка входа информации (пишущий сервер)
и несколько точек выхода (читающие сервера)

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

С распределенными транзакциями то же думаю не стоит завязываться,
увельчится общее время вставки.
Попробую использовать зеркалирования при помощи средств SQL Server 2005.
Правда будет небольшая задержка в тиражировании данных.

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

Да.
Вот, сейчас думаю над этим.
Как будут новости - напишу.