캐시가 반대 방향으로 커질 때

이 서비스의 캐시 폴더에 작은 파일 넷이 있습니다. 가장 큰 것이 35바이트입니다. 합쳐서 카운터 번호 셋을 담고 있고, 모든 카운터 요청마다 읽힙니다.

계수 경로가 데이터베이스에 거의 언제나 "아니오"로 답하는 물음 넷을 던지지 않아도 되도록 존재합니다. 이 카운터는 주인 자신의 방문을 제외하는가? 나가는 클릭을 따라가는가? 사이트를 지나는 경로를 따라가는가? 스스로 다시 불러오는가? 카운터의 99% 이상에서 답은 모두 아니오이고, 답이 예인 몇 안 되는 번호를 담은 파일 하나를 보는 편이 인덱스 조회 넷보다 쌉니다.

쌉니다. 그리고 그것은 뒤집히는 종류의 쌈입니다.

무엇을 쟀는가

같은 물음 — "이 카운터가 목록에 있는가?" — 을 두 방식으로, 여섯 가지 목록 크기에서 던졌습니다. 파일 방식: 읽고, JSON을 풀고, 번호를 찾습니다. 데이터베이스 방식: 인덱스가 있는 칸에 대한 준비된 문 하나입니다. 각각 이천 번씩, 다섯 차례, 중앙값을 취했습니다.

오늘 크기에서는 파일이 여덟 배로 이깁니다. 0.0202밀리초 대 0.1630입니다. 번호 천 개에서 둘은 같아집니다. 만 개에서 파일은 열두 배 더 들고, 십만 개에서는 135배 더 듭니다. 그때쯤이면 조회마다 읽고 풀어야 할 것이 578킬로바이트이기 때문입니다.

데이터베이스 선은 움직이지 않습니다. 두 줄에서 0.16밀리초이고 십만 줄에서 0.16밀리초입니다. 인덱스는 그것을 위한 것이고, 저 선이 얼마나 지루해 보이는지 뒤에 얼마나 많은 일이 숨어 있는지는 잊기 쉽습니다.

불편한 대목

교차점은 번호 100개와 1,000개 사이 어딘가입니다. 이 서비스에는 지난 서른 날에 활동한 카운터가 2,218개 있습니다.

그러니 제외 기능이 성공한다면 — 카운터를 가진 모두가 "내 방문은 세지 마라"를 켠다면 — 파일은 번호 2,218개를 담고 11킬로바이트가 되며 조회마다 0.02가 아니라 0.43밀리초가 듭니다. 어제의 18,423건에서 그것은 3초면 되었을 조회를 피하려고 하루 8초의 일을 하는 셈입니다.

이 최적화는 기능이 가장 적게 쓰일 때 가장 빠릅니다. 느린 조회처럼 부하와 함께 서서히 나빠지지 않습니다. 채택과 함께 나빠지고, 그것은 아무도 지켜보지 않는 축입니다. 채택이 오르는 것은 좋은 소식이어야 하기 때문입니다.

왜 아직 거기 있는가

오늘 옳기 때문이고, "오늘 옳다"는 무언가의 까닭이 되어도 됩니다. 그것이 언제 참이기를 그치는지 누군가 적어 두기만 한다면 말입니다.

파일 셋에 번호 셋. 계수 경로가 유일하게 빨라야 하는 기계에서 대안보다 여덟 배 쌉니다. 지금 그것을 이기고 있는 조회로 바꾸는 것은 가정을 근거로 더 나쁜 시스템을 만드는 일입니다.

필요한 것은 다시 쓰기가 아니라 걸림줄입니다. 파일은 어차피 설정을 바꾸는 코드가 데이터베이스에서 씁니다 — 목록이 수백 항목을 넘겼다는 것을 알아채고 말해 줄 자연스러운 자리가 그곳입니다. 천장이 적힌 캐시는 결정입니다. 천장이 없는 캐시는 아무도 동의하지 않은 내기입니다.

일반적인 모양

이것은 파일에 캐시하는 것에 반대하는 논거가 아닙니다. 캐시가 어느 방향으로 커지는지 알아야 한다는 논거입니다.

대부분의 캐시는 부하와 함께 좋아집니다. 요청이 늘고, 적중이 늘고, 비율이 좋아집니다. 이것은 다른 종류입니다. 요청당 비용이 담고 있는 데이터 양의 함수이고, 담는 것은 서비스가 북돋우려는 바로 그것과 함께 늘어납니다. 읽을 때마다 모든 항목의 값을 치릅니다. 지금 세어지는 방문자와 아무 상관 없는 2,215개까지 말입니다.

메모리나 파일에 든 조회표에 던져야 할 물음은 "얼마나 빠른가"가 아니라 "무엇이 이것을 자라게 하고, 그것이 잘되면 어떻게 되는가"입니다. 답이 "느려집니다"라면, 크기 한도는 만드는 날에, 파일을 쓰는 코드 옆에, 코드 안에 들어가야 합니다.