일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- licence delete curl
- token filter test
- docker
- 파이썬
- matplotlib
- API
- TensorFlow
- Java
- ELASTIC
- license delete
- 차트
- sort
- flask
- Elasticsearch
- 900gle
- high level client
- Python
- Mac
- MySQL
- aggregation
- springboot
- License
- zip 암호화
- Kafka
- aggs
- analyzer test
- plugin
- Test
- query
- zip 파일 암호화
- Today
- Total
목록분류 전체보기 (475)
개발잡부
normalizer - keyword 필드는 애널라이저를 사용하지 않는 대신 노멀라이저(normalizer) 의 적용이 가능 - 노멀라이저는 애널라이저와 유사하게 settings 에서 정의하며 토크나이저는 적용할 수 없고 캐릭터 필터와 토큰 필터만 적용해서 사용이 가능함 실무 적용 케이스 요구사항 대소문자 구분 없이 검색 가능 띄어쓰기 상관없이 검색가능 대소문자, 띄어쓰기 상관없이 exact 매칭 테스트 ) normalizer 가 세팅된 index 생성 searchWord 필드에 doo_normalizer 맵핑 PUT doocoo { "settings": { "analysis": { "normalizer": { "doo_normalizer": { "type": "custom", "char_filter":..
일단 삽질 부터 정리를 하자면.. 왜 삽질을 정리하냐 물어보신다면.. "결과가 좋지 않으니 시간낭비를 하지 말자" 라는 의미로 첨에 성능개선의 방향을 메소드 별 캐싱, 즉 동적인 결과를 반환하는 메소드 외에 검색키워드에만 영향을 받아 캐싱이 되어도 무방한 정적인 데이터를 처리하는 메소드를 캐싱 해버린다. 이렇게 캐싱할 메소드를 정해놓고 데이터 처리 하는 로직을 component 에 이관하고 component 를 캐싱하려고 했으나.. 메소드 캐싱을 할수록 시간이 증가하는 기적이 .. 20~50ms 씩 증가.. 위의 구조라면 저것들을 다 캐싱하는 순간.. 그래서 캐싱은 1번으로 끝내고 가능하다면 최전방으로 배치한다. 의 전략 최초 호출인 /search 의 호출을 캐싱해버리는.. /search 호출은 상품정보..
빠른 요약 multi_match 쿼리 구조는 analyzer 의 영향을 받는다 쿼리 유형 multi_match 쿼리가 내부적으로 실행되는 방식은 다음과 같이 설정할 수 있는 매개변수에 multi_match따라 다릅니다 best_fields ( 기본값 ) 모든 필드와 일치하지만 _score가장 적합한 필드의 문서를 사용하는 문서를 찾습니다. most_fields 모든 필드와 일치하는 문서를 찾아 _score각 필드의 문서를 결합합니다. cross_fields analyzer필드를 하나의 큰 필드인 것처럼 동일하게 처리합니다 . 모든 필드 에서 각 단어를 찾습니다 phrase match_phrase각 필드에 대해 쿼리를 실행 하고 _score 가장 적합한 필드를 사용합니다 phrase_prefix match..
페이지 캐시 - 쿼리에서 실제로 읽은 이 데이터의 양에 관계없이 데이터를 캐시 페이지 캐시의 기본 개념은 디스크에서 데이터를 읽은 후 사용 가능한 메모리에 데이터를 넣는 것 다음 읽기는 메모리에서 반환되고 데이터를 가져오는 데 디스크 탐색이 필요 없음 샤드레벨 요청캐시 - 유사한 쿼리를 사용할 때 데이터를 캐시 집계로만 구성된 검색 응답을 캐싱 구성 요소는 IndicesRequestCache 클래스 - 이 메서드는 쿼리 단계를 실행할 때 SearchService 내에서 사용 이 캐시는 기본적으로 활성화되어 있고, 총 힙의 최대 1%를 차지 요청별 구성 -요청 매개 변수를 통해 캐시를 활성화 결과를 반환하지 않는 검색 요청에 대해 활성 확인 GET /_nodes/stats/indices/request_ca..
searchTagList 의 수가 큰 shipMethod 를 구하는 쿼리 라고 하는데 실행해보면 shipMethod 의 cadinality 의 DESC 로 정렬되고 해당 집계에 대한 count 이다. 검증 안댐 GET /_search { "size": 0, "aggs": { "SEARCH_KEYWORD": { "terms": { "field": "shipMethod", "size": 10, "order": { "count": "desc" } }, "aggs": { "count": { "cardinality": { "field": "searchTagList" } } } } } } 쿼리 결과 { "took" : 15, "timed_out" : false, "_shards" : { "total" : 3, "s..
어디엔가 정리가 되어 있을꺼 같긴한데 찾지를 못해서 다시 작성 [] 대괄호를 쓰면 패턴으로 인식해서 대괄호 안에 있는 문자들을 각각 포함하는 라인을 찾아내줌.. api 의 메소드 실행시간을 다 찍어보고 싶어서 @Timer 어노테이션을 만들었는데 이게..구분하기가 쉽지가 않음 그래서 메소드안에서 일일이다 시간을 기록하는 노가다 코드를 심어 놓음 API 실행 로그 파일 로그를 구분하기 위해 내가 필요한 로그 내용에 prefix 를 입력 (base) ➜ log git:(main) ✗ grep '{COM} ' log.txt > rep.txt 을 실행 저걸 실행하면 log.txt 에서 {COM} 로 시작하는 라인을 rep.txt 로 추출해서 파일로 생성 {COM} 으로 시작하는 라인으로 이루어진 새파일 생성 r..
GET home-search-query-log/_search { "size": 1, "query": { "bool": { "filter": [ { "range": { "query_log.created_date_time": { "gte": "2023-10-29T22:40:00", "lt": "2023-10-29T22:45:00" } } }, { "term": { "query_log.result_count": 0 } } ] } }, "aggs": { "cardinality": { "cardinality": { "field": "query_log.input_query.keyword" } } }, "track_total_hits": true } { "took" : 18, "timed_out" : false, "..
Concept 실제 서비스에 적용될 api cache 의 구성 동적인 데이터를 처리하는 메소드와 정적인 데이터를 처리하는 메소드를 구분하여 캐싱 구성 Detail Data component 데이터를 조회 / 후처리 까지 처리하는 메소드 Data component 단위로 캐싱 application.yml 더보기 spring: profiles: local redis: timeout: 1000 lettuce: pool: max-active: 3 max-idle: 3 min-idle: 3 password: password elasticache: master: - name: itemList redisMaster: host: 127.0.0.1 port: port - name: itemSpecial redisMast..
Api 성능이슈로 정적인 데이터, 동적인데이터에 분리가 필요하고 정적인 데이터에 대한 캐싱이 필요한 상황이 되었다. cache 키를 어떻게 생성할건지에 대한 고민을.. 우선 키 생성방법은 단일 param 을 key 로 cache key 생성 @Cacheable(value = CacheKey.DISTANCE, key = "#request.distance", unless = "#result == null") 복수의 param 을 key 로 cache key 생성 @Cacheable(value = CacheKey.DISTANCE, key = "{#request.distance, #request.countryCode}", unless = "#result == null") key generator 를 만들어서 ..
검색성능 개선 final 이다. 지금까지 테스트 해본 결과를 바탕으로 구조를 잡아서 테스트 ( final 이라고 해놓고 진격의 거인마냥 final part 1, final part 2, final 1기 1쿨 이렇게 증식되지 않기를 바랄뿐..) 우선 이슈는 픽업 서비스 오픈 이후 response time이 튀는 현상이 발생했다. 당연히 검색쿼리로 데이터 조회 후 처리 로직이 추가되었으니 당연히 응답시간이 늘어나는건데 이것이 문제가 되고 있으니.. 늘어난 응답시간은 100ms 이하라서 사용자가 인지하기 힘든 속도이긴 하나. cloud watch 의 모니터링 대시보드에선 널뛰기를 하는 모습으로 나온다. 그래도 로직이 추가될때마다 성능이 저하된다면 문제가 맞긴 한듯하다 cloud watch의 ALB 대상그룹의 ..