最近我听到有人说 RT 请求跟踪器可能存在可扩展性问题，因为它的数据库不是标准化的（我参加的一次 Perl 会议上，有人正面地称它为超标准化，但我认为他可能误解了标准化的含义）。另一方面，我知道 Perl 的 CPAN 等大型企业使用 RT。这种规模是否需要采取特殊措施来处理数据库过大时发生的情况？您的经验是什么？
答案1
您认为错误跟踪器会有多忙？我怀疑工作集相对较小，应该很容易被数据库缓存。
我能找到的唯一关于 RT 扩展问题的报告来自 2003 年，并且只出现在搜索中。RT 的主要用户可能是电子邮件，与随机 DB 搜索查询相比，电子邮件的使用量相对较小。
答案2
我曾经在一家拥有 RT 中数十万张票的公司工作过，在实施严格的垃圾邮件过滤器之前，仅由于垃圾邮件，每天就会增加数千张新票。
尽管按照今天的标准古老的（P4 级）它从未出现过性能问题。这主要源于使用正确管理的 Postgres 作为后端，MySQL 运行良好，但 RT 针对它进行了更好的优化。
您可以告诉 RT 清除旧票，但这会破坏数据，而且在我看来浪费时间。