현재까지 공부한 내용을 토대로 우리 프로젝트에 적용할 때 발생 될 문제 점에 대해 정리하도록 하겠습니다.
저희 프로젝트는 웹페이지에서 조회후 검수 처리를 진행하고, 검수 처리의 유무에 따라 [검수, 의심, 정상]으로 조회를 진행합니다. 또한 해당하는 조회 페이지는 페이징 처리를 현재 제공하고 있으며 이에따라 고객사 에서는 ES를 적용함에 따른 기능변화를 싫어할 것으로 예측합니다.
이에따라 ES를 적용하면 발생될 문제점은
1.
쓰기 증폭
a.
B-Tree는 문서 하나를 INSERT할 때 인덱스가 걸린 컬럼 개수만큼만 갱신합니다.
인덱스 3개면 트리 3개에 각각 1건씩.
역인덱스는 문서 하나에 토큰 개수만큼 posting list를 건드립니다. 500단어짜리 문서에서 중복 제거 후 200개의 고유 term이 나오면, 200개의 posting list에 doc id를 추가해야 합니다.
MySQL: INSERT 1건 → 인덱스 3개 갱신
ES: INSERT 1건 → term 200개 × (posting list + term frequency + position) 갱신
Plain Text
복사
여기에 색인 시점 분석(형태소 분석, nori 같은 건 특히 무겁습니다) 비용까지 붙습니다. 읽기를 빠르게 하려고 쓰기 비용을 앞당겨 지불하는 구조입니다.
그래서 ES는 이걸 배치로 상쇄합니다 → 메모리 버퍼에 모았다가 1초에 한 번 세그먼트로 떨굽니다. 대신 그 1초가 near real-time이라는 또 다른 대가가 됩니다.
예를 들면 아래와 같습니다.
{
"name": "카카오프렌즈 라이언 쿠션",
"description": "부드러운 극세사 소재로 제작된 대형 쿠션입니다. 거실 소파나 ... (200자)",
"stock": 100
}
JSON
복사
이 문서 1건을 분석기에 통과시키면:
[부드럽다, 극세사, 소재, 제작, 대형, 쿠션, 거실, 소파, 침대, 사용, 커버, 분리, 세탁, 가능, ...]
Plain Text
복사
이렇게 나온 토큰의 수가 200개라면 재색인 시 실제로 일어나는 일은 stock의 갯수를 99로 수정한다면 새 세그먼트를 만들고 기존 세그먼트는 사용하지 않는다고 표기해 둡니다.
이후 Merge를 통해 문서를 정리합니다.
관련 상세 내용
2.
Paging 문제
b.