[ElasticSearch 정리하기] Full Text Search 종류

출처: https://www.elastic.co/guide/en/elasticsearch/reference/current/full-text-queries.html
출처: https://stackoverflow.com/questions/26001002/elasticsearch-difference-between-term-match-phrase-and-query-string
1. term
하나의 term을 찾는다. 이 term은 analyze 되지 않는다. 따라서 대소문자, 복수형 등이 다 구분된다
{ "user":"Bennett" }

{
  "query": {
    "term" : { "user" : "bennett" }
  }
}
//아무것도 리턴되지 않는다. (대소문자 구분)

2. match
가장 기본적인 search로 text, number, date, boolean을 사용할 수 있다. text는 검색하기전 analyze된다.
fuzzy matching을 지원한다(정확하게 일치하지않더라도 연관성이 있다고 판단하면 리턴).
GET /_search
{
    "query": {
        "match" : {
            "message" : {
                "query" : "this is a test"
            }
        }
    }
}

3. query_string
입력값을 analyze한다. 사용자가 명시적으로 ""로 둘러싸지않는이상 순서는 상관이 없다.
{ "foo":"I just said hello world" }
{ "foo":"Hello world" }
{ "foo":"World Hello" }

{
  "query": {
    "query_string": {
      "query": "hello World"
    }
  }
}
//얘는 3개를 다 리턴한다

{
  "query": {
    "query_string": {
      "query": "\"Hello World\""
    }
  }
}
//얘는 명시적으로 ""로 싸여져 있기 때문에 match_phrase와 동일하게 처음 2개만을 리턴한다.
query_string과 match의 차이점은 AND와 OR같은 연산자를 사용할 수 있다. 
query_string은 syntax를 먼저 parse한 뒤에 split을 하고 analyze를 한다.
GET /_search
{
    "query": {
        "query_string" : {
            "query" : "(new york city) OR (big apple)",
            "default_field" : "content"
        }
    }
}
주의할 점: query_string은 invalid syntax에 대해 에러를 반환하므로 AND와 OR과 같은 query syntax를 지원해야되는 것이 아니라면 match를 사용하거나 좀 더 덜 엄격한 simple_query_string을 사용하는 것이 낫다.

4. Intervals
matching rules를 사용하여 쿼리한다. 여러개의 term들이 원하는 간격안에 존재하는지 쿼리한다.
아래의 쿼리는 "hot"과 "porridge"사이에 10단어 이상 간격이 없으면서 중간에 "salty"가 없어야 된다.
POST _search
{
  "query": {
    "intervals" : {
      "my_text" : {
        "match" : {
          "query" : "hot porridge",
          "max_gaps" : 10,
          "filter" : {
            "not_containing" : {
              "match" : {
                "query" : "salty"
              }
            }
          }
        }
      }
    }
  }
}

5. match_phrase
입력값을 analyze한다. 그리고 다음의 조건을 충족하는 document를 찾아서 반환한다.
- 모든 term들이 field에 존재해야한다.
- 모든 term들이 입력된 순서에 맞게 존재해야된다.
{ "foo":"I just said hello world" }
{ "foo":"Hello world" }
{ "foo":"World Hello" }

{
  "query": {
    "match_phrase": {
      "foo": "Hello World"
    }
  }
}
//1번째 2번째만 리턴된다. 3번째는 순서가 틀림

6. match_boolean_prefix
마지막 term을 제외한 모든 term은 term query에 사용된다. 마지막 term은 prefix query에 사용된다.
따라서 아래의 match_bool_prefix는 그 밑의 term과 prefix로 이루어진 query와 동일하다
GET /_search
{
    "query": {
        "match_bool_prefix" : {
            "message" : "quick brown f"
        }
    }
}

GET /_search
{
    "query": {
        "bool" : {
            "should": [
                { "term": { "message": "quick" }},
                { "term": { "message": "brown" }},
                { "prefix": { "message": "f"}}
            ]
        }
    }
}
match_phrase_prefix와 상당히 유사하지만 match_phrase_prefix는 입력값을 phrase로 보고 쭉 이어진 하나로 검색을 하는 반면, match_boolean_prefix는 term단위로 검색을 하기때문에 서로 떨어져 있어도 가능하고, 순서가 뒤섞여있어도 가능하다.

7. match_phrase_prefix
위에서 언급했던 것처럼 입력값을 하나의 뭉텅이로 검색한다 따라서:
     - quick brown fox (O)
     - two quick brown ferrets (O)
     - the fox is quick and brown (X)

8. multi_match
multi_match는 multi query를 바탕으로 여러 field를 동시에 쿼리할 수 있도록 한다.
GET /_search
{
  "query": {
    "multi_match" : {
      "query" : "this is a test",
      "fields" : [ "subject^3", "*_name" ] 
    }
  }
}
위의 코드처럼 subject 필드에 3배의 가중치를 줄 수 있으며 field이름에 * wildcard를 사용할 수 있다.

만약 field가 명시되어 있지 않다면 index.query.default_field로 설정된 field에서 검색하고, 이 default_field는 따로 명시하지 않았다면, index의 field는 term query를 수행할 수 있는 모든 field를 추출하여 수행한다.

