방문할 목록 관리하기

이미 본 주소를 걸러내는 것입니다.

페이지 하나에서 주소 수십 개가 나오고 대부분은 이미 본 것입니다. 사이트 안에서 서로 링크하기 때문입니다.

월 10억 페이지 을 가져오면 발견 주소는 그보다 훨씬 많다
걸러내지 않으면 목록이 먼저 터진다

그래서 목록 관리의 핵심은 담는 것이 아니라 본 것을 기억하는 것입니다.

흔한 실수: 목록 크기를 저장 용량 문제로만 보는 것. 용량도 문제지만 같은 페이지를 반복해 가져오는 것이 예산 낭비입니다. 예산이 정해진 설계에서 그 낭비가 곧 못 본 페이지가 됩니다.

값싼 판정 장치를 앞에 두고 지문만 담습니다.

"없다" 고 하면 확실히 없으므로 새 주소로 처리하면 됩니다. 드물게 틀리면 이미 본 주소를 한 번 더 가져올 뿐이고 놓치는 주소는 없습니다.

이 비대칭은 키-값 저장소의 읽기 경로에서 쓴 것과 같습니다.

흔한 실수: 틀릴 수 있다는 이유로 이 장치를 쓰지 않는 것. 어느 방향으로 틀리는지가 중요합니다. 한 번 더 가져오는 것은 예산을 조금 쓰는 일이고, 놓치는 것과는 무게가 다릅니다.

추적용 매개변수는 버리고 의미 있는 질의는 남깁니다.

같은 페이지를 가리키는 주소가 여러 형태로 나옵니다. 끝의 빗금, 대소문자, 순서가 다른 질의 문자열이 그렇습니다.

다 버리면 실제로 다른 페이지를 하나로 취급한다
하나도 안 버리면 같은 페이지가 수백 개로 늘어난다

어디까지가 판단이고 정답이 없습니다. 그래서 규칙을 기록해 두고, 목록이 부푸는 원인을 볼 때 그 규칙을 조정합니다.

흔한 실수: 정규화를 한 번 정하고 끝내는 것. 사이트마다 매개변수를 다르게 쓰므로 새로운 부풀림 패턴이 계속 나타납니다. 목록에서 같은 호스트의 주소가 급증하는 것을 지표로 보면 그 패턴을 찾을 수 있습니다.

앞부분만 메모리에 두고 나머지는 디스크에 둡니다.

순서대로 읽고 쓰므로 디스크에 유리한 접근이 됩니다. 키-값 저장소에서 본 순차 쓰기의 이유와 같습니다.

그리고 목록은 크롤 결과보다 더 중요하게 지킵니다. 페이지는 다시 가져올 수 있지만 목록을 잃으면 어디까지 했는지를 잃고, 이미 가져온 것을 또 가져오게 됩니다.

흔한 실수: 목록을 임시 자료로 다루는 것. 재시작할 때 비면 예산이 낭비되고, 그 낭비는 못 본 새 페이지로 나타납니다. 눈에 보이지 않는 손실이라 더 위험합니다.