개발잡부

검색 속도 조정 파일 시스템 캐시에 메모리 제공 더 빠른 하드웨어 사용 문서 모델링 가능한 한 적은 수의 필드를 검색 사전 색인 데이터 매핑 식별자를 키워드로 고려 스크립트 피하기 반올림된 날짜 검색 읽기 전용 인덱스 강제 병합 글로벌 서수 워밍업 색인 정렬을 사용하여 접속사 속도를 높임 기본 설정을 사용하여 캐시 활용도 최적화 복제본은 처리량에 도움이 될 수 있지만 항상 그런 것은 아님 회사에서 성능 이슈를 제기했다. 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 동일한 키워드에서 무의미한 데이터 같이 추출 됨

elasticsearch score 임계값 score에 지정된 값보다 작은 문서는 제외 시킨다. GET /_search { "min_score": 0.5, "query" : { "term" : { "user" : "kimchy" } } } 스코어 기준 노출제어는 .. 애매하다..

간만에 ES 테스트 N-gram tokenizer 우선 프로젝트로 이동 es8.6환경 만들어 놓은게 있으니 활용 cd /Users/doo/docker/es8.6.2 docker compose up -d --build 아 역시나 이럴줄 .. 900gle es 로 변경 - es 7.15.1 cd /Users/doo/project/900gle/docker/elastic-stack docker compose up -d --build ngram 토크나이저로 home 을 분해해 보면 아래와 같이 분해가 된다 { "tokens" : [ { "token" : "h", "start_offset" : 0, "end_offset" : 1, "type" : "word", "position" : 0 }, { "token" : ..

500개가 넘는 상품명의 토크나이징된 결과값을 달라고 한다.. 노가다를 뛰까.. 500개 정도면 할만한데 라고 생각했으나.. 수정, 추가 등등 계속요청할꺼 같아서 만들어봄 local 에서 es 에 세팅된 analyzer 를 이용함 client 생성 client = Elasticsearch("https://id:pw@host:port/", ca_certs=False, verify_certs=False) analyze 쿼리 def get_query(): response_n = client.indices.analyze( index=INDEX_NAME, body={ "analyzer": "index_analyzer", "text": "프랑스_떼땅져녹턴시티라이트_750ML" } ) print(response_n)..

Elasticsearch의 각 인덱스는 하나 이상의 샤드로 나뉘며, 각 샤드는 하드웨어 장애로부터 보호하기 위해 여러 노드에 걸쳐 복제될 수 있습니다. 데이터 스트림을 사용하는 경우 각 데이터 스트림은 인덱스 시퀀스로 지원됩니다. 단일 노드에 저장할 수 있는 데이터 양에는 제한이 있으므로 노드를 추가하고 일치시킬 인덱스 및 샤드 수를 늘려 클러스터의 용량을 늘릴 수 있습니다. 그러나 각 인덱스와 샤드에는 약간의 오버헤드가 있으며 데이터를 너무 많은 샤드로 나누면 오버헤드가 압도적으로 커질 수 있습니다. 너무 많은 인덱스 또는 샤드가 있는 클러스터는 오버샤딩 으로 인해 어려움을 겪는다고 합니다 . 오버샤딩된 클러스터는 검색에 대한 응답이 덜 효율적이며 극단적인 경우 불안정해질 수도 있습니다. 샤딩 전략 만..