일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- license delete
- sort
- token filter test
- zip 파일 암호화
- License
- MySQL
- licence delete curl
- matplotlib
- ELASTIC
- Kafka
- query
- plugin
- springboot
- Python
- Test
- aggregation
- zip 암호화
- Java
- docker
- aggs
- flask
- analyzer test
- Mac
- API
- 900gle
- 차트
- TensorFlow
- high level client
- Elasticsearch
- 파이썬
- Today
- Total
목록ElasticStack (108)
개발잡부
검색 결과 리스팅은 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 를 쿼리한다. flowchart 이게 가능한가? 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..
불용어 (stopword) 필터를 사용해 analyzer 에서 불용어를 걸러낼 수는 있지만.. 이 no result 케이스에서 불용어때문에 걸러진건지 실제 true 인 데이터가 없는건지 알아내야 한다.. 왜냐..면 이 케이스에서 확장검색이 들어가야 하는데 이 확장검색이란 놈이 operator 가 or 이기때문에 조합형 불용어 에서는 정밀도가 떨어지는 검색결과가 나오게 되어 이 케이스를 없애달라는.. 원하는건 불용어를 포함한 검색어 일때 no result 처리 주의할점! 은 스크립트를 사용하면 검색속도가 느려질 수 있다. 암튼.. 일단 만들어 보자 es 는 8.8.1 버전에서 키바나와 es 만 실행 #내 로컬 경로 cd /Users/doo/docker/es8.8.1 docker compose es kiba..
정규식 쿼리 쿼리구조는 아래와 같고 GET /_search { "query": { "regexp": { "user.id": { "value": "k.*y", "flags": "ALL", "case_insensitive": true, "max_determinized_states": 10000, "rewrite": "constant_score" } } } } 옵션값 설명 (필수, object) 검색하고자 하는 필드입니다. value (필수, 문자열) 제공된 에서 찾으려는 용어에 대한 정규식입니다 . 지원되는 연산자 목록은 정규식 구문 을 참조하십시오 . 기본적으로 정규식은 1,000자로 제한됩니다. 설정 을 사용하여 이 제한을 변경할 수 있습니다 index.max_regex_length . 쿼리 성능은 re..
collapse매개변수를 사용하여 필드 값을 기준으로 검색 결과를 축소 할 수 있습니다 . 축소는 축소 키당 최상위 정렬된 문서만 선택하여 수행됩니다. GET hyper-item/_search { "_source": [ "docId", "itemNo", "itemStoreInfo.eventInfo" ], "query": { "exists": { "field": "itemStoreInfo.eventInfo" } }, "collapse": { "field": "itemNo" } }
목표 QueryString 쿼리를 OR 검색조건으로 추가해서 재현율을 개선 작업방향 AS-IS Query > bool > must > multi_match 에서 Query > bool >must > bool > should > bool > must > multi_match OR Query > bool > must > bool > should > bool > must > query_string 로 변경 쿼리 구조 추가 개선 작업 재현율은 올라갔으나 정밀도를 올려야 함 추가 작업 tokenizer 테스트 : 검색결과의 노출기준을 term 의 매칭 수로 판단 정밀도를 올리기 위해 토근 분해의 디테일을 올린다. analyzer 테스트 : 1번테스트에서 유의미한 결과를 보이는 tokenizer 를 포함한 anal..
itemNm 에서 실패검색어를 기반으로 조회 했을때 유의미한 데이터를 추출한다. 띄어쓰기 영향 X 공백기준 앞뒤 순서 영향 X 위의 조건을 고려하여 적합한 쿼리 구현 후보 1. wildcard *{keyword}* 의 경우 단일 단어에서는 유의미한 결과가 나오지만 공백을 포함한 단어에서는 재현율이 좋지 않음 후보 2. query_string 작업의 의도에 가장 부합하는 결과를 도출할 수 있음. query result 후보 3. match 동일한 키워드에서 무의미한 데이터 같이 추출 됨