modiday

• Keyword
  • 일정한 형식으로 고정된 문자열 데이터를 색인할 때 사용
  • keyword타입의 field는..
    • aggregation, sorting, filtering에 사용된다.
    • 분리된 문자열로는 검색할 수 없다. 
• Text
  • 사이즈가 큰 문자열을 저장할 때 사용 
  • 'Analyzer'를 통해 문자열이 분리된 토큰으로 저장되기 때문에 문자열 내 단어들로 검색할 수 있다. 
  • 전문 검색이 필요할 경우에 사용하는 것이 좋음 
  • sorting, aggregation에 사용은 가능하나 성능 문제로 사용시 주의가 필요하다. 
    • Text & Keyword
      • 타입은 text이지만 aggregation 이나 sorting을 해야하는 경우에는 아래와 같이 사용한다. 
      • city의 타입은 text이지만 city.raw 필드의 type은 키워드로 준다. 

PUT my_index
{
  "mappings": {
    "properties": {
      "city": {
        "type": "text",
        "fields": {
          "raw": { 
            "type":  "keyword"
          }
        }
      }
    }
  }
}

PUT my_index/_doc/1
{
  "city": "New York"
}

PUT my_index/_doc/2
{
  "city": "York"
}

GET my_index/_search
{
  "query": {
    "match": {
      "city": "york" 
    }
  },
  "sort": {
    "city.raw": "asc" 
  },
  "aggs": {
    "Cities": {
      "terms": {
        "field": "city.raw" 
      }
    }
  }
}

(참고 : https://www.elastic.co/guide/en/elasticsearch/reference/6.5)

• 날짜 / 시간 표현식을 사용하여 간격을 지정할 수 있다. 
• 사용예 (elasticsearch 공식 api 문서 참조)

POST /sales/_search?size=0
{
    "aggs" : {
        "sales_over_time" : {
            "date_histogram" : {
                "field" : "date",
                "interval" : "month"
            }
        }
    }
}

• Aggregation 에서 사용

GET mytable*/_search
{
  "size": 0,
  "aggs": {
    "결과(result)": {
      "date_histogram": {
        "field": "birth",
        "interval": "month",
        "format": "yyyy-MM"
      },
      "aggs": {
        "사용비용": {
          "sum": {
            "field": "usage_cost"
          }
        }
      }
    }
  }
}

• Composite & SubAggregation 에서 사용

GET mytable*/_search
{
  "size": 0,
  "aggs": {
    "결과(result)": {
      "composite": {
        "sources": [
          {
            "날짜": {
              "date_histogram": {
                "field": "birth",
                "interval": "month",
                 "format": "yyyy-MM"
              }
            }
          }
        ]
      }, 
      "aggs": {
        "사용비용": {
          "sum": {
            "field": "usage_cost"
          }
        }
      }
    }
  }
}

(참고 : https://www.elastic.co/guide/en/elasticsearch/reference/6.5)

• Multi-Index
  • GET /twitter/_search?q=user:kimchy
  • GET /kimchy,elasticsearch/_search?q=tag:wow
  • GET /_all/_search?q=tag:wow
• URI Search
  • URI에 사용할 수 있는 매개변수
    • q : 특정필드 검색하고 싶을 때
    • _source : 도큐먼트 내용 표시하지 않고 hits와 scores 등의 정보만 출력
    • fields : 출력 결과에 표시할 필드 
    • sort : 검색 결과의 출력 순서 ex) ?sort=필드명:asc
    • timeout : 제한 시간 지정 
    • from : 결과 어디서부터 출력할지 지정 ex) from=3 -> 4번째부터 출력  
    • size : 리턴 결과 개수 (기본 10개) 
• Request Body Search - 01 
  • SELET * FROM twitter WHERE user = 'modi'

GET /twitter/_search
{
    "query" : {
        "term" : { "user" : "modi" }
    }
}

{
    "took": 1,
    "timed_out": false,
    "_shards":{
        "total" : 1,
        "successful" : 1,
        "skipped" : 0,
        "failed" : 0
    },
    "hits":{
        "total" : 1,
        "max_score": 1.3862944,
        "hits" : [
            {
                "_index" : "twitter",
                "_type" : "_doc",
                "_id" : "0",
                "_score": 1.3862944,
                "_source" : {
                    "user" : "modi",
                    "message": "trying out Elasticsearch",
                    "date" : "2009-11-15T14:12:12",
                    "likes" : 0
                }
            }
        ]
    }
}

