Однако у меня есть несколько вопросов по этому поводу:
Есть ли более новый способ сделать это?
Если я хочу закрывать темы на основе даты последнего действия (а не даты создания), есть ли переменная, которую можно использовать вместо created_at?
Можно ли как-то исключить личные сообщения из закрытия? Я запустил запрос в тестовой среде и заметил, что он затронул все темы, независимо от того, были ли они публичными или приватными; мы хотели бы по возможности исключить личные сообщения.
На нашем форуме почти 16 лет контента, импортированного из нашего предыдущего решения. Что касается времени выполнения запроса: (a) как мы можем определить, сколько времени потребуется для его выполнения, и (b) лучше ли разбить его на части (например, выполнить для всего до 2010 года, затем для 2011, 2012 и так далее, пока не дойдем до 2023 года) или просто запустить его как один запрос?
Просто хочу убедиться (особенно в пункте 4), что мы не окажем слишком сильного влияния на производительность системы. Я знаю, что многое зависит от оборудования, на котором мы работаем (а я даже не знаю, какое именно, так как у нас есть команда инфраструктуры, которая занимается установкой и обслуживанием всего оборудования).
По поводу пункта #2: с помощью плагина Data Explorer (о котором я ранее не знал) кажется, что updated_at — это, вероятно, значение, соответствующее «временной метке последнего ответа». Правильно ли я понимаю?
Спасибо за эту подсказку — она, думаю, очень полезна для моих первых трёх вопросов. Буду признателен за разъяснения по поводу updated_at и планирую работать с нашей расширенной историей сообщений и тем.
Однозначно стоит сначала протестировать небольшую партию. Я, э-э, уже однажды из-за массовых действий «положил» сайт сообщества и пожалел, что не протестировал подмножество данных заранее.
Спасибо — я так и думал, что это может быть так. Хорошо получить подтверждение по выбранному подходу.
Думаю, я попробую восстановить одну из последних резервных копий и настроить изолированную песочницу отдельно от тестовой среды. Не уверен, как в такой конфигурации будет работать компонент SSO, но было бы полезно оценить производительность, прежде чем применять изменения к рабочей системе.
Отмечу, что если у вас особенно активное сообщество, тестовый сайт не будет полностью имитировать рабочую среду, так как помимо массовых действий есть влияние от органического использования сайта пользователями.
Определённо — спасибо за указание на пост о тестовом сервере, это тоже будет весьма полезно.
Да, нагрузка пользователей, скорее всего, не станет большой проблемой — похоже, что среднее количество просмотров страниц в день составляет около 50 тысяч по всем категориям (краулеры, анонимные и зарегистрированные пользователи). Понимание потенциального увеличения нагрузки по сравнению с текущей будет полезно для планирования.
В итоге я настроил тестовый сервер (на самом деле это было довольно просто — просто восстановил резервную копию из продакшена и вошёл через процедуру восстановления администратора, так как система настроена только на OIDC). Похоже, у нас около 160 тысяч тем, и быстрый тест только по одной категории с примерно 7500 темами занял 6 минут на моей тестовой системе — значит, на все темы уйдёт около 2 часов. Влияние на производительность системы (мониторилось через htop) здесь оказалось практически незаметным.
Уверен, мы найдём период низкой нагрузки, когда можно будет запустить команду rake, и при желании можем обрабатывать группы категорий по очереди — это будет работать у нас очень хорошо.
Огромное спасибо за все советы и помощь — за последние пару дней я многому научился в этой платформе благодаря этому.
