#클로드 3.5 소네트
{
  "trigger": {
    "schedule": {
      "cron": "0 0 * * *"  // 매일 자정에 실행
    }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["users-index"],
        "body": {
          "query": {
            "bool": {
              "must_not": [
                {
                  "range": {
                    "last_login": {
                      "gte": "now-23d"
                    }
                  }
                }
              ],
              "must": [
                {
                  "term": {
                    "active": true
                  }
                }
              ]
            }
          }
        },
        "size": 1000
      }
    }
  },
  "condition": {
    "compare": {
      "ctx.payload.hits.total": {
        "gt": 0
      }
    }
  },
  "actions": {
    "email_inactive_users": {
      "foreach": "ctx.payload.hits.hits",
      "max_iterations": 1000,
      "email": {
        "to": "{{_source.email}}",
        "subject": "Login Reminder",
        "body": {
          "html": """
          <p>Dear {{_source.name}},</p>
          <p>We noticed that you haven't logged in to our service for 23 days. 
          We miss you and hope to see you soon!</p>
          <p>Best regards,<br>Your Service Team</p>
          """
        }
      }
    }
  }
}

#챗gpt 3.5
PUT _watcher/watch/login_watch
{
  "trigger": {
    "schedule": {
      "daily": { "at": "12:00" }     // 매일 낮 12시에 실행
    }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["user-logs"],    // 사용자 로그가 저장된 인덱스
        "body": {
          "query": {
            "bool": {
              "must_not": {
                "range": {
                  "last_login": {    // 마지막 로그인 시간 필드
                    "gte": "now-23d/d",
                    "lte": "now/d"
                  }
                }
              }
            }
          }
        }
      }
    }
  },
  "condition": {
    "compare": {
      "ctx.payload.hits.total.value": {
        "gt": 0     // 하나 이상의 사용자가 검색되면 실행
      }
    }
  },
  "actions": {
    "email_action": {
      "email": {
        "to": "{{#ctx.payload.hits.hits}}{{_source.email}}{{/ctx.payload.hits.hits}}", // 사용자 이메일 주소
        "subject": "로그인 알림",
        "body": "귀하의 계정은 23일 동안 로그인하지 않았습니다."
      }
    }
  }
}

apiVersion: v1
kind: Service
metadata:
  name: elasticsearch-node
  namespace: branch
spec:
  clusterIP: None
  selector:
    app: elasticsearch
  ports:
    - port: 9201
      name: http
    - port: 9301
      name: transport

apiVersion: v1
kind: Service
metadata:
  name: elasticsearch-node1
  namespace: branch
spec:
  ports:
  - port: 9201
    name: rest
    targetPort: 31015
  - port: 9301
    name: transport
  clusterIP: None  # 이 설정이 서비스를 headless로 만듭니다.
  selector:
    app: elasticsearch
    node.name: "node1"  # 이 예시에서는 elasticsearch Pod의 라벨에 맞춰야 합니다.

해당 문서는 아래 공식 문서를 정리한 내용임

https://www.elastic.co/guide/en/elasticsearch/reference/7.16/modules-cluster.html

샤드 리밸런싱

클러스터의 어느 노드에도 샤드가 몰려있지 않고 같은 수준의 샤드 개수를 유지하고 있을 때 '균형이 맞는다'고 표현함. 엘라스틱 서치는 균형을 맞추기 위해서 노드 간에 샤드를 이동시키는 '리밸런싱'이라는 작업을 자동으로 실행함. 리밸런싱은 클러스터의 샤드 할당 규칙에 따르기 때문에 완벽할 수 없음. 이런 경우, 가장 완벽한 상태를 만드려고 시도함. 데이터 티어를 사용하는 경우에는 할당 규칙을 필터링하여 각 샤드를 적절한 티어에 배치함.

샤드 휴리스틱 리밸런싱

리밸런싱은 각 노드의 무게를 계산한 후, 무거운 노드에서 가벼운 노드로 샤드를 이동시키며 발생함. 설정한 값 이하로 두 노드 간 차이를 좁힐 수 있는 이동이 더 이상 없을 때 균형을 잡았다고 함.

디스크 기반 샤드 할당

디스크 기반 샤드 할당은 필요 이상의 샤드 이동을 막고, 모든 노드가 충분한 디스크 공간을 갖도록 함. 목표는 어떤 노드도 높은 워터마크를 갖지 않게 하는 것임. 리밸런싱 중 일시적으로 임계치를 넘어갈 수는 있으나 다른 노드로 다시 샤드를 리밸런싱하면서 해당 문제를 해결함. 일시적으로 높은 워터마크 이상의 디스크를 사용하는 것은 정상이라고 볼 수 있음.

낮은 워터마크

• 샤드의 할당 작업 중단
• 기본 샤드는 새로 생성 가능

높은 워터마크

• 모든 샤드의 할당 작업 중단

allocator는 낮은 워터마크를 초과한 노드에 더이상 샤드가 할당될 수 없도록 하여 높은 워터마크 초과를 방지함. 모든 노드가 높은 워터마크를 초과하면 샤드 할당이 불가능해지므로 일부 노드가 항상 낮은 워터마크보다 디스크를 적게 쓰는지 확인 작업이 필요함.

작성 후 날리는 쿼리문에서, index를 생성만 한다고 치면 PUT이 맞는데, 생성과 동시에 데이터를 인덱싱 하려면 POST가 맞지 않나 의문 또, 따로 타입을 지정하라는 요구사항이 없는데 mapping을 내가 작성해두는게 맞을지?

