Backend · Search
검색엔진을 들일 때 - DB로 버틸 수 있는 선
검색이 느리다고 바로 엔진을 들이면 저장소가 둘이 되고 동기화라는 새 일이 생긴다. DB로 어디까지 버틸 수 있고, 무엇을 보고 넘어갈지 판단표로 닫는다.
검색이 빠른 이유 6편
Backend · Search
색인은 늦게 따라온다 - 방금 쓴 글이 안 보이는 이유
글을 저장하고 바로 검색했는데 안 나온다. 버그가 아니라 역색인이라는 구조가 원래 그렇게 생겼다. 왜 바로 못 넣는지, 그 지연을 어디까지 줄일 수 있는지 본다.
검색이 빠른 이유 5편
Backend · Search
랭킹 - 다 찾은 다음 무엇을 위에 둘까
조건에 맞는 문서가 5,000건 나왔다. 사용자는 위에서 세 개만 본다. 어떤 문서가 더 관련 있다고 판정하는지, 공식 없이 직관만으로 따라가 본다.
검색이 빠른 이유 4편
Backend · Search
토큰화 - 어디서 자르느냐가 검색되느냐를 정한다
역색인을 만들려면 본문을 낱말로 잘라야 한다. 그런데 한국어는 공백이 낱말 경계가 아니다. 검색이 안 된다는 신고의 대부분이 이 자르는 규칙에서 나온다.
검색이 빠른 이유 3편
Backend · Search
역색인 - 문서에서 낱말이 아니라 낱말에서 문서로
검색이 빠른 이유는 결국 아이디어 하나다. 문서를 열어 낱말을 찾는 대신, 낱말마다 그 낱말이 든 문서 번호를 미리 적어 둔다. 책 뒤의 찾아보기와 정확히 같은 구조다.
검색이 빠른 이유 2편
Backend · Search
LIKE '%검색어%' - 인덱스가 있어도 다 훑는다
검색창을 붙이고 LIKE로 막았다. 인덱스도 만들어뒀는데 데이터가 늘자 느려진다. 인덱스가 게을러서가 아니라, DB 인덱스와 본문 검색이 애초에 다른 일을 하기 때문이다.
검색이 빠른 이유 1편
CS · Algorithm
이진탐색 - 반을 버릴 수 있을 때
정렬해 두면 한 번 볼 때마다 절반을 통째로 버릴 수 있다. 그 조건이 무엇인지, 그리고 왜 이 짧은 코드가 그렇게 자주 틀리는지.
알고리즘의 갈림길 4편