Назад | Перейти на главную страницу

Масштабирование SQL-сервера с высокой степенью транзакций

Я хочу обновить один из серверов своего сайта. В настоящее время сайт выполняет около 20 миллионов sql-запросов в день, и этот показатель довольно быстро растет. Сейчас Пропускная способность ввода-вывода - реальная проблема, поэтому моя идея состоит в том, чтобы переместить различные базы данных на их собственные пары дисков. Моя идея - сделать что-то вроде этого:

Конфиг

Диск 1 и диск 2 / Raid 5,6 или 10 (SAS или SSD) - база данных 1

Диск 3 и диск 4 / Raid 5,6 или 10 (SAS или SSD) - база данных 2

Диск 5 и диск 6 / Raid 5,6 или 10 (SAS или SSD) - база данных 3

Диск 7 (SSD) - Журналы транзакций

Диск 8 (SSD) - Журналы транзакций

Мне здесь не хватает опыта, поэтому у меня есть несколько вопросов:

1) Во-первых, выглядит ли вышесказанное глупо?

2) Есть ли что-нибудь, на что я должен обратить внимание в контроллере RAID, например. Пропускная способность при использовании SSD?

3) Все ли SSD-диски созданы равными? Я встречал темы, в которых говорилось, что некоторые типы не соответствуют стандартам?

4) Я предполагаю, что для простых двух зеркал дисков любой из этих уровней RAID подойдет? Плохое предположение?

5) Какие-нибудь другие настройки, чтобы улучшить эту конфигурацию?

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

Спасибо Дэйв

Нет, все SSD не равны. Intel G2 неплохие, а Crucial RealSSD хороши. Тем не менее, лучшая производительность - у карт SSD, которые вставляются в слоты PCI Express. Лучшие из них в настоящее время имеют пропускную способность 1,4 ТБ / с (последовательная).

Общий знаменатель - произвольная пропускная способность записи. Лучше всего это измерить, запустив утилиту Microsoft SQLIO.

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

Не забывайте TempDB, если у вас есть процедуры или запросы, которые его используют.