Как Вы справляетесь с большими данными в MS SQL Server?

Question

[Олег Тараканов]

Всем привет!

Наша компания разрабатывает региональные решения для системы образования. Работаем на ASP .NET + MS SQL Server.
Размер БД крупных заказчиков стремительно приближается к 500 GB - через год-два столкнемся с БД размером в 5-10 TB.
Решение в виде "переписать тупой код на Oracle" не подходит, т.к. система реально очень серьёзная и пользуется большим спросом конечного пользователя - работника школы.
Наращивание серверных требований пока срабатывает, но запрос серверов с 1 TB ОЗУ и 8 ЦП выглядит дико, даже для больших регионов (Краснодарский край, Московская область).

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

Answer 1

[Артём Каретников]

Так покажите структуру самых больших таблиц, посмотрим. В сбере у меня была база больше 2 терабайт, но у нас реально куча юзеров и куча транзакций. Терабайт оперативки нужен не был. :)

Comments

[t_q_l]

Ответ помечен, как решение, а в чём его суть?

[Артём Каретников]

Суть в том, что человек обратился ко мне, привел свои реальные данные, схему - мы с ней поработали и все оказалось как обычно: если нормально писать код, а не кривыми руками это делать, то жуткие обьемы оперативки и жесткого диска не нужны.

[Олег Тараканов]

Артем Каретников: Поддерживаю ответ Артема. Очень благодарен за оказанную помощь. Скорость одного из проблемных отчетов выросла в 10 раз!

Answer 2

[Клёвый Админ]

Зачем столько ОЗУ? Какой размер "горячих данных", какой паттерн нагрузки? Почему БД такая "здоровая"? Не хранится ли в ней бинарная информация? Можно ли её поделить на различные БД меньшего размера?

Это и многое другое можно использовать как направления для оптимизации. И что-то мне подсказывает, что хорошее многоуровневое хранение и вытеснение бинарников в отдельное место решит ваши проблемы с БД.

Answer 3

[Илья Т.]

Ничего непонятно из вашего поста. Больше вопросов возникает чем ответов: почему именно терабайт ОЗУ? Чем оракл принципиально для вас лучше ? Какой профиль нагрузки? Какая структура данных? Если нагрузка преимущественно на чтение - нет проблем замасштабироваться горизонтально. Если нагрузка смешанная надо смотреть в сторону оптимизации. Вообще надо брать за уши нормального ДБА и садить его за покурку вашей базы.
5-10 Тб по нынешним временам - нифига не большая база.