FreeBardВсем доброго времени суток!

На собеседовании задали вопрос - какие есть особенности проектирования и создания базы под очень большие объемы данных.
Не нашелся что ответить.
Кто в теме, просветите по вопросу на будущее..)
Интересуют ответы и со стороны dba и со стороны разработчика
Со стороны разработчика - активное использование секционирования больших таблиц и файловых групп.
Со стороны DBA - раскладка "архивных" секций крупных таблиц на диски HDD и "свежих" секций на диски SSD, отдельный том (и LUN на дисковой полке) для журнала транзакций, отдельный том под tempdb (самый скоростной), выбивание из руководства бюджета на лицензии SQL Enterprise Edition, подготовка AlwaysOn AvGroups или отказоустойчивого кластера (FCI), регулярное чтение MSDN и согласованное с разработчиками накатывание свежих SP и CU, разворачивание мониторинга с отрисовкой важных показателей, согласованных с разработчиками, на дашбордах и предоставление доступа к ним для разработчиков и службы Service Desk.

Внимательная настройка совместно с разработчиками Resource Governor и разделение всех пользователей такой крупной БД на группы с различным приоритетом доступа к ресурсам сервера.

Для DBA - мониторинг свободного места на томах со всеми файлами БД, включая служебные базы инстанса MSSQL, и рассылка регулярных почтовых уведомлений, в том числе разработчикам (не все смотрят дашборды, а служебную почту читают все).

FreeBardособенности проектирования и создания базы под очень большие объемы данных.

Поскольку наверняка такая БД будет в группе AlwaysOn - нужно будет заранее продумать, кому к каким репликам давать доступ. И самое главное - минимизировать использование триггеров (потом скажете спасибо еще не один раз).

a_voroninFreeBardВсем доброго времени суток!

На собеседовании задали вопрос - какие есть особенности проектирования и создания базы под очень большие объемы данных.
Не нашелся что ответить.
Кто в теме, просветите по вопросу на будущее..)
Интересуют ответы и со стороны dba и со стороны разработчика

Если речь идет о OLTP, то смотрите в сторону Микросервесной архитекруты,
если речь о ХД смотрите в сторону Data Vault и Anchor Model

И такие вещи как партиционирование, колоночные индексы становятся актуальными

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