task 2

mapping은 source index 복사해오면 될 것 같고, 문제 조건을 잘 모르겠음 단순히 title필드를 keyword 타입으로 변경해서 검색이 안 되게 만들면 되는걸까?

task 3

coot_to는 _search request를 날렸을 때 보이지 않음.. 이거 말고 다른 옵션이 있는건가? 가이드 찾아봤는데 mapping parameters에서 내용 찾지 못했음 몰라서 안보이는건지도

task 4

기본 aggregation 작성 문제 작성은 했으나 확인은 해볼 수 없어서 아쉬움 (index 부재)

task 5

runtime field script를 작성하는 문제 마찬가지로 직접 확인해 볼 수 없어서 아쉬움

task 6

하위 aggregation이 있는 경우의 정렬 방법을 자꾸 잊어버림 그래도 가이드에서 서치 키워드를 인지했으니 괜찮을 듯! 실 index가 없어서 web_traffic 인덱스 활용하여 비슷한 조건으로 진행함

task 7

score는 검색 조건에 해당된 필드들의 수라는 조건이 잘 이해되지 않는다.. 그 외 두 가지 조건은 쿼리 작성 가능할 듯

task 8

일반적인 search 쿼리 작성 문제이나, 클러스터 두 개를 다 활용해야 함

task 9

repo와 snapshot 설정하는 문제 경로 문제로 고생했었는데, 키바나 사용하면 큰 문제 없었던 것으로 기억

task 10

search template 작성하는 문제 크게 어려움 없음

설정한 role과 user는 어떻게 테스트 할 수 있는지 질문할 것

user 생성 시, role을 여러 개 선택할 수 있는 것 같던데 선택한 role 사이에 권한이 충돌하면 어떻게 되는지?

• task1_role : 문제 조건에 맞는 role 설정 task1 이외의 모든 인덱스에 대해 read 권한만 가짐
• test_role : 궁금해서 만들어본 role 설정 모든 인덱스에 대해 all 권한 부여

하나의 유저에 task1_role과 test_role 모두 부여했는데 문제 없이 저장되었음

task 2

문제 없음! clear!

task 3

해설은 dynamic template 사용했는데, 결과만 맞으면 mapping을 하나하나 정의해도 시험에서 큰 문제 없는지?

task 4

ignore_missing에 대한 이야기가 문제에 제시되지 않았는데, 해설에서는 해당 옵션을 true로 설정함 일반적으로 필수로 설정하는 옵션인가?

task 5

공식 문서에서 nested field 내용 확인

예시

