Помощь в выборе горизонтально масштабируемого решения SQL Server 2008 (репликация,)

В настоящее время я пересекаю джунгли технологий горизонтального масштабирования SQL Server, таких как репликация, доставка журналов, зеркалирование ... У меня есть следующие ограничения на мой выбор:

  • I want the read-only load to be spread accross the primary and the secondary (mirror, subscriber) server
    • Write load can be sent directly to the primary server
    • Решение практически не требует обслуживания. Изменения схемы должны просто реплицироваться на вторичный сервер (внимание: репликация здесь имеет некоторые серьезные ограничения, как кажется)
    • Записанные данные должны быть доступны очень быстро (менее 1 с, но лучше было бы мгновенно) на вторичном сервере.
    • В случае сбоя сервера я легко могу допустить потерю данных до одного часа. Меня больше волнует простая масштабируемость

Вот несколько вариантов того, что я мог бы выбрать: http://msdn.microsoft.com/en-us/library/bb510414.aspx. Есть какой-нибудь опыт, которым вы могли бы поделиться?


sql-server sql-server-2008 replication log-shipping mirroring
person usr    schedule 03.06.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Все это решения высокой доступности, а не горизонтального масштабирования. У SQL Server нет простого решения для горизонтального масштабирования, как и у других (реляционных) баз данных. Использование репликации «ведущий-ведомый» масштабируется настолько, насколько позволяет возможность масштабирования при записи ведущего устройства. Использование репликации мастер-мастер мультиплексирует записи и вызывает проблемы с согласованностью. Почти все крупномасштабные развертывания, в которых были попытки решения на основе репликации, были вынуждены отказаться от этого.

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

Другой альтернативой является отказ от некоторых ограничений (согласованность записи, согласованность чтения, возможность восстановления, типизированные схемы, ссылочная целостность) и выбор механизма nosql, который может свободно масштабироваться после освобождения от этих ограничений (Cassandra, HBase, MongoDB).

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

person Remus Rusanu    schedule 03.06.2010
comment
Да, я думаю, что ваш последний абзац применим к нам, потому что мы могли бы купить сервер побольше. Однако меня беспокоила стоимость, потому что эти большие серверы стоили много денег ... Репликация сделала бы переход на более крупную систему (в настоящее время 1 маленький сервер) дешевле, я думаю, но хлопоты могут не стоить усилий. Модель нашей предметной области чрезвычайно разнообразна и реляционна. Множество таблиц и ограничений. - person usr; 03.06.2010