У меня есть таблица с интенсивным доступом, соответствующая личным сообщениям пользователя, с более чем 10 млн строк. Когда я запускаю процесс удаления пользователя, из таблицы удаляются устаревшие сообщения, обычно более 1000 строк. Проблема возникает, когда эта таблица оптимизируется, потому что это занимает около 1 минуты, в течение которой таблица полностью блокируется, а все запросы задерживаются. То же самое и для других больших таблиц.
Вопрос в том, могу ли я просто оставить таблицу постоянно неоптимизированной без серьезных проблем с производительностью? Или мне следует оптимизировать таблицу хотя бы раз в неделю при низком трафике, чтобы не раздражать моих онлайн-пользователей?
Да, производительность ухудшится, но мы не можем сказать вам, насколько быстро или какой уровень ухудшения является приемлемым, поскольку вы уже делаете это. почему бы тебе не измерить влияние самостоятельно.
Акбер прав, говоря, что использование кластера позволит вам оптимизировать одну систему, в то время как другая по-прежнему обслуживает данные - но почему бы не настроить их как пару мастер-мастер - тогда вам не нужно обновлять и понижать версию при переключении . И нет необходимости записывать временные записи - просто подождите, пока восстановится задержка сервера, а затем переключитесь. Это также действительно хорошее решение для резервного копирования и, конечно же, высокой доступности.
Еще одно решение, уже широко используемое для такого рода упражнений, - это изменение схемы с нулевым временем простоя - я знаю две хорошие реализации: одна написана на Perl от парней из Percona, и один написано на PHP людьми из Facebook.
Я предполагаю, что вы имеете в виду реорганизацию таблиц для удаления места, занимаемого удаленными строками.
Самое простое решение - репликация:
Более сложный вариант этого может использоваться для записи временных записей в другую таблицу на ведомом устройстве и последующего копирования их обратно на ведущее устройство, но это потребует изменений на уровне приложения.
Идеальное решение - иметь очередь записи и таблицы с возможностью записи и только для чтения. Этот шаблон проектирования похож на шаблон, известный как CQRS. Он основан на возможной последовательности, и ваши пользователи могут даже не заметить всплеска. Все транзакции записи в конечном итоге будут записаны в таблицу, но могут быть недоступны сразу, поскольку они удерживаются в очереди, пока записываемая таблица реорганизуется.