Пакетное обновление базы данных.

Зависит от того с чего у тебя идёт нагрузка и как часто ты обновляешь данные в базе. Если ты редко заливаешь на сервер большие объёмы данных и часто запрашиваешь (при этом время заливки тебя не беспокоит критически), то 2 сервера норм смотрятся. Если критично, то тут уже надо думать исходя из того что за базы у тебя и какие нагрузки. Может там вообще надо уже кластер разворачивать и настраивать синхронизацию и перераспределение запросов между серверами.

Я бы master и slave сервера поднял и между ними нагрузку балансил, если есть такая возможность.

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

Из обновления сотен тысяч записей не следует автоматически изменение производительности сервера.

наверняка есть стандартное решение для данной ситуации

Во-первых, нет, во-вторых, ты даже ситуацию не описал. В чём затык-то? В локах? В CPU? В IO? Какие требования к атомарности этой пачки? Решений куча. К сожалению, по MySQL у меня мало опыта, такого рода процесс в постгресе с десятками миллионов изменений у меня на производительности никак не сказывается, но очевидные общие решения это

• троттлить обновления (если не нужна атомарность)
• ввести поколения данных

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

А что именнт тупит то? Индексы? Ключи? Хранилище?

обновляются сотни тысяч записей

всего-лишь?

наверняка есть стандартное решение для данной ситуации

которой ситуации-то?

ну ум приходит

не всем. а только лишь

как всегда на лорчике и подобных васянофорумах люди кИдаются отвечать «по-существу» на абсолютно долбоносное описание какой-то сферической ситуации в вакууме… На perlmonks для сравнения послали бы подальше (вежливо, потому что это perlmonks).

А так какой вопрос такой и ответ - ТС, купи серверу нормальных ССДешек и «сотни тыщ» апдейтов сделают твою базу мягкой и шелковистой.

/тред