PUT my-index-000001/_doc/1
{
  "group" : "fans",
  "user" : [
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}

• user가 nested field가 아닌 경우

  GET my-index-000001/_search
  {
  "query": {
    "bool": {
      "must": [
          {"match": {"user.first": "John"}},
        {"match": {"user.last": "White"}}
      ]
    }
  }
  }

  위와 같은 요청을 전송하면 hit이 1개가 도출됨 user필드 내부의 요소 두 개를 하나의 단위로 보지 않고, 전체를 하나의 document로 취급하기 때문

• user가 nested field인 경우

  GET my-index-000001/_search
  {
   "query": {
    "nested": {
      "path": "authors",
      "query": {
        "bool": {
          "must": [
            {"match": {"user.first_name": "John"}},
            {"match": {"user.last_name": "White"}}
          ]
        }
      }
    }
  }

  먼저의 예시와 유사한 검색이지만, 이 요청의 응답은 hit이 0개. user가 nested field이므로 그 내의 객체 하나하나를 하나의 작은 단위로 보기 때문 필드 하나하나를 보지 않고 객체를 검색한다고 이해하면 맞을 듯

조건에 맞추어 User와 Role 설정하는 문제 lab에서 실습하지 않은 내용이지만, 키바나 잘 확인하면 무리 없이 작성 가능

task 2

query를 사용해 범위를 좁히고, 중첩 구조의 aggregation을 진행하는 문제 lab에서 진행하던 것과 상황 설정만 다를 뿐, 거의 같음

task 3

dynamic templates 사용하는 것 이외에는 lab 실습과 크게 다를 것 없는 문제 dynamic 개념을 완전 뒤로하고 있었는데 개념 상기도 되고 실습을 처음 진행해보기도 했음 실제 시험 중에는 답안을 확인할 수 없으니, 메뉴얼의 드롭다운을 모두 확인해보면서 어떤 개념이 있는지 미리 살펴보고, 시험 중에라도 막히는 경우 메뉴얼 싹 훑어보는 것이 좋을 듯

task 4

특정 필드에 대해 따로 타입 설정 해주지 않는 것 확인함.. 코드도 에러로 동작하지 않음 ㅠㅠ -> 하나하나 비교해가면서 다시 뜯어볼 예정 => ingest pipeline 작성할 때에 오타가 있었던 것으로 확인! 문제지의 answer보다 더 정답에 가깝다고 생각함 문제에서는 runtime_ms, bytes_sent, @timestamp 이외는 모두 keyword 타입으로 지정하라고 되어있는데 답안에는 response에 대한 타입 지정이 누락되었음

task 5

nested라는 새로운 type과 aggregation. 가이드 활용하면 크게 어렵지는 않았음

task 6

lab에서 실습한 내용과 거의 똑같은 문제라 금방 해결

task 7

remote cluster 등록에 문제가 있어 진행할 수 없었음

task 8

키바나로 조건에 맞추어 liftcycle policy를 만드는 자체는 금방 진행 matrics-mapping component template을 사용하라는 조건이 있는데, 이 매핑 템플릿을 작성하는 것에 대한 내용은 존재하지 않음 실습때도 어려워했고, 현재도 잘 못 따라가는 파트라 반복 필요

task 9

스냅샷을 restore해서 검색을 진행하는 문제 실습해 본 적은 없지만, 가이드 보고 따라할 수 있을 것 같음 실제 스냅샷이 서버에 존재하지는 않아 눈으로 보고 이해

task 10

검색할 때 사용할 수 있는 다양한 옵션들 종합 선물 세트 문제 다 문제 없이 잘 진행했고, 잘 안 써봐서 옵션이 헷갈렸던 highlight도 가이드 참고하여 진행하였음 다만, pagenation할 때, from을 시작 document 순서가 아니라 페이지 그 자체로 오해한 바람에 잘못된 숫자를 지정함 실전 때 이런 디테일에 신경쓸 것

#request
GET web_traffic/_search
{
  "size": 0,
  "aggs": {
    "status_code_buckets": {
      "terms": {
        "field": "http.response.status_code",
        "order": {
          "runtime.50": "asc"
        }
      },
      "aggs": {
        "runtime": {
          "percentiles": {
            "field": "runtime_ms",
            "percents": [
              50
            ]
          }
        }
      }
    }
  }
}

#response
...
...
  "aggregations" : {
    "status_code_buckets" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 230,
      "buckets" : [
        {
          "key" : "503",
          "doc_count" : 1821,
          "runtime" : {
            "values" : {
              "50.0" : 158.0
            }
          }
        },
        ...
        ...

runtime이라고 이름을 붙인 aggregation의 결과를 보면, runtime 내에 values가 있고, 또 이 내부에 50.0과 그 결과가 있는 구조임 이 결과를 활용해서 정렬을 진행하는 것이 문제의 핵심인데, request를 보면 runtime.50으로 활용하고 있는 것을 확인할 수 있음

내가 생각하기에는 활용하는 값은 runtime.values.50이 되어야 맞는 것 같았는데. runtime.10으로 변경해도 잘 작동하는 것을 확인함 percentiles aggregation은 데이터를 다 계산한 결과를 가지고 있고, 내가 그 중에서 어떤 데이터만 출력할지를 지정해주는 방식인 듯

GET _cat/indices?v에서 결과로 나오는 docs.deleted가 실제로 지금까지 해당 인덱스에서 지워진 document 개수인지 궁금해짐

5개의 document를 가진 인덱스를 임의 생성하고 GET _cat/indices?v 해보면 docs.count가 5개인 것을 확인 가능함 이후 하나의 document를 삭제한 후, 해당 인덱스에 match_all request를 날려 document 수가 4개인 것을 확인함 이후 다시 GET _cat/indices?v 해봤는데, 여전히 docs.count가 5개로 확인됨 실시간으로 인덱스들의 정보를 가져오는 것이 아니라 일정 시간마다 업데이트 하는 방식인 듯

어느 정도 지난 후 다시 GET _cat/indices?v 확인해보니, docs.count가 4개로 줄어들었음 그런데 의문인 점은, docs.deleted가 2개로 보인다는 것

위 내용 작성하다가 다시 궁금해진 내용

인덱스 별로 지금까지 삭제한 document 수를 저장하고 있는 것인지, 아니면 isDeleted 같은 안 보이는 필드가 있고, 삭제 처리된 document에 대해 그 필드 값이 true로 변경되는 방식으로, docs.deleted의 값은 이 필드가 true인 document들을 세는 것일지? 만약에 후자라면 삭제한 document의 복구도 비교적 쉽게 이루어질 수 있을 듯

  ...
  "highlight": {
    "pre_tags": ["<strong>"],
    "post_tags": ["</strong>"]
  }
  ...

[]로 감싸져 있어서 여러 개의 태그를 담을 수 있을 것이라고 생각했고, 아래처럼 작성해봄

  ...
  "highlight": {
    "pre_tags": ["<strong>", "<b>"],
    "post_tags": ["</strong>", "</b>"]
  }
  ...

그런데 여전히 결과는 <strong>, </strong> 태그로만 감싸져 나오고 <b>, </b> 태그는 보이지 않음

Painless 스크립트를 활용했을 때, 반환값을 볼 수 있는 방법은 없을까?

4.3장 solution 2에서는 값을 꺼낼 때, doc['url'].value로 꺼냈음 solution 3에서는 doc['authors.last_name']을 변수 authors에 저장해 둠 그리고 사용할 때, authors.get(숫자).startsWidh() 으로 사용함 구조를 잘 모르겠다.

내가 생각하기에는 3에서 -> 꺼낼 때 doc['authors.last_name'].value -> 혹은 사용할 때 authors.get(숫자).value.startsWidh() 위 두 경우 중 하나에 해당해야 맞는 것 같은데.

7.4장 sanpshot repository 만드는 데에서 자꾸 실패 실습 불가능

CCR 실습 결국 못해봄... 설정 관련된 내용을 공식 문서랑 자료에서 못 찾았다ㅠ 앞 부분 복습 후 리뷰타임 때에 yml 파일 관련 설정 질문 예정 CCR 하나에 매달리기보다 전체 복습 1번을 더 하자고 판단

profiler에서 self time이랑 total time의 차이점?

boosting의 두 가지 방법

• best_fields : default. 여러 필드들의 점수를 내고 그 필드들 중 가장 높은 점수를 가지고 있는 하나의 필드를 선택해 그 점수가 document의 score가 됨
• most_field : 여러 필드들의 점수를 내고, 그 점수들의 합계가 해당 document의 score가 됨

답안에는 PUT으로 되어있는데, POST로 작성해도 문제 없이 돌아가긴 함

t2_my_index에서 자료를 보면 하나밖에 안 들어있는데, Index Management 메뉴에서 보면 document가 2개로 뜸 하나는 뭘까?

blogs 인덱스도 자료 개수가 4719개로 뜨는데, Index Management에서 보면 두 배로 나옴 혹시 replica에 저장된 document 개수까지 해서 이렇게 나오는건가?

GET t2_blogs_fixed2/_search
{
  "size": 5, 
  "query": {
    "match_phrase": {
      "content": "open source"
    }
  },
  "sort": [
    {
      "publish_date": {
        "order": "desc"
      }
    }
  ],
  "_source": ["title", "publish_date"]
}

GET t2_blogs_fixed2/_search
{
  "size": 5, 
  "query": {
    "match_phrase": {
      "content": "open source"
    }
  },
  "_source": ["title", "publish_date"]
}

위 아래는 sort가 있는지 없는지만 다름 sort가 있을 때에는 score가 null인 것을 확인함 sort를 빼면 각 document에 맞는 score가 계산됨 정렬 방식을 내가 지정하면 score 계산을 따로 진행하지 않는 듯

GET t2_blogs_fixed2/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "meetups",
            "fields": ["title", "content"]
          }
        }
      ],
      "filter": [
        {
          "range": {
            "publish_date": {
              "gte": "now-3y"
            }
          }
        }
      ]
    }
  }
}

