Какие объективные факторы указывают на то, что пришло время для репликации SQL Server?

Я пытаюсь найти баланс между высокой производительностью нашей базы данных и простотой обслуживания. Мы рассматриваем возможность использования репликации для повышения производительности путем репликации наших отчетов SSRS в физически отдельную базу данных из нашей транзакционной базы данных. Однако включение репликации имеет ряд недостатков с точки зрения разработчика:

• Это усложняет изменение схемы
• Это мешает нашему автоматизированному серверу интеграции / сборки
• Кажется, это затрудняет реализацию контроля исходного кода SQL

Мой вопрос : когда вы знаете, что пришло время начать репликацию в свете этих недостатков? Как вы решаете, оправдывает ли дополнительная сложность выигрыш?

Мы использовали его раньше, поэтому его настройка не является проблемой. Это больше о принятии решения, чтобы включить или нет, чтобы включить его. Я ищу некоторые показатели производительности объекта, которые другие наблюдали при репликации.

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

Репликация должна быть рассмотрена на этапе разработки приложения. Если у вас есть географически распределенная рабочая сила / база пользователей, может иметь смысл иметь региональные базы данных и центральные базы данных. Отключенные базы данных на ноутбуках могут «синхронизироваться», когда они, наконец, восстанавливают связь с сетью (думают продавцы в дороге).

Что касается отчетности, репликация не является ответом. Большая часть проблем с производительностью в среде отчетов связана с тем, что отчеты пишутся для системы, настроенной для оперативной обработки транзакций (OLTP).

Репликация для целей отчетности - это просто перемещение ваших данных OLTP на другой сервер, но с сохранением той же структуры отчета. По сути, вы тратите больше оборудования на решение этой проблемы и увеличиваете свои расходы на обслуживание, но при этом получаете минимальные выгоды.

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

Следуя этому подходу, вы получите огромные преимущества в производительности.

Мы считаем, что репликация может оказаться полезной в аналогичной ситуации, поскольку разработчики отчетов могут «владеть» индексами в реплицируемой базе данных. Это дало нам возможность повысить производительность запросов, добавив индексы, которые разработчики приложений никогда бы не утвердили в производстве из-за их негативного влияния на INSERTS и UPDATES.

Может быть, частью вашего варианта использования является копирование некоторых транзакционных таблиц, изменение индексации и проверка того, стоит ли это того?

Надеюсь это поможет!