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_searchhistorysearch_searchterm에의해서 관리가 되었다.

문제점

문제는 searchhistory의 방식이다. 검색 기록을 유저 마다 설정하여 기록하는 것은 타당하지만 문제는 검색 기록이 영원히 누적된다는 것이다. 이러한 구조로 다음의 문제가 발생한다.

  1. 실시간 검색의 동향을 파악할 수 없다.

    지속적인 누적으로 인해서 처음 검색어를 검색한 날짜와 그다음으로 가장 최근에 검색한 날짜가 테이블에 기록된다. 최근 N일 동안 유저가 검색한 검색어에 대한 통계를 낼 수 없다.

  2. 최근 유저의 관심사를 파악하 수 없다.

    시간에 따라서 유저의 관심사는 변하게된다. 특히 시간의 흐름에 따라서 유저가 어떠한 검색 결과를 원하는 지는 유저의 latent vector를 추출하는 데에 중요한 부분을 차지한다.

개선사항

먼저 searchterm의 테이블 변경사항을 살펴보자

가장큰 차이는 검색 횟수의 부재이다. 이는 searchhistory 테이블에서 날짜에 따라 동적으로 집계를 하는 것이 시간별 트렌드를 알기 쉽기 때문에 제외하였다.

searchhistory의 테이블 변경사항은 다음과 같다.

이제 유저가 검색한 결과마다 하나의 튜플이 생성된다. 이러한 검색기록은 시간별로 생성되며 집계를 통해서 동적으로 유저의 관심사를 분석할 수 있게 된다.

결과

키바나를 통한 분석 결과

키바나를 통한 분석 결과

변경된 형식을 통해서 실시간으로 사용자의 검색 내용이 인덱싱되고 이를 통해서 키바나를 활용할 수 있다.

created에 따라서 검색 검색어에 대한 통계 결과를 정리하였다.

하지만 위의 결과의 경우는 사용자가 검색한 텍스트 그 자체를 인덱싱 하기 때문에 집계 결과에서 토큰화된 결과를 보지 못한다. 추후에 사용자가 늘어나게 될 경우 키워드를 따로 뽑아서 집계를 통해서 트랜드를 빠르게 분석하는 방향도 좋을 것이다.