GET t2_blogs_fixed2/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "meetups",
            "fields": ["title", "content"]
          }
        }
      ],
      "filter": [
        {
          "range": {
            "publish_date": {
              "gte": "now/d-3y"
            }
          }
        }
      ]
    }
  }
}

위쪽 코드가 내가 작성한 방식, 아래쪽 코드가 solution 답안 검색할 자료의 기간을 설정할 때, now-3y인지 now/d-3y인지 표현 방식만 다름 결과는 동일한데, now/d의 정확한 의미가 궁금

match와 term의 차이가 뭘까? 같은 기능인데 단순히 must는 match, filter는 term을 쓰는건가? 기능이 같다면 두 가지 함수가 있는 이유는 score 계산의 유무 차이인가? score 계산을 할지 말지는 match, filter를 선언하는 순간 정해질텐데... 비슷한 고민을 했던 것 같은데 명확히 해결되지 않은 모양 질문 후 따로 정리할 것

pipeline 만들고 적용하고 하는 부분은 아직도 어색.. 4장 여러번 돌려야 할 듯

이름 겹치면 안 돌아갈 줄 알았는데 runtime_mappings를 통해서 이미 있던 필드 위에 타입을 일시적으로 덧씌울 수도 있음

significant_terms가 terms보다 상세한 정보가 나오는 것은 확인 그런데 bg_count는 뭘까?

  "aggregations" : {
    "top_OS" : {
      "doc_count_error_upper_bound" : 11,
      "sum_other_doc_count" : 38389,
      "buckets" : [
        {
          "key" : "Windows",
          "doc_count" : 517774,
          "top_urls" : {
            "doc_count" : 517774,
            "bg_count" : 1462658,
            "buckets" : [
              {
                "key" : "/blog/welcome-insight-io-to-the-elastic-team",
                "doc_count" : 38455,
                "score" : 0.058338717766485755,
                "bg_count" : 60841
              },
              {
                "key" : "/blog/configuring-ssl-tls-and-https-to-secure-elasticsearch-kibana-beats-and-logstash",
                "doc_count" : 7369,
                ...
                ...

POST t2-my-metrics/_rollover
{
  "conditions": {
    "max_age": "2s"
  }
}

GET t2-my-metrics

위 코드를 순서대로 실행하면, 현재 write 설정된 인덱스는 2초간만 유효하기 때문에 바로 다음 넘버링 인덱스가 생성된다. 그런데 이 설정이 계속 유지되는 건 아닌지 다음 넘버링이 나는 2초마다 생길 줄 알았는데, 한 번 생기고 그 다음 넘버링 인덱스가 생성되지 않는 것을 확인했다. 자동으로 매 시간마다 넘겨주거나 매 document의 수마다 넘겨주는 설정이 분명 있을텐데.

7.1장에서 aliases 실습으로 만든 인덱스들은 index management 화면에서 보였는데, 7.2장에서 data stream 실습으로 만든 인덱스들은 찾아볼 수가 없다... 왜?

PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval": "30s"
  }
}

poll interval이 정확히 어떤 것에 대한 간격인지 잘 모르겠음 일반적으로는 10분으로 설정한다는데, lifecycle에 대한 확인 시간인가?

7.3장 lifecycle 설정하는 부분 => 약간의 오차는 있지만 이건 서버적인 부분에서 발생할 수 있는 틱 차이라고 생각되는 짧은 시간이고, 새 인덱스가 잘 생성되고 이전 인덱스는 warm 단계로 잘 내려옴 그런데 warm 단계에서 cold 단계로 내려오는 과정이 전혀 관찰되지 않음 설정이 뭔가 잘못된건지 리뷰 시간에 확인이 필요

PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval": "30s"
  }
}

DELETE _data_stream/t2-my_metrics-service.status-dev

POST t2-my_metrics-service.status-dev/_doc
{
  "@timestamp": "2021-07-04",
  "status": "UP",
  "message": "Service is running."
}

GET t2-my_metrics-service.status-dev/_settings

GET t2-my_metrics-service.status-dev/_ilm/explain

빠른 테스트 위한 코드 모음

cluster2의 t1_blogs 상태

cluster1의 replicated_blogs 상태

CCR 정의

follower 인덱스도 primary, replica 각 1개씩인데 왜 health 상태도 안 뜨고 복제도 안 될까...ㅠ

8.3장의 6번 솔루션이 이해가 잘 되지 않음 should는 점수 계산에 영향을 미치지만 검색되는 자료의 수에는 영향을 미치지 않음 match 역시 점수 계산에 영향을 미치는 것은 같지만 결과에까지도 영향을 주는데... 뭘 어떻게 바꾸라는건지 잘 모르겠음 => should 내에서 match_phrase나 match나 결과는 크게 변하지 않지만 match_phrase가 상대적으로 연산 속도가 훨씬 느리기 때문에, 사용할 일이 있을 경우 match가 효율적

3단어 문장을 검색했을 때

• match_phrase : 1.3ms
• match : 각 단어에 0.1ms

GET web_traffic/_search
{
  "size": 0,
  "aggs": {
    "logs_by_week": {
      "date_histogram": {
        "field": "@timestamp",
        "calendar_interval": "hour"
      },
      "aggs": {
        "sum_bytes": {
          "sum": {
            "field": "bytes_sent"
          }
        },
        "the_movfn": {
          "moving_fn": {
            "buckets_path": "sum_bytes",
            "window": 5,
            "script": "MovingFunctions.unweightedAvg(values)"
          }
        }
      }
    }
  }
}

moving_fn이 어떤 역할을 하는지 잘 모르겠음

6.1의 7번 solution => node 3번이 보이지 않음 primary 1, 2번이 각각 node1, node2에 배치된것은 확인했는데, replicas는 왜 모두 unassigned인지 의문

_cat/shard?v&s=,,,&h=,,,에서 s,h가 각각 무슨 의미일까 => 하나씩 실행해보니, h는 어떤 항목을 표시할지 결정하는 부분 s는 sort. 어떤 기준으로 정렬할지 앞쪽부터 우선순위

GET _tasks?actions=*reindex&detailed runtime error 발생했을 때, 아직 해당 쿼리가 백그라운드에서 돌아가고 있을 수 있음 그 때에 돌아가고 있을 작업을 확인하는 것

아마 뒤에 reindex를 명시해서 _reindex 작업에 대한 디테일만 나오는 것 같은데, 다양한 옵션이 있을 것으로 예상 => 공부해볼 내용

document를 저장할 때, 어떤 샤드에 저장하는가는 랜덤? 아니면 규칙이 있나? => 질문할 것 ==> 기본적으로는 특정 알고리즘 (아마 라운드로빈)을 따름 내가 직접 어떤 샤드에 저장할 지 선택할 수도 있음

오늘 실습 전반적으로 이해 잘 되었으나 replica 샤드들이 전혀 배치되지 않는 것을 확인했음 내가 무언가 설정을 잘못한건지 뭔지... primary는 문제 없이 할당되는데 왜 모든 replica들이 unasigned로 표기될까

특정 필드만 필요한 경우에는 fields가 더 효율적

GET t2_blogs_fixed2/_search
{
  "query": {
    "match": {
      "content": {
        "query": "open source",
        "operator": "and"
      }
    }
  }
}

match는 기본적으로 or연산 수행 and연산을 위해서는 match내에 query를 한 번 더 작성해서 "operator": "and"로 연산자를 설정해야 함

구분자로 구분된 문자열 각각이 아니라 전체 문자열을 검색어로 사용하고 싶을 때에는 match 대신 match_phrase 사용

GET t2_blogs_fixed2/_search
{
  "query": {
    "multi_match": {
      "query": "meetups",
      "fields": ["title", "content"]
    }
  }
}

GET t2_blogs_fixed2/_search
{
  "query": {
    "range": {
      "publish_date": {
        "gte": "now-3y"
      }
    }
  }
}

GET t2_blogs_fixed2/_search # 에러 발생 코드
{
  "query": {
    "multi_match": {
      "query": "meetups",
      "fields": ["title", "content"]
    },
    "range": {
      "publish_date": {
        "gte": "now-3y"
      }
    }
  }
}

query 내에 multi_match나 range가 하나씩 들어있을 때에는 둘 다 에러 없이 잘 실행됨 그런데 두개를 같이 넣으면 에러 발생 두 개 이상의 쿼리를 한 번에 쓰려면 bool 사용

GET t2_blogs_fixed2/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "meetups",
            "fields": ["title", "content"]
          }
        }
      ],
      "filter": [
        {
          "range": {
            "publish_date": {
              "gte": "now-3y"
            }
          }
        }
      ]
    }
  }
}

