개발잡부

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

인덱스 생성 PUT nested-object-test { "mappings": { "properties": { "metaDates": { "type": "nested", "properties": { "value": { "type": "float" } } } } } } 데이터 색인 PUT /nested-object-test/_doc/1 { "somefield": "this is a field", "someotherfield": "this is some other field", "metaDates": [ { "name": "create-time", "value": 1 }, { "name": "update-time", "value": 1 }, { "name": "some-other-time", "value":..