• Request Body Search - Sort

PUT /my_index
{
    "mappings": {
        "_doc": {
            "properties": {
                "post_date": { "type": "date" },
                "user": {
                    "type": "keyword"
                },
                "name": {
                    "type": "keyword"
                },
                "age": { "type": "integer" }
            }
        }
    }
}

GET /my_index/_search
{
    "sort" : [
        { "post_date" : {"order" : "asc"}},
        "user",
        { "name" : "desc" },
        { "age" : "desc" },
        "_score"
    ],
    "query" : {
        "term" : { "user" : "kimchy" }
    }
}

엘라스틱 공식문서를 참고하여 짧은 영어 실력으로 번역하고 이해한 내용을 정리하였습니다.

(참고 : https://www.elastic.co/guide/en/elasticsearch/reference/6.5)

• Near Real Time
  • Elasticsearch 는 실시간 검색 플랫폼
  • 인덱스 생성 시점부터 검색 가능 시간까지 약간의 대기 시간 (보통 1 초)이 있긴 하다.

• Cluster
  • 모든 데이터를 보유하고 있는 노드들의 집합
  • 모든 노드에 검색할 수 있고, 연합된 인덱싱을 제공한다.
  • 클러스터의 default 이름은 "elasticsearch"
  • 노드가 클러스터의 이름으로 클러스터에 join하게끔 설정되어 있을 수 있으니, 클러스터 이름을 중요시하자!
  • 다른 환경에서 같은 클러스트 이름을 쓰게 되면 노드가 엉뚱한 클러스터에 join되는 결과를 맞볼 수 있으니 같은 이름을 쓰지 않게 주의하자.
  • Cluster 건강한지 확인하기 (ㅋㅋ)
    • GET /_CAT/health?v
      • Green : 굿
      • Yellow : 몇몇 replicas(아래 설명 참고)가 아직 할당되지 않은 상태
      • Red : 일부 데이터 not avliable

• Node
  • 클러스터의 일부로써, 데이터를 저장하고 검색하는 기능을 하는 단일 서버
  • 노드이름은 중요하다 (클러스터 이름과 마찬가지로)
    • 왜 ? 나의 네트워크의 이름은 네트워크의 어떤 서버가 Elasticsearch 클러스터의 어떤 노드에 해당하는지 식별하려는 관리 목적에 중요합니다.
  • 클러스터 안에 여러개의 노드를 가질 수 있음 
  • 노드 하나로 운영할 땐 굳이 클러스터 구성 설정을 따로하지 않아도 된다. 
  • 관계형 데이터베이스와는 다르게 하나의 서버에 데이터가 다 저장되는 것이 아니라 여러개의 노드에 데이터가 저장되고 이것이 전부 모여 엘라스틱서치 서버를 만들게 된다. 
    • 데이터노드 : 데이터가 저장되는 노드로 샤드가 배치되는 곳이다. 
    • 마스터 노드 : 인덱스 샌성/삭제와 같은 클러스터 관련 전반적인 작업을 하는 곳이다.
    • 인제스트 노드 : 데이터를 전처리해준다.
    • 코디네이팅 노드 : 요청을 분산시켜준다.

• Index
  • 관계형 데이터베이스의 '데이터베이스' 와 비슷
  • 차이라면 엘라스틱서치는 여러 인덱스를 동시에 검색할 수 있게 하였음 (=Multi Tenancy)

• Shard
  • 인덱스 내부에 쪼개진 데이터들
  • 왜 쪼개나?
    • 대량의 데이터를 저장하면 단일 노드 서버의 하드웨어 용량을 초과할 수 있기 때문에
    • 엘라스틱 서치는 대량의 데이터를 다루는 서비스이기 때문에 데이터가 많아지면 노드를 구분하고, 구분하면서 데이터들이 쪼개지게 된다. 
    • 이렇게 쪼개면 볼륨을 분할하는 효과를 가져오기 때문에 성능/처리량이 증가한다. 
  • 프라이머리 샤드
    • 데이터의 원본
  • 레플리카 샤드
    • 프라이머리 샤드의 복제본
    • 중요함! Whay?
      • 샤드나 노드가 실패할 경우 고가용성을 제공하는데 이런 이유로 레플리카 샤드는 원본/기본 샤드와 동일한 노드에 할당되지 않는다.
      • 이 뜻은 무엇이냐면..
        • 검색 볼륨/처리량을 향상 시키는 동안에도 끊김 없이 처리 가능하다는 뜻
        • 왜냐하면 그동안 레플리카 샤드한테 처리하라고 시키면 되기 때문 

• Document
  • 데이터 최소 단위
  • row
  • JSON Object

• Field
  • 관계형 데이터베이스의 '열(Column)'
  • 관계형 데이터베이스의 열과 다른점?
    • 하나의 필드가 여러 개의 데이터 타입을 가질 수 있음

• Mapping
  • 데이터 타입 지정 등의 필드 속성 정의

엘라스틱 공식문서를 참고하여 짧은 영어 실력으로 번역하고 이해한 내용을 정리하였습니다.

초보 개발자이니 틀린 부분이 있다면 언제든지 얘기해주세요 ^^

(참고 : https://www.elastic.co/guide/en/elasticsearch/reference/6.5)

• Pretty Results
  • 요청할 때 ?pretty=true 를 붙여주면 JSON 결과를 보기 좋게 변경해준다. 
• Human readable output
  • query string에 ?human=false 를 붙여주면 사람이 사용하는 용도가 아닌 모니터링 도구에 의해 사용될 때 의미 있는 통계 결과가 나온다.  
• Date Math
  • gt & lt -> range query에서 사용
  • from & to -> aggregations 에서 사용 
  • +1h , -1d , /d 
    • ex) now-1h
  • y = years, M = months, w = weeks, d = days, h = hours, H = hours, m = minutes, s = seconds
• Response Filtering
  • Elasticsearch가 반환하는 응답 개수?내용?을 줄이기 위해 filter_path를 사용하는데 딱 필요한 데이터만 받고 싶을때 사용 가능함
  • 사용 예) took, hits._id 만 필요로 하는 경우
    • GET /_search?q=elasticsearch&filter_path=took,hits.hits._id,hits.hits._score
    • Response
      • { "took" : 3, "hits" : { "hits" : [ { "_id" : "0", "_score" : 1.6375021 } ] } }
  • wildcard (* , **) 사용 가능
  • - 사용가능
    • GET /_count?filter_path=-_shards