multi_match가 어떻게 작동할지는 type 파라미터에 따라 결정된다.
 - best_fields: 여러개의 field들 중에서 입력값 단어들 중 가장 많은 단어를 가지고 있는 하나의 field의 점수를 사용
 - most_fields: 여러개의 field들의 점수를 산출한뒤 합산하고 field의 개수로 나눈 평균점수를 사용한다

 - phrase / phrase_prefix: best_fields와 똑같지만 match_phrase / match_phrase_prefix를 match대신 사용

 - cross fields: 여러개의 field가 동시에 만족되야할 경우(예: 성과 이름이 다른 field에 들어가있을때). query string을 individual term으로 analyze한 뒤에 마치 하나의 field를 검색하는 것처럼 모든 field를 살펴본다. 
(위의 best_field와 most_field와는 달리 어느 하나의 field에 모든 term이 존재하면 된다)
(주의: cross_fields에는 fuzziness가 사용될 수 없다)

tie_breaker: 점수가 산정되는 방식을 결정한다:
     - 0.0 : 모든 field 중 가장 높은 점수를 가진 field의 점수를 선택
     - 1.0 : 모든 field의 점수를 합함
     - 0.0 < n < 1.0: 가장 높은 field의 점수 + (n * 나머지 matching field 점수)

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Django 공식문서 번역] REST Framework - Viewset and Router

Viewset을 사용하면 관련된 view들을 하나의 클래스로 묶을 수 있다. class UserViewSet ( viewsets . ViewSet ): """ A simple ViewSet for listing or retrieving users. """ def list ( self , request ): queryset = User . objects . all () serializer = UserSerializer ( queryset , many = True ) return Response ( serializer . data ) def retrieve ( self , request , pk = None ): queryset = User . objects . all () user = get_object_or_404 ( queryset , pk = pk ) serializer = UserSerializer ( user ) return Response ( serializer . data ) from rest_framework import routers router = routers . SimpleRouter () router . register ( r 'users' , UserViewSet ) router . register ( r 'accounts' , AccountViewSet ) urlpatterns = router . urls 위의 예시는 아래의 URL 패턴을 만든다 URL pattern:  ^users/$  Name:  'user-list' URL pattern:  ^users/{pk}/$  Name:  'user-detail' URL
자세한 내용 보기

Intel Open WebRTC Toolkit(OWT) Media server 설치하는법

Ubuntu 18을 기준으로 하고있습니다. 1.  https://software.intel.com/en-us/webrtc-sdk  에 들어가서 Download를 누르고 회원가입 후 다운로드를 받는다. - 만약 리모트 서버에 다운을 받고 싶다면 회원가입 후 다운로드 버튼 > 오른쪽 클릭 > 링크 복사로 다운로드 링크를 복사한 후, wget <링크> 2. 다운받은 zip파일을 풀어준다 unzip Intel_CS_WebRTC.v<version>.zip - 만약 unzip이 깔려있지 않다면 sudo apt-get install unzip 3. 압축을 푼 폴더 안으로 이동한 후 자신이 설치하고자 하는 패키지를 설치하면 되는데 이번에는 서버를 설치하려고 하기 때문에 tar xf CS_WebRTC_Conference_Server_MCU.v<version>.Ubuntu.tgz 4. 압축이 풀린 폴더안으로 이동 cd Release-v<version> 5. dependencies 설치하기 bin/init-all.sh --deps 6. 서버 시작하기 bin/start-all.sh - 만약 "node version not match. Please use node v8"과 같은 에러가 뜬다면 node의 버전을 8.15버전으로 바꿔줘야되는데 아마 기본적으로 nvm이 같이 깔렷을텐데: nvm ls 결과가 다음처럼 뜰 것이다: Release-v4.3# nvm ls         v8.15.0 ->       system node -> stable (-> v8.15.0) (default) stable -> 8.15 (-> v8.15.0) (default) 그러면: nvm use stable 하고 node 버전을 체크해보면 8.15가 뜬다 그리고 다시 bin/start-all.sh 하면! starting ma
자세한 내용 보기

[Django REST Framework] create() vs perform_create()

Django REST Framework의 ModelViewSet과 create() 관련 찾아보고 공부한 내용을 정리해보려고 한다. 기본적으로 ModelViewSet은 GenericAPIView라는 클래스를 상속받기 때문에 .list(), .create()  .list(), .create() 등을 기본으로 내장하고 있다. 따라서 이 중에서 기본 내장되어 있는 메소드 중 동작을 변경하고 싶은 것들만 overriding해서 수정하면 된다. 그리고 ModelViewSet은 GenericAPIView를 상속받고 있기 때문에 최소한 queryset와 serializer_class는 세팅해주어야 한다. from rest_framework import status from rest_framework.response import Response def create(self, request, *args, **kwargs): serializer = self.get_serializer(data=request.data) serializer.is_valid(raise_exception=True) self.perform_create(serializer) headers = self.get_success_headers(serializer.data) return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers) def perform_create(self, serializer): serializer.save() 위의 코드를 보면 이해가 조금 더 쉬울 것 같다. perform_create()은 create()의 동작 중 일부분을 overriding한다고 생각하면 되는데, serializer.save()가 호출될 때 perform_create()가 호출된다고 생각하면 된다. 위의 경우 명시적으로 perform_create()를 호출했지만, d
자세한 내용 보기