그동안 며칠에 한번씩 2주이상 지난 백업을 모두 지우고, editlog의 항목도 적절히 삭제하는 식으로 히스토리를 관리했는데(세련되지 않은 스크립트를 써서), 이제 백업 파일 삭제는 고무신님이 제공해주신 스크립트를 쓰도록 하겠습니다. 그리고, 관리의 자동화를 위해서 editlog의 항목도 최근 2000개만 보관하려고 합니다. 이유는 editlog파일이 커지면 RecentChanges가 느려지기 때문입니다. editlog에서 항목이 사라지더라도 백업파일이 남아 있다면 페이지히스토리에서 백업본을 확인할 수 있습니다. 단지, 누가 수정했는지의 정보가 사라집니다(제가 제대로 알고 있는 것이라면). 어떻게 생각하시는지요? 2000이라는 숫자는 그냥 개인적인 감에 의해 선택했습니다; 2000개면 대략 150Kbyte 쯤 될 것 같군요.(지금 editlog가 4500개의 항목에 용량이 350Kbyte정도 됩니다.) --희상
제 생각에는 2000개라는 임의의 숫자보다, "시간에 따른 부패" 메타포를 쓰는 것이 어떨까 합니다. 위키 전체에 유통기한이란 개념이 있습니다. 누군가가 어떤 페이지를 수정합니다. 그 때 해당 페이지의 과거 버젼 중(이제 막 과거 버젼이 될 페이지는 빼고)에 유통기한을 넘는 놈은 자동 삭제 됩니다. 어떤 시점에 있어 유통기한을 넘긴 과거 기록들이 존재합니다. 다만 그 페이지가 수정되는 시점에 "쓰레기 치우기"가 발동합니다. 이걸 editlog에도 적용해서, 유통기한을 넘긴 항목이 있으면 삭제합니다 -- 이건 cronjob으로 주기적으로(예컨대 유통기한 주기로) 처리하는 것이 더 효율적이겠죠. RecentChanges의 속도를 높이려면 editlog를 텍스트파일로 전체 액세스 하지 말고 버클리 디비 등의 레코드(record format file)를 이용하면 될 것입니다.
시간에 따른 부패가 더 좋은 이유는 그 시스템의 사용자들이 이해하고 예측할 수 있기 때문입니다.
유통기한을 넘긴 놈이 즉각적으로 청소되지 않는 것이 좋은 이유는 외부공격이나 사용자의 실수에 더 안정적이기 때문입니다.
--김창준