• Flat Setting
  • ?flat_settings=true 해주면 결과가 flat하게 나온다 (기계가 더 이해하기 쉬운 버젼으로)
  • 근데 flat_settings=false (기본) 이랑 비교해봤을 때 나름의 매력이 또 있는 것 같음 ㅋㅋ
• Enabling stack traces
  • 에러가 났을 때 ?size=surprise_me를 query string에 붙여 주면 아래와 같은 stacktrace를 확인할 수 있다.
  • Request
    • POST /twitter/_search?size=surprise_me&error_trace=true
  • Response

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "Failed to parse int parameter [size] with value [surprise_me]",
        "stack_trace": "Failed to parse int parameter [size] with value [surprise_me]]; nested: IllegalArgumentException..."
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "Failed to parse int parameter [size] with value [surprise_me]",
    "stack_trace": "java.lang.IllegalArgumentException: Failed to parse int parameter [size] with value [surprise_me]\n    at org.elasticsearch.rest.RestRequest.paramAsInt(RestRequest.java:175)...",
    "caused_by": {
      "type": "number_format_exception",
      "reason": "For input string: \"surprise_me\"",
      "stack_trace": "java.lang.NumberFormatException: For input string: \"surprise_me\"\n    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)..."
    }
  },
  "status": 400
}

• Request body in query string
  • POST request가 아닌데 request body가 있고, 이를 허용하지 않는 라이브러리의 경우에는 request body를 source query string으로 파라미터를 보내면 된다. 
  • 이때 반드시 source_content_type을 명시해 주기 (예를 들면 application/json)
• Content-Type Requirements
  • request body 보낼 때 content-type header 명시해주기

엘라스틱 공식문서를 참고하여 짧은 영어 실력으로 번역하고 이해한 내용을 정리하였습니다.

초보 개발자이니 틀린 부분이 있다면 언제든지 얘기해주세요 ^^

(참고 : https://www.elastic.co/guide/en/elasticsearch/reference/6.5)