아빠는 개발자

nested 와 object 구조에서 aggregation 테스트를 해보자 동일한 데이터를 색인하는데 nested 구조에서 index의 크기가 증가하고 docs 가 늘어난다.   100만개 색인..  목표는 1000 만개였으나 데이터를 랜덤 숫자로 생성하는데도 시간이 꽤 오래 걸렸다..그래서 중간에 멈추고 리프레시 실행     인덱스 생성 쿼리nested index{ "settings": { "number_of_shards": {SHARD_SIZE}, "number_of_replicas": 0 }, "mappings": { "dynamic": "true", "_source": { "enabled": "true" }, "properties": { "n..

음... 저번에 작성중이던 글이 싹 날아갔네 ..초심으로 돌아가서 다시 작성해보잣... 상품은 n 개의 promotion 에 등록될 수 있고  promotion 에는 m 개의 theme 가 등록될수 있다. 결론은 하나의 상품은 n x m 의 개의  promotion theme 에  등록될 수 있는것이다.  문제 1상품이 등록된 유효한 테마의 No 를 구해야 한다. 해결방법1. promotion_theme 번호를 연결해서 배열로 색인 후에 .. 후처리?..  머.. 후처리가 들어간다면 안되는게 어딨겠나..api 의 응답속도나 이것저것 했을때 후처리를 좋아하진 않는 편이라 Pass  2. object 구조로 promos.promo 와 promos.theme 를 색인해서 필터를 promo 로 걸고 aggreg..

인덱스 복사 # -*- coding: utf-8 -*- import time import json import datetime as dt from datetime import datetime from elasticsearch import Elasticsearch from elasticsearch.helpers import bulk import requests import ssl import urllib3 from time import sleep from urllib import parse from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor print(ssl.OPENSSL_VERSION) urllib3.disable_warnings..

Elasticsearch의 hot_threads API는 클러스터 내에서 CPU가 높게 사용되는 스레드 정보를 제공하는 엔드포인트입니다. 이를 통해 어떤 작업이 CPU를 많이 사용하고 있는지를 식별하고 성능 이슈를 해결할 수 있음 Hot Threads API 사용 방법: cURL을 사용한 기본 사용법 curl -X GET "localhost:9200/_nodes/hot_threads?pretty" 위 명령은 로컬 호스트의 9200번 포트에서 실행 중인 Elasticsearch에 연결하고, 각 노드의 hot threads 정보를 출력. 위 명령은 각 노드에서 상위 5개의 hot threads만 출력합니다. threads 파라미터를 사용하여 출력할 스레드의 수를 조절할 수 있음 curl -X GET "loc..

전체 클러스터 재시작 및 순차적 재시작 전체 클러스터 다시 시작 또는 롤링 다시 시작을 수행하려는 상황이 있을 수 있습니다 . 전체 클러스터 재시작 의 경우 클러스터의 모든 노드를 종료하고 다시 시작하는 반면 , 롤링 재시작 의 경우 한 번에 하나의 노드만 종료하므로 서비스가 중단되지 않습니다. 전체 클러스터 다시 시작 1. 샤드 할당을 비활성화합니다. Disable shard allocation. 노드를 종료하면 할당 프로세스는 index.unassigned.node_left.delayed_timeout해당 노드의 샤드를 클러스터의 다른 노드에 복제하기 시작하기 전에(기본적으로 1분) 기다립니다. 이 작업에는 많은 I/O가 포함될 수 있습니다. 노드가 곧 다시 시작될 예정이므로 이 I/O는 필요하지 않..

빠른 요약 multi_match 쿼리 구조는 analyzer 의 영향을 받는다 쿼리 유형 multi_match 쿼리가 내부적으로 실행되는 방식은 다음과 같이 설정할 수 있는 매개변수에 multi_match따라 다릅니다 best_fields ( 기본값 ) 모든 필드와 일치하지만 _score가장 적합한 필드의 문서를 사용하는 문서를 찾습니다. most_fields 모든 필드와 일치하는 문서를 찾아 _score각 필드의 문서를 결합합니다. cross_fields analyzer필드를 하나의 큰 필드인 것처럼 동일하게 처리합니다 . 모든 필드 에서 각 단어를 찾습니다 phrase match_phrase각 필드에 대해 쿼리를 실행 하고 _score 가장 적합한 필드를 사용합니다 phrase_prefix match..

검색 결과 리스팅은 Query Cache에, 검색 결과에 대한 집계 는 Request Cache 에 저장 된다 그렇다면 둘다 확인해서 multi_match + aggs 의 결과가 어디에 캐싱된건지 확인 GET /location-index/_stats/query_cache?human { "_shards": { "total": 2, "successful": 2, "failed": 0 }, "_all": { "primaries": { "query_cache": { "memory_size": "0b", "memory_size_in_bytes": 0, "total_count": 0, "hit_count": 0, "miss_count": 0, "cache_size": 0, "cache_count": 0, "evic..

file system cache 를 이용한.. 꼼수를 부려보자 기존쿼리 + AGGS 를 사용하는데 file system cache 를 이용할 수 가 없다. 왜냐..면 size 가 0이 될 수 없는 상황.. 그래서 AGGS size 0을 먼저 실행하고 그다음 검색쿼리를 실행하면 캐싱을 이용하지 않을까 하는 생각이 있는데 테스트를 해보자 location 정보를 색인할 예정이고 "country_code": { "type": "keyword" }, "city": { "type": "keyword" }, city 를 집계하고 country code 를 쿼리한다. 이게 가능한가? aggs name 으로 캐시가 생성되면 가능할꺼 같기도 한데.. aggs 결과를 쿼리결과와 합치지 않아도 된다면 후 처리 로직이 더 줄어..

전역 서수는 집계 성능을 최적화하는 데 사용되는 데이터 구조입니다. 이는 느리게 계산되어 필드 데이터 캐시의 일부로 JVM 힙에 저장됩니다. 버킷팅 집계에 많이 사용되는 필드의 경우 요청을 수신하기 전에 Elasticsearch에 전역 서수를 구성하고 캐시하도록 지시할 수 있습니다. 힙 사용량이 증가하고 새로 고침 시간이 더 오래 걸릴 수 있으므로 이 작업은 신중하게 수행해야 합니다. 이 옵션은 Eager 전역 서수 매핑 매개변수를 설정하여 기존 매핑에서 동적으로 업데이트될 수 있습니다. 맵핑 옵션 PUT index { "mappings": { "properties": { "foo": { "type": "keyword", "eager_global_ordinals": true } } } } 테스트 해보자 ..

검색 속도 조정 파일 시스템 캐시에 메모리 제공 더 빠른 하드웨어 사용 문서 모델링 가능한 한 적은 수의 필드를 검색 사전 색인 데이터 매핑 식별자를 키워드로 고려 스크립트 피하기 반올림된 날짜 검색 읽기 전용 인덱스 강제 병합 글로벌 서수 워밍업 색인 정렬을 사용하여 접속사 속도를 높임 기본 설정을 사용하여 캐시 활용도 최적화 복제본은 처리량에 도움이 될 수 있지만 항상 그런 것은 아님 회사에서 성능 이슈를 제기했다. elasticsearch 의 캐싱을 정리하려고 하는데 쿼리속도가 문제가 아닌걸 알지만 우선 es 레벨에서 캐싱으로 처리할 수 있는 부분을 정리 우선 속도에 영향을 미치는 부분은 The more fields a query_string or multi_match query targets, t..