Недавно я услышал, что кто-то предположил, что у трекера RT-запросов могут быть проблемы с масштабируемостью из-за ненормализованной базы данных (кто-то на встрече Perl, на которую я пошел, назвал его в положительном свете гипер-нормализованным, но я думаю, что он, возможно, неправильно понял, что такое нормализация это все о). С другой стороны, я знаю, что крупные предприятия, такие как CPAN Perl, используют RT. Требует ли этот уровень масштабирования специальных мер, чтобы справиться с тем, что происходит, когда db становится слишком большим? Какой у вас был опыт?
Я работал в компании, у которой были сотни тысяч заявок в RT, и до того, как был введен жесткий спам-фильтр, я добавлял несколько тысяч новых заявок в день только из-за спама.
Хотя находясь на коробке, которая по сегодняшним меркам древний (Класс P4) у него никогда не было проблем с производительностью. В основном это связано с использованием правильно управляемого Postgres в качестве бэкэнда, MySQL работает нормально, но RT просто лучше оптимизирован для него.
Вы можете сказать RT удалить старые билеты, но это уничтожает данные и пустая трата времени ИМХО.
Насколько загружен, по вашему мнению, трекер ошибок? Я подозреваю, что рабочий набор относительно невелик и должен легко кэшироваться БД.
Единственные сообщения о проблемах масштабирования RT, которые я могу найти, относятся к 2003 году и только в поиске. Основными пользователями RT, вероятно, будет электронная почта, которая должна быть относительно легкой по сравнению со случайными поисковыми запросами в БД.