PUT test
{
"mappings": {
"properties": {
"id": {
"type": "integer"
},
"created": {
"type": "date"
},
"keyword": {
"type": "text",
"analyzer": "standard",
"search_analyzer": "standard"
},
"history": {
"type": "nested",
"properties": {
"created": {
"type": "date"
},
"user_id": {
"type": "integer"
}
}
},
"search_term_relations": {
"type": "join",
"relations": {
"keyword": "history"
}
}
}
}
}
기존의 검색기록은 search_searchhistory
와 search_searchterm
에의해서 관리가 되었다.
searchhistory
: 유저가 특정 검색어를 얼마나 많이 검색했는지를 보여주는 지표이다.searchterm
: 검색어를 기록하는 부분이다. 어떤 단어가 얼마나 많이 검색이 되었는지를 알려준다.문제는 searchhistory
의 방식이다. 검색 기록을 유저 마다 설정하여 기록하는 것은 타당하지만 문제는 검색 기록이 영원히 누적된다는 것이다. 이러한 구조로 다음의 문제가 발생한다.
실시간 검색의 동향을 파악할 수 없다.
지속적인 누적으로 인해서 처음 검색어를 검색한 날짜와 그다음으로 가장 최근에 검색한 날짜가 테이블에 기록된다. 최근 N일 동안 유저가 검색한 검색어에 대한 통계를 낼 수 없다.
최근 유저의 관심사를 파악하 수 없다.
시간에 따라서 유저의 관심사는 변하게된다. 특히 시간의 흐름에 따라서 유저가 어떠한 검색 결과를 원하는 지는 유저의 latent vector를 추출하는 데에 중요한 부분을 차지한다.
먼저 searchterm
의 테이블 변경사항을 살펴보자
변경전
필드 | 설명 |
---|---|
id | pk |
created | 생성일 |
modified | 수정일 |
keyword | 검색어 |
point | 검색 횟수 |
language | 언어 |
변경후
필드 | 설명 |
---|---|
id | pk |
created | 생성일 |
modified | 수정일 |
keyword | 검색어 |
language | 언어 |
가장큰 차이는 검색 횟수의 부재이다. 이는 searchhistory
테이블에서 날짜에 따라 동적으로 집계를 하는 것이 시간별 트렌드를 알기 쉽기 때문에 제외하였다.
searchhistory
의 테이블 변경사항은 다음과 같다.
변경전
필드 | 설명 |
---|---|
id | pk |
created | 생성일 |
modified | 수정일 |
count | 검색한 횟수 |
search_term_id | 검색어 |
user_id | 유저 정보 |
변경후
필드 | 설명 |
---|---|
id | pk |
created | 생성일 |
modified | 수정일 |
search_term_id | 검색어 |
user_id | 유저 정보 |
이제 유저가 검색한 결과마다 하나의 튜플이 생성된다. 이러한 검색기록은 시간별로 생성되며 집계를 통해서 동적으로 유저의 관심사를 분석할 수 있게 된다.
키바나를 통한 분석 결과
변경된 형식을 통해서 실시간으로 사용자의 검색 내용이 인덱싱되고 이를 통해서 키바나를 활용할 수 있다.
created
에 따라서 검색 검색어에 대한 통계 결과를 정리하였다.
하지만 위의 결과의 경우는 사용자가 검색한 텍스트 그 자체를 인덱싱 하기 때문에 집계 결과에서 토큰화된 결과를 보지 못한다. 추후에 사용자가 늘어나게 될 경우 키워드를 따로 뽑아서 집계를 통해서 트랜드를 빠르게 분석하는 방향도 좋을 것이다.