modiday

• 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)

• Date math support in index names
  •  날짜 index의 범위를 검색할 수 있다.
    • 원래는 모든 시계열 index를 검색하고 결과를 filtering 했는데 이걸 보완한 것 같다. 
    • aliases를 유지하지 않아도 된다.
  • 예를 들면 daily logs에서 에러를 찾는다고 할 때 검색을 지난 2일로 제한하여 검색할 수 있음 
  •  
  • 형식
    • <static_name{date_math_expr{date_format|time_zone}}>
    • 사용예
      • # GET /<logstash-{now/d-2d}>,<logstash-{now/d-1d}>
      • GET / %3Clogstash-%7Bnow%2Fd-2d%7D%3E%2C%3Clogstash-%7Bnow%2Fd-1d%7D%3E%2C%3Clogstash-%7Bnow%2Fd%7D%3E/_search
      • %3C = '<'
      • %7B = '{'
      • <logstash-{now/M-1M{YYYY.MM}}>

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

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

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

• Multiple Indices
  • 인덱스 매개 변수는 여러 인덱스에서 실행을 지원한다.
  • 아래와 같이 사용 가능하다.
    • test* or *test or te*t or *test*, and the ability to "exclude" (-), for example: test*,-test3
    • 여기서 -test3 은 해당 인덱스를 제외한 다는 표현이다.
• Multiple Indices url query string parameters
  • ignore_unavalizable
    • unavaliable 한 indices 무시할지 말지 
  • allow_no_indices
    • 예를 들어 foo* 로 request했을 때 해당하는 index 없으면 fail로 처리할지 말지 true or false 설정
  • expand_wildcards 
    • 와일드 카드 인덱스 표현( * )으로 확장 할 수있는 인덱스 종류 제어
    • open으로 표현되면 -> open된 index들로만 확장
    • closed로 표현되면 -> closed된 index들로만 확장
    • (?) 어떤 경우에 쓰이는지 잘 모르겠다.

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

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