# ESE

jyo____c

constant keyword 필드를 data stream 인덱스에 설정해두면 rollover 될 때마다 가장 처음 들어오는 document에 의해 그 값이 결정됨 default로 rollover 되어도 같은 값을 유지하게 할 수 있음 -> 모든 인덱스가 같은 값을 가진다면, 무슨 의미가 있는지? 어떤 상황에 주로 사용하는지? 예시가 잘 상상이 안 됨. 질문할 것 7.4장 sanpshot repository 만드는 데에서 자꾸 실패 실습 불가능 CCR 실습 결국 못해봄... 설정 관련된 내용을 공식 문서랑 자료에서 못 찾았다ㅠ 앞 부분 복습 후 리뷰타임 때에 yml 파일 관련 설정 질문 예정 CCR 하나에 매달리기보다 전체 복습 1번을 더 하자고 판단 profiler에서 self time이랑 total time의 차이점? boosting의 두 가지 방법 best_fields : default. 여러 필드들

jyo____c

1.2장 solution2번 답안에는 PUT으로 되어있는데, POST로 작성해도 문제 없이 돌아가긴 함 t2myindex에서 자료를 보면 하나밖에 안 들어있는데, Index Management 메뉴에서 보면 document가 2개로 뜸 하나는 뭘까? ![](https://velog.velcdn.com/images/jyo__c/po

jyo____c

aliases 실습 과정 중에서 궁금한 점이 생겼다. 위 코드를 순서대로 실행하면, 현재 write 설정된 인덱스는 2초간만 유효하기 때문에 바로 다음 넘버링 인덱스가 생성된다. 그런데 이 설정이 계속 유지되는 건 아닌지 다음 넘버링이 나는 2초마다 생길 줄 알았는데, 한 번 생기고 그 다음 넘버링 인덱스가 생성되지 않는 것을 확인했다. 자동으로 매 시간마다 넘겨주거나 매 document의 수마다 넘겨주는 설정이 분명 있을텐데. 7.1장에서 aliases 실습으로 만든 인덱스들은 index management 화면에서 보였는데, 7.2장에서 data stream 실습으로 만든 인덱스들은 찾아볼 수가 없다... 왜? poll interval이 정확히 어떤 것에 대한 간격인지 잘 모르겠음 일반적으로는 10분으로 설정한다는데, lifecycle에 대한 확인 시간인가? 7.3장 lifecycle 설정하는 부분 => 약간의 오차는 있지만 이건 서버적인 부분

jyo____c

5.3의 5번 solution 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 작업에 대한 디테일만 나오는 것 같은데, 다양한 옵션이 있을 것으로 예상 => 공부해볼 내용 -

jyo____c

_source는 따로 설정해주지 않으면 default로 원본 자료의 모든 필드가 이 안에 담겨서 출력 "_source": ["필드명", ...]으로 어떤 필드만 담을지 선택할 수도 있음 "_source": false로 설정하면 해당하는 document의 인덱스 명과 id만 출력 특정 필드만 필요한 경우에는 fields가 더 효율적 match는 기본적으로 or연산 수행 and연산을 위해서는 match내에 query를 한 번 더 작성해서 "operator": "and"로 연산자를 설정해야 함 구분자로 구분된 문자열 각각이 아니라 전체 문자열을 검색어로 사용하고 싶을 때에는 match 대신 match_phrase 사용 query 내에 multi_match나 range가 하나씩 들어있을 때에는 둘 다 에러 없이 잘 실행됨 그런데 두개를 같이 넣으면 에러 발생 두 개 이상의 쿼리를 한 번에 쓰려면 `bool

jyo____c

mapping에서 분석기 만들어놓고, 필드 타입이랑 분석기를 지정해 줬는데도 document를 넣으면 keyword랑 다를 바 없이 "We love X-Pack"가 그대로 저장되는 것을 확인 => 우리한테 보여줄 때에는 그렇게 보이고, analysis는 내부적으로 실행되어 그 결과는 따로 가지고 있는 것! 그래서 어떻게 분석되는지 확인할 때 쓰는 것이 "_analyze" API 새 인덱스로 reindex 인덱스 내 document 개수 확인 HTML 태그 제거하는 charfilter는 htmlstrip query나 aggregation에 사용하지 않을 필드는 doc_values를 false로 해두면 저장공간을 절약할 수 있음 실습 페이지 Lab 2.4의 1번 solution 결과로 search 했을 때 searchtags에 tags의 모든 필드가 나오지 않는 점이 의문 => document를 i

jyo____c

개념 추가 클러스터, 노드는 논리적인 개념이지 물리적인 개념이 아님 한 서버에 노드를 여러 개 올릴 수 있지만 서버 스펙이 좋아도 하나만 올릴 것이 권장됨 => 디스크를 공유하는 데에 있어서 속도가 영향을 받음 Shard 샤드는 Lucene의 한 인스턴스이다 = 샤드 하나하나가 모두 검색 엔진이다 하나당 20GB를 넘어가지 않도록 구성해야 함 replica shard를 유지하는 이유 여러 노드에 분산 저장하여 검색, 색인을 병렬화 => 속도 향상 노드 하나에 문제가 생겼을 때, 사본을 가지고 있는 다른 노드로 인해 장애 없이 유지 가능 primary shard가 손실되면 replica 중 하나가 primary로 승격되어 유지 Shard overallocation static data 샤드의 수를 넉넉하게 잡아놓고 읽기/쓰기 작업에 대한 병렬화를 진행 => overallocation time-series data 분산하여 저장해놓

jyo____c

Async search 오래 걸리는 query나 aggregation에 대해 진행 상황을 모니터링 하거나 부분적인 결과 상황을 확인할 때 사용 Changing data Reindex 원본 index가 있고, 그 인덱스에서 파생된 사본을 만드는 것 전체 document를 대상으로 하지 않고 일부만을 활용하고 싶을 때에는 max_docs 나 query를 활용할 수 있음 한 클러스터에서 다른 클러스터로의 인덱스 복제도 가능 Update by Query 한 index 내에서 document를 수정하는 것 내용 수정 -> 저장 (x) 삭제 -> 재등록 (o) => document가 등록된 이후 indexing 절차가 달라졌을 수도 있기 때문에, 이런 내용을 반영하기 위해서 삭제했다가 다시 재등록하는 과정을 거침 Enrichment RDB의 join과 유사한 개념 검색이 이루어질 때 join이 발생하면 데이터를 처리하는 과정이 추가되는 것이

jyo____c

Elastic Search는 검색, 분석을 위한 엔진 기본 개념 맨 꼭대기에 있는 cluster, 그 아래로 각 실행흐름인 node, 그 아래 RDB의 테이블과 비슷한 개념으로 생각할 수 있는 index가 존재 클러스터는 여러 개가 존재할 수 있으며, 각 클러스터가 논리적으로 분리됨 클러스터끼리 데이터를 주고 받는 식으로 통신이 가능 클러스터 아래에 노드는 여러 개가 달려있을 수 있음 노드는 하나의 Instance라고 부름 노드 아래에 존재하는 개념인 인덱스는 테이블과 유사하다고 볼 수 있음 DB에는 Insert를 한다면, Index에는 Indexing을 함 DB의 row는 Index의 document 엘라스틱의 데이터 구분 Static data 증량은 적고, 그에 비해 업데이트가 잦은 데이터 코드성 테이블 정형화된 데이터에 적합 Time series data 업데이트는 거의 없지만, 증량이 빠른 데이터 log와 같