Справка по выбору решения для масштабирования SQL Server 2008 (репликация, ...) - PullRequest
Новая
       55

Справка по выбору решения для масштабирования SQL Server 2008 (репликация, ...)

5 голосов
/ 03 июня 2010

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

  • Я хочу, чтобы нагрузка только для чтения распределялась по первичному и вторичному (зеркальному, абонентскому) серверу.
    • Загрузка записи может быть отправлена ​​непосредственно на основной сервер
    • Решение должно быть практически без обслуживания. Изменения схемы должны просто реплицироваться на вторичный сервер (внимание: репликация имеет некоторые серьезные ограничения здесь, как кажется)
    • Письменные данные должны быть доступны очень быстро (менее 1 с, но лучше бы мгновенно) на вторичном сервере
    • При сбое сервера я могу легко потерять до одного часа потери данных. Меня больше волнует легкая масштабируемость

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

1 Ответ

5 голосов
/ 03 июня 2010

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

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

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

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

...