인덱스를 더하면 오히려 느려질 때
이 글의 내용
일별 수치 표에는 열쇠가 하나 있습니다. 카운터와 날짜를 함께 묶은 것입니다. 코드의 다섯 자리가 그 표에 다른 물음을 던집니다 — "이 카운터를 시간에 따라"가 아니라 "이 날짜들의 모든 카운터"입니다. 첫 페이지 갤러리, 톱리스트, 사이트맵, 90일 그래프, 그리고 상태 수치입니다. 날짜 칸에 인덱스가 없으면 그 하나하나가 114,113줄을 모두 읽습니다.
그 인덱스를 더하면 갤러리가 열 배 빨라집니다. 더하지 않았습니다. 그렇게 정한 측정을 적습니다.
조회 하나가 훨씬 빨라졌습니다
갤러리는 오늘 활동한 카운터를 청합니다. 날짜에 인덱스가 없으면 표 전체를 훑고, 있으면 날짜 하나를 찾아 443줄을 읽습니다. 61.5밀리초가 6.1이 되었습니다. 미묘한 결과가 아니고, 그것만 쟀다면 인덱스는 지금 데이터베이스에 있었을 것입니다.
조회 둘이 느려졌습니다
사이트맵은 열나흘을 청하고 19% 느려졌습니다. 상태 수치는 한 해를 청하고 10% 느려졌습니다. 두 경우 다 조회 계획기가 기본 열쇠에서 새 인덱스로 갈아타며 더 나쁜 선택을 했습니다.
이 대목은 이해해 둘 값어치가 있습니다. 계획기의 결함이 아니기 때문입니다. 보조 인덱스로 범위를 읽는다는 것은 인덱스에서 맞는 줄을 찾고 그다음 하나하나 표에서 가져온다는 뜻입니다. 좁은 조각이라면 남는 장사입니다. 열세 달 가운데 열나흘이라면 여전히 하나씩 가져오는 줄이 많고, 표를 곧바로 훑는 것이 — 물리적 순서로 읽는 것이고 디스크와 캐시가 좋아하는 방식입니다 — 그것을 이깁니다. 계획기는 그것을 모릅니다. 범위와 인덱스를 보고 집습니다.
"이 인덱스는 갤러리에만 쓰라"고 말할 길은 없습니다. 인덱스는 그 칸을 건드리는 모든 조회에 열려 있고, 계획기는 자기 추정이 그렇다고 하는 곳이면 어디서든 씁니다. 하나를 더하는 것은 그것을 위해 만든 조회 하나가 아니라 그 표의 모든 조회에 대한 변경입니다.
합치면: 아무것도 아닙니다
다섯 전부에 걸쳐 555밀리초가 524가 되었습니다. 1.1배 개선이고, 이 페이지들을 어차피 캐시에서 내보내는 작은 서버에서 스키마를 바꿀 값어치가 없습니다.
90일 그래프는 9% 나아진 것처럼 보입니다. 세지 않았고, 왜인지 적어 둘 값어치가 있습니다. 모든 조회를 세 번 쟀습니다. 인덱스 없이, 있을 때, 그리고 다시 없이. 인덱스 없는 두 번째 실행이 첫 번째 가까이에 오지 않으면 차이는 변경이 아니라 기계였던 것입니다. 90일 그래프에서는 인덱스 없는 두 실행이 13.8% 차이 났습니다 — 주장하려는 효과보다 큽니다. 그러니 그 줄은 아무것도 재지 않았고, 아무것도 아닌 것으로 보고합니다.
이것을 어떻게 쟀고, 왜 그것이 중요한가
살아 있는 표에서 재지 않았습니다. 스크립트가 그것을 복사하고, 사본에서 작업하고, 끝에 사본을 버립니다. 무슨 일이 일어나는지 보려고 운영 표에 인덱스를 더하는 일은 놀랄 때마다 한 번씩만 가능합니다.
조회는 코드에서 들어낸 진짜 조회이고, 카운터 표와의 결합까지 포함합니다. 이 시험의 이전 판본은 단순화한 대역을 썼고 훨씬 신나는 답을 내놓았습니다. 스무 배 빠르다고 말입니다. 그 단순화한 조회는 실제로 도는 것이 아니었습니다.
숫자는 무엇이 되었을까
이것을 흔한 방식으로 쟀다면 — 느려 보이는 조회를 골라 전후로 시간을 재는 것 — 답은 "열 배 빠름, 넣자"였을 것입니다. 인덱스가 들어갔을 테고, 갤러리는 빨라졌을 테고, 사이트맵과 상태 페이지는 느려졌을 테고, 아무도 그 둘을 잇지 못했을 것입니다. 아무도 그쪽을 보고 있지 않았으니까요.
그것이 이 일의 일반적인 모양입니다. 공유 기반 시설에 대한 변경은 그것을 부른 경우만 놓고 평가할 수 없습니다. 물음은 "이것이 내가 보고 있는 것에 도움이 되는가"가 아니라 "이것을 또 무엇이 건드리고, 그것에 무슨 일이 일어나는가"입니다.
될 만한 판본이 하나 있습니다. 두 칸을 담되 날짜를 앞에 둔 인덱스여서, 갤러리가 표로 돌아가지 않고 인덱스만으로 답할 수 있게 하는 것입니다. 더 넓은 범위에서 계획기를 꾀지 않을 수도 있습니다. 재지 않았으니 권고가 아닙니다 — 사본에 올려 볼 다음 것입니다.