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

Репликация менее ресурсоемка, чем высокочастотное чтение?

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

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

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

У меня вопрос:

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

Кроме того, не повлияет ли на производительность ведомого устройства репликация транзакций, как если бы в него производилась запись?

В общем, кажется, что количество операций умножается за счет внедрения репликации.

например

Мне кажется, что любая выгода, полученная от добавления дополнительного сервера, будет потеряна при добавлении дополнительного процесса чтения и записи.

Я смотрю на это слишком упрощенно? или я что-то упускаю?

Спасибо

Репликация SQL Server на стороне издателя осуществляется через приложение, которое считывает данные непосредственно из журнала транзакций, а не из реальных таблиц базы данных SQL Server.

На стороне подписчика данные записываются в SQL Server построчно через хранимые процедуры (по умолчанию).

Я управляю некоторыми ОЧЕНЬ большими приложениями, которым не нужно выгружать операции чтения на другой SQL Server. Есть очень небольшое количество приложений, которые действительно необходимо масштабировать. В 99% случаев простая настройка правильной индексации и правильное проектирование сервера и хранилища будут обрабатывать огромные рабочие нагрузки, если был приобретен достаточно большой сервер.