Я собираюсь увеличить нашу базу данных sql2008. Просто. Но мне может потребоваться масштабировать наши базы данных sql.
Для простой ситуации горизонтального масштабирования (т. Е. Распределения нагрузки обработки) есть ли какие-то хорошие начальные передовые практики? Я знаю, что существует так много решений, которые будут зависеть от продукта -> много операций записи и не так много операций чтения, много операций чтения и немного операций записи, и то и другое, и т. д.
Но есть ли общая отправная точка для сайта, который довольно много читается (вместо того, чтобы писать)? например. возьмите вторую коробку sql, добавьте немного синхронизации и вперед.
Насколько актуальными должны быть данные на других ящиках?
MSSQL имеет отличную настройку односторонней синхронизации. У вас должна быть лицензия на соответствующие версии SQL Server (я не думаю, что он включен в самую базовую версию), но его очень легко настроить.
Единственная загвоздка в том, что вы можете писать только в одно место, все остальные должны быть доступны только для чтения. Для двусторонней синхронизации (если вы вообще собираетесь писать) все намного сложнее.
Короче говоря, да, второй ящик с синхронизацией будет работать достаточно хорошо, но вам также нужно будет выполнить собственную балансировку нагрузки (т.е. пусть один веб-сервер читает один сервер sql, другой веб-сервер читает другой сервер sql), поскольку они по-прежнему появляются как отдельные экземпляры. В противном случае вы попадете в кластеры, что является еще одной рыбой.
Итак, эта штука для синхронизации - что это такое и как ее настроить? Итак, в вашей SQL Management Studio (SSMS) вы увидите папку «Репликация» на панели навигации с публикациями и подписками.
Вкратце, вы:
Там много статей, так что просто Google SQL Server Replication.
Что касается аппаратного обеспечения, наш основной сервер db - это двухъядерный четырехъядерный процессор с 4 ГБ оперативной памяти. Наши ведомые устройства двухъядерные с 4 ГБ оперативной памяти. На этом уровне можно купить много серверов. Конечно, все зависит от того, какую нагрузку вы ожидаете.
вопрос сложнее, на него можно ответить в нескольких сообщениях. Существует слишком много вариантов масштабирования серверов, и это лишь некоторые из них: отказоустойчивый кластер, доставка журналов, репликация, зеркальное отображение базы данных.
Я бы порекомендовал вам замечательную книгу, которую можно скачать здесь: Pro SQL Server 2005 Высокая доступность
Надеюсь, вы найдете там ответы на свои вопросы
В наши дни оборудование довольно мощное и дешевое, поэтому вы можете пройти долгий путь, просто используя приличный сервер. Если, как вы говорите, ваша база данных предназначена в основном для чтения, то Poweredge 2950 с 16 ГБ ОЗУ и шестью дисками RAID5 по 15 КБ (или 6) является очень мощной базой для SQL Server; добавьте столько ядер, сколько хотите, но даже двухъядерные четырехъядерные не так уж дороги. Я думаю, что 2950 потребует до 64 ГБ ОЗУ, хотя это будет дорого!
Ваше оборудование уже может быть таким мощным. Если это так, вы ожидаете ступенчатого изменения мощности и стоимости, и если да, я думаю, вам нужен лучший совет, чем просто несколько сообщений на ServerFault :-)
JR
ну, на этот вопрос сложно ответить в том смысле, что вы (разработчики) должны были думать об этой проблеме при проектировании базы данных. Но взгляните на общие базы данных на предмет высокого соотношения чтения / записи, которое может быть проще всего реализовать. Другим решением может быть репликация.
наслаждайся, м