위 코드에서 range가 must 내부에 작성되거나 multi-match가 filter 내부에 작성되어도 hits 수는 동일 다만, 검색어와 연관관계를 높이기 위해서 multi-match는 must에 작성하였고, 작성일자에 따라 그 연관성이 영향을 받는다고는 판단하지 않지만 기간이 명시되어 있었으므로 filter에 range를 작성함

1. content에 ingestion이 포함되고
2. content에 logstash가 포함되면 안 되며
3. 프랑스어로 작성된 내용(fr-fr)을 검색

   GET t2_blogs_fixed2/_search
   {
   "query": {
    "bool": {
      "must": [
        {
          "match": {
            "content": "ingestion" # ingestion을 포함
          }
        }
      ],
      "must_not": [
        {
          "match": {
            "content": "logstash" # logstash를 미포함
          }
        }
      ], 
      "filter": [
        {
          "match": {
            "locale": "fr-fr" # 프랑스어로 작성
          }
        }
      ]
    }
   }
   }

PUT _scripts/weekly_blogs
{
  "script": {
    "lang": "mustache",
    "source": {
      "query": {
        "bool": {
          "filter": [
            {
              "range": {
                "publish_date": {
                  "gte": "{{start_date}}",
                  "lte": "{{start_date}}||+1w"
                }
              }
            }
          ]
        }
      }
    }
  }
}

