개발잡부

org.elasticsearch.hadoop.EsHadoopIllegalArgumentException: Cannot detect ES version - typically this happens if the network/Elasticsearch cluster is not accessible or when targeting a WAN/Cloud instance without the proper setting 'es.nodes.wan.only' es.nodes.wan.only = true 위의 옵션 해도 안되는 ... 다음 구성 속성도 추가해야 했습니다. es.net.ssl = true

간만에 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" : ..

Elastic APM : https://www.elastic.co/kr/apm Elastic APM Overview : https://www.elastic.co/guide/en/apm/get-started/7.6/transactions.html Elastic APM Server : https://www.elastic.co/guide/en/apm/server/current/index.html Elastic JAVA Agent : https://www.elastic.co/guide/en/apm/agent/java/1.x/index.html Elastic PHP Agent : https://github.com/philkra/elastic-apm-php-agent Newrelic APM : https://new..

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

클라이언트에서 connection 종료를 인지하지 못하고 계속들고있다가 lost connection으로 시도하는것으로 추측 .setConnectionReuseStrategy((response, context) -> true) // keepAlive use true .setKeepAliveStrategy((response, context) -> 300) // keepAlive timeout sec

인덱스 생성 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":..

노드 속성을 사용하여 hot-warm-cold 아키텍처를 구현하는 방식은 더 이상 권장되지 않습니다. Elasticsearch 7.10 은 데이터 수명 주기 구성을 덜 복잡하게 만들었습니다. 이 블로그 게시물에서는 몇 가지 변경 사항, 사용 방법 및 그 과정에서 몇 가지 모범 사례를 살펴보겠습니다. 데이터 수명 주기는 많은 단계를 포함할 수 있으므로 다음을 살펴보겠습니다. 클러스터를 계층(핫, 웜, 콜드)으로 분할하여 새 데이터가 올바른 위치로 이동하도록 합니다. 계층 간에 데이터를 마이그레이션하기 위해 인덱스 수명 주기 관리(ILM) 내에서 이러한 계층을 활용합니다. 검색 가능한 스냅샷을 사용하여 콜드 계층 내에서 데이터 밀도를 높입니다. 데이터가 계층을 통해 흐르는 방식에 대한 실제 예와 함께 모든 ..

PUT doo_shingle { "settings": { "analysis": { "filter": { "doo_shingle_filter": { "type": "shingle", "min_shingle_size": 3, "max_shingle_size": 4 } } } } } min_shingle_size / max_shingle_size : shingle의 최소 / 최대 단어 개수를 지정. 디폴트는 모두 2 output_unigrams : Shingle 외에도 각각의 개별 토큰(unigram)도 저장 하는지의 여부를 설정. 디폴트는 true output_unigrams_if_no_shingles : shingle 을 만들 수 없는 경우에만 개별 토큰을 저장하는지의 여부를 설정 디폴트는 false to..

#! The [edgeNGram] token filter name is deprecated and will be removed in a future version. Please change the filter name to [edge_ngram] instead. PUT doo_edge_ngram { "settings": { "analysis": { "filter": { "doo_edge_ngram_filter": { "type": "edge_ngram", "min_gram": 1, "max_gram": 4 } } } } } GET doo_edge_ngram/_analyze { "tokenizer": "keyword", "filter": [ "doo_edge_ngram_filter" ], "text": "..