무엇을 먼저, 언제 다시

불가능합니다. 계산해 보면 예산의 세 배가 필요합니다.

보관 30억 페이지를 월 1회면 월 30억 번의 가져오기
예산은 월 10억 페이지
신규를 하나도 안 가져와도 부족하다

그래서 "모든 페이지를 주기적으로 갱신한다" 는 요구는 성립하지 않습니다. 계산해서 그것을 밝히는 것이 설계자의 일입니다.

대신 예산을 신규와 재방문으로 나누고, 재방문 안에서도 자주 바뀌는 것에 몰아 줍니다.

흔한 실수: 요구사항을 그대로 받아 설계를 시작하는 것. 숫자를 곱해 보면 불가능한 요구가 섞여 있는 경우가 있고, 그것을 먼저 말해야 나머지 설계가 의미를 갖습니다.

다시 가져와서 비교하고, 결과에 따라 간격을 조절합니다.

얼마나 자주 바뀌는지는 미리 알 수 없습니다.

바뀌지 않았다: 다음에는 더 늦게 본다
바뀌었다: 다음에는 더 일찍 본다

이렇게 하면 자주 바뀌는 페이지가 저절로 자주 방문되고 죽은 페이지는 저절로 잊힙니다. 관찰이 정책을 만드는 구조입니다.

그리고 바뀌지 않았다는 응답을 받으면 내용을 받지 않으므로 예산을 거의 쓰지 않고 확인할 수 있습니다.

흔한 실수: 페이지 종류로 간격을 고정하는 것. 뉴스라고 다 자주 바뀌지 않고 오래된 기사는 그대로입니다. 관찰이 분류보다 정확합니다.

여러 신호를 섞어 정합니다. 한 신호에만 의존하지 않습니다.

링크 수만 보면 서로 링크를 걸어 순위를 올리는 방식에 속습니다. 깊이만 보면 깊은 곳의 좋은 내용을 놓칩니다.

흔한 실수: 하나의 점수로 모든 것을 정리하려는 것. 점수를 만들려면 신호마다 가중치가 필요하고, 그 가중치를 정할 근거가 없으면 숫자에 근거가 없는 것을 감추는 셈입니다. 신호를 나눠 두면 어느 신호 때문인지 볼 수 있습니다.

두 층으로 나눕니다. 우선순위는 어느 큐를 채울지, 예의는 꺼내는 속도를 정합니다.

중요한 페이지가 한 호스트에 몰려 있으면 우선순위대로 가져오려 해도 초당 한 번씩만 가능합니다.

우선순위: 어느 호스트 큐에 주소를 넣을지 정한다
예의: 그 큐에서 꺼내는 간격을 정한다

두 층으로 나누면 서로를 방해하지 않습니다. 우선순위가 높아도 그 호스트에서 나오는 속도는 규칙이 정합니다.

흔한 실수: 우선순위를 지키려고 예의를 어기는 것. 그 호스트가 우리를 막으면 그 중요한 페이지들을 영구히 못 봅니다. 급한 것을 위해 자산을 잃는 선택입니다.