3.3장 2번 문제 템플릿 작성할 때에는 자동완성이 도와주지 않기 때문에 실제로 쿼리를 작성하고 그 부분만 옮겨다 넣는 것이 편한 듯 삭제는 아래처럼 진행

DELETE _scripts/weekly_blogs

pipeline 작성할 때, rename이나 remove에 ignore_missing 옵션의 역할을 잘 모르겠음 => 공부 필요 ignore_failure 옵션이 존재하던데, 실패했을 때 그 실패를 무시하려면 사용하는 옵션이라고 생각됨 => on_failure를 설정하면 오류가 발생했을 때 어떻게 다룰지를 설정할 수 있음 ignore_failure를 따로 설정하지 않으면 dafault로 false인 것 같고, on_failure가 정의되어 있지 않아도 기본 처리방식이 있는 것으로 보임

GET t2_blogs_fixed2/_search
{
  "size": 0,
  "aggs": {
    "NAME": {
      "terms": {
        "field": "category"
      }
    }
  }
}

POST categories/_bulk
{"create":{}}
{"uid": "blt26ff0a1ade01f60d","title":"User Stories"}
{"create":{}}
{"uid": "bltfaae4466058cc7d6","title": "Releases"}
{"create":{}}
{"uid": "bltc253e0851420b088","title": "Culture"}
{"create":{}}
{"uid": "blt0c9f31df4f2a7a2b","title": "News"}
{"create":{}}
{"uid": "blt1d90b8e0edce3ea9","title": "Engineering"}

PUT _enrich/policy/t2_categories_policy
{
  "match": {
    "indices": "categories",
    "match_field": "uid",
    "enrich_fields": ["title"]
  }
}

POST _enrich/policy/t2_categories_policy/_execute

순서대로 실행했을 때, 마지막에 enrich policy 실행하는 부분에서 런타임 에러가 발생... 왜? 그런데 이 정책으로 enrich 실행하는 자체는 잘 돌아갔음 뭘까 왤까 => 다음에 다시볼것

# Request
GET t2_blogs_fixed2/_search
{
  "size": 0,
  "runtime_mappings": {
    "authors.uid": {
      "type": "keyword"
    }
  },
  "aggs": {
    "top_uids": {
      "terms": {
        "field": "authors.uid"
      }
    }
  }
}

# Response
{
  "took" : 488,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 4659,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "top_uids" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 4722,
      "buckets" : [
      ....
      ...
      ...

}

전체 자료 개수는 4659개 authors.uid라는 필드를 런타임 동안에 작성하였지만 내용이 아무것도 없을 것이기 때문에 aggregation이 진행되는 것은 하나도 없을 것으로 예상 => 전체 조회와 동일하게 4659개의 bucket이 나오는 것이 맞다고 생각함 그런데 결과에서 보이는 sum_other_doc_count가 4722개 이게 뭘까?

mapping에서 분석기 만들어놓고, 필드 타입이랑 분석기를 지정해 줬는데도 document를 넣으면 keyword랑 다를 바 없이 "We love X-Pack"가 그대로 저장되는 것을 확인 => 우리한테 보여줄 때에는 그렇게 보이고, analysis는 내부적으로 실행되어 그 결과는 따로 가지고 있는 것! 그래서 어떻게 분석되는지 확인할 때 쓰는 것이 "_analyze" API

PUT 인덱스이름 # 아무것도 없는 빈 인덱스 생성

PUT 인덱스이름/_mapping # 빈 인덱스에 매핑 추가 가능

PUT 인덱스이름 # 위 두 번의 요청과 이 한 번의 요청은 동일한 결과
{
    "mapping": {
        ...
    }
}

새 인덱스로 reindex

POST _reindex
{
    "source": {
        "index": "원본 인덱스"
    },
    "dest": {
        "index": "목표 인덱스"
    }
}

인덱스 내 document 개수 확인

GET 인덱스이름/_count

HTML 태그 제거하는 char_filter는 html_strip

query나 aggregation에 사용하지 않을 필드는 doc_values를 false로 해두면 저장공간을 절약할 수 있음

PUT 인덱스이름
{
    "mappings": {
        "properties": {
            "필드명": {
                "doc_values": false
            }
        }
    }
}

실습 페이지 Lab 2.4의 1번 solution 결과로 _search 했을 때 search_tags에 tags의 모든 필드가 나오지 않는 점이 의문 => document를 indexing할 때 설정하지 않은 필드는 결과에서도 보여주지 않기 때문 빈 배열로 나오는 필드는 빈 배열이 indexing할 때 값으로 있었던 것

"doc_values": false와 "enabled": false는 모두 query와 aggregation에 사용할 수 없음 => 그럼 왜 두 개의 약속어가 존재하는지 의문

doc_values: false

• query, aggregation에 사용할 수 없음 (오류 발생)
• 필드에 대한 검색은 가능

enabled: false

• query, aggregation에 사용할 수 없음 (결과값이 0)
• object type에 사용하며, 상위 필드에서 선언하면 그 하위 필드들까지 모두 enabled가 false로 설정됨
• 현재는 사용하지 않는 옵션

(추가) index: false

• query, aggregation에 사용할 수 없음
• 필드에 대한 검색도 불가능
• enabled 대신 사용 가능

# Response
{
    "tokens":
    [
        {
            "token": "tuning",
            "start_offset": 0,
            "end_offset": 6,
            "type": "<ALPHANUM>",
            "position": 0
        },
        {...},
        ...
        {
            "token": "123", # NUM 타입인데 왜 문자열처럼 ""으로 감싸져 나올까
            "start_offset": 25,
            "end_offset": 28,
            "type": "<NUM>",
            "position": 6
        }
    ]
}

# analyzer 설정
PUT blogs_test
{
  "settings": {
    "analysis": { # 분석 관련된 내용을 정의하는 곳
      "char_filter": { # 문자에 대한 필터를 작성하겠다고 선언
        "my_filter": {
          "type": "mapping",
          "mappings": ["X-Pack => XPack"]
        }
      },
      "analyzer": { # 사용할 분석기에 대한 설정
        "my_content_analyzer": {
        # 이 안에 순서를 바꿔봤는데, 결과가 달라지진 않았음
        # 내부 순서가 적용되는 순서에 영향을 미치지는 않는 듯
          "type": "custom", # 존재하는 규칙 사용하지 않겠다고 명시
          "char_filter": ["my_filter"], # 문자열 필터에 위에서 정의한 필터 가져옴
          "tokenizer": "standard", # 기본 방법으로 토큰 구별
          "filter": ["lowercase"] # 이후 모두 소문자로 변경
        }
      }
    }
  }
}

# Request
POST blogs_test/_analyze #blogs_test
{
  "text": "We love X-Pack",
  "analyzer": "my_content_analyzer"
}

# Response
{
  "tokens": [
    {
      "token": "we",
      "start_offset": 0,
      "end_offset": 2,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "love",
      "start_offset": 3,
      "end_offset": 7,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "xpack",
      "start_offset": 8,
      "end_offset": 14,
      "type": "<ALPHANUM>",
      "position": 2
    }
  ]
}

클러스터, 노드는 논리적인 개념이지 물리적인 개념이 아님 한 서버에 노드를 여러 개 올릴 수 있지만 서버 스펙이 좋아도 하나만 올릴 것이 권장됨 => 디스크를 공유하는 데에 있어서 속도가 영향을 받음

Shard

샤드는 Lucene의 한 인스턴스이다 = 샤드 하나하나가 모두 검색 엔진이다 하나당 20GB를 넘어가지 않도록 구성해야 함

replica shard를 유지하는 이유

• 여러 노드에 분산 저장하여 검색, 색인을 병렬화 => 속도 향상
• 노드 하나에 문제가 생겼을 때, 사본을 가지고 있는 다른 노드로 인해 장애 없이 유지 가능
• primary shard가 손실되면 replica 중 하나가 primary로 승격되어 유지

Shard overallocation

static data

샤드의 수를 넉넉하게 잡아놓고 읽기/쓰기 작업에 대한 병렬화를 진행 => overallocation

time-series data

분산하여 저장해놓고 따로 쓰거나 따로 읽거나 할 일이 거의 없음 단위별로 인덱스를 따로 만드는 편이 더 유용함 => overallocation보다는 multiple indices가 적합

filter

필터는 캐시에 올라가 있는 데이터를 활용하기 때문에 속도가 빠름 => 사용 권장!

index.refresh_interval

index.refresh_interval은 document가 indexing된 후 검색에 반영되기까지 걸리는 시간 -1로 설정하는 경우, indexing이 진행되는 동안 반영되지 않다가 작업이 종료되면 default 설정으로 돌아감 길게 설정하면 indexing 속도는 빨라지지만 검색에 반영되려면 오래 기다려야 함

Data stream

aliases와 거의 유사하나 그보다 한 단계 더 자동화 되어있음

backing indices

data stream은 여러 인덱스로 구성된 개념 이 중에 실제로 write 작업이 수행되는 인덱스는 하나만 존재 이 write가 수행되는 인덱스 이외의 인덱스들을 backing indices라고 함

오래 걸리는 query나 aggregation에 대해

1. 진행 상황을 모니터링 하거나
2. 부분적인 결과 상황을 확인할 때 사용

Changing data

Reindex

원본 index가 있고, 그 인덱스에서 파생된 사본을 만드는 것 전체 document를 대상으로 하지 않고 일부만을 활용하고 싶을 때에는 max_docs 나 query를 활용할 수 있음 한 클러스터에서 다른 클러스터로의 인덱스 복제도 가능

Update by Query

한 index 내에서 document를 수정하는 것 내용 수정 -> 저장 (x) 삭제 -> 재등록 (o) => document가 등록된 이후 indexing 절차가 달라졌을 수도 있기 때문에, 이런 내용을 반영하기 위해서 삭제했다가 다시 재등록하는 과정을 거침

Enrichment

RDB의 join과 유사한 개념 검색이 이루어질 때 join이 발생하면 데이터를 처리하는 과정이 추가되는 것이므로 속도가 느려질 수 있음 그래서 애초에 document가 indexing될 때, 필요한 내용을 다 끌어오는 것을 enrich라고 함

Denormalization

데이터를 저장할 때, 관계성에 중점을 두지 않고 하나의 index에 가능한 모든 정보를 담아두는 것 Elasticsearch의 외부에서 혹은 내부에서 모두 가능하지만, 내부에서 이루어지면 당연히 처리하는 과정이 추가되므로 속도에 영향을 줌 => 외부에서 처리를 마치고 오는 것이 이상적

Runtime fields

index에는 존재하지 않지만 query를 실행하는 순간 생성되어 search, aggregation 등의 작업이 가능한 필드 실행되어 결과를 보여주고 난 이후에는 다시 사라짐 (저장되지 않음)

Painless script

요청을 수행할 때 작업할 추가적인 내용들을 작성하기 위한 Elasticsearch의 언어 작업 중에 수행되므로 작업의 속도를 늦출 수 있음 임시 방편으로, 가능하면 사용하지 않고 reindexing하거나 update하는 것이 좋음

Significant aggregation

필드의 타입에 따라 두 가지 옵션이 존재

• significant_terms : keyword 필드에 사용
• significant_text : text 필드에 사용

대량의 문서 내에서 작업하기 힘들 수 있으므로 표본을 만들 수 있는 sampler aggregation을 진행한 후, 그 내부에서 사용하기가 권장됨

Transforming data

대량의 데이터에서 매번 정보를 요약해오는 것은 부담이 될 수 있는 작업 => 요약본을 미리 마련해두어 별도의 index에 유지하는 것이 transform

pivot

transform의 종류 중 하나 원본 테이블에 대해 필요한 정보를 어떻게 요약할지 정의하여 유지

Continuous mode

원본 index에 document가 들어올 때, pivot에도 해당 document에 대한 정보가 들어옴 원본 index를 체크하는 시간 주기를 설정 가능 (최대 1시간)

Retention policy

오래된 document에 대한 내용을 어떻게 처리할지 설정 가능

Latest

최신 내용만 가지고 있으면 되는 경우에 선택할 수 있는 transform 종류 새로은 document가 들어오면 기존 내용 대신 해당 내용을 보관하게 됨

기본 개념

맨 꼭대기에 있는 cluster, 그 아래로 각 실행흐름인 node, 그 아래 RDB의 테이블과 비슷한 개념으로 생각할 수 있는 index가 존재

클러스터는 여러 개가 존재할 수 있으며, 각 클러스터가 논리적으로 분리됨 클러스터끼리 데이터를 주고 받는 식으로 통신이 가능

클러스터 아래에 노드는 여러 개가 달려있을 수 있음 노드는 하나의 Instance라고 부름

노드 아래에 존재하는 개념인 인덱스는 테이블과 유사하다고 볼 수 있음 DB에는 Insert를 한다면, Index에는 Indexing을 함 DB의 row는 Index의 document

엘라스틱의 데이터 구분

Static data

• 증량은 적고, 그에 비해 업데이트가 잦은 데이터
• 코드성 테이블
• 정형화된 데이터에 적합

Time series data

• 업데이트는 거의 없지만, 증량이 빠른 데이터
• log와 같이 insert가 계속 되는 것

Query option

• Lucene(루씬) Elastic Search의 기반이 되는 검색 엔진
• Query DSL Elastick Search에서 가장 유연하게 사용할 수 있는 query

Keyword vs text

Text

• 인덱싱이 발생하는, 필드의 데이터 타입
• 원본 문자열을 가공하기 때문에 검색이 필요한 경우 적합

Keyword

• 인덱싱이 발생하지 않는 원본 문자열
• aggregation을 위해 사용하는 경우가 많음

mapping

RDB에서 테이블을 정의하는 것과 같은 동작 mapping은 index를 정의함 = index의 스키마를 정하는 것이 mapping

dynamic templates

정의되지 않은 필드에 document를 인덱싱하려고 하면 Elastic Search는 동적으로 매핑을 진행해줌 (그다지 권장되지는 않음) 이 때, 동적으로 매핑이 발생하더라도 그에 대한 어느 정도의 기반을 마련해 주는 것이 dynamic templates 정의하지 않아도 dynamic mapping은 발생하지만, 정의된 틀에 맞는 경우에는 어느 정도 대비할 수 있게 됨

Score

• score : 조건에 맞는 결과들에 점수를 매겨 유사도 혹은 유용도를 수치화한 것
• Elastic Search는 default로 BM25 알고리즘을 사용하여 score를 매김
• score의 3요소
  • TF(term frequency)
    • 검색한 단어가 나타나는 빈도가 높다면 점수를 높게 계산
    • 하나의 문서 내에서 적용하는 규칙
  • IDF(inverse document frequency)
    • 검색한 단어가 나타나는 빈도가 높다면 점수를 낮게 계산
    • 여러 개의 문서에 대해서 적용하는 규칙
  • field length
    • 더 짧은 필드에 대해 더 높은 점수를 부여