아빠는 개발자

Aggregation 의 성능을 높이고 싶을때 시도해 보면 좋은 방법이 될꺼 같은데.. 아무튼 테스트를 해보자일단 인덱스의 맵핑 구조는 아래와 같다.  포인트는             "city": "Michigan",            "country_code": "US",            "country": "America/Detroit",3개의 정보가 단일필드, place 하위의 object, 그리고 그 obejct 하위의 object 로 3가지 색인후 집계 테스트를 진행해 본다.  { "settings": { "number_of_shards": 1, "number_of_replicas": 0 }, "mappings": { "dynamic": "true", "_sour..

Elasticsearch에서 데이터 노드가 6대일 때, primary shard와 replica의 설정이 성능에 미치는 영향주된 차이점은 읽기와 쓰기 성능, 그리고 시스템의 가용성 및 복구 능력 주어진 시나리오에서 primary shard가 3개이고 replica가 각각 1과 3인 두 설정을 비교해 보잣1. Primary Shard: 3, Replica: 1구성:총 샤드 수 = Primary Shard (3) + Replica Shard (3) = 6개 샤드.각 노드에 하나의 샤드가 배치될 수 있으므로, 모든 노드가 샤드를 하나씩 가지게 됨이는 3개의 primary shard에 대해 각각 1개의 replica shard를 가지므로, 6개의 데이터 노드에 분산성능:쓰기 성능: 쓰기 작업은 primary s..

이론과 실제가 달라서.. 당황스럽다 이게.. 말을 안듣는다..테스트 방법의 문제인가.. 아무튼..   테스트 Api 를 로컬에 띄워놓고 테스트를 진행하면..  elasticsearch data node 트래픽이 잘 안들어가는 듯한..내 pc 에서 나가는 패킷이 나가다가 줄어드는데.. 음.. 원인을  누구한테 물어봐야 할지..네트워크 대역폭이 문제인가.. 아무튼 테스트 했는데 원하는 그림이 나오긴했다.  샤드 구성을 변경해서 data node 재부팅샤드 맞춤 _cluster/reroute테스트19:00 이후 Auto test 실행 Shard 구성AS-IS: 6서버 1노드 1샤드 (primary 3, replica 1) 각 데이터 노드별로 1개의 샤드 구성 - 운영과 동일한 구조TO-BE: 6서버 1노드 1..

이게 나를 요즘 .. 힘들게 한다...       데이터 노드의 구성은 1서버 1노드 1샤드  primary 3 , replica 1 어느부분이 문제를 일으키는지는 알고 있다.  제거 하고 다시 실행, 하지만 이 로직을 뺄수는 없다..  문제를 일으키는 로직은 검색결과에서 집계를 통해 필터를 만들어 내는 로직 이 로직을 파보니 query_cache 가 특정샤드에서만 상대적으로 적게 생성이 된다.  집계를 통한 필터 생성이여서 request cache 가 먹혀야 하는 구조였는데  아무튼 마지막 구간에서 엄청나게 안정적인 흐름을 보이는..  그럼 다시 널뛰는 cpu 로 만들어 놓고    해결방법try 1- cpu 는 트래픽이 적을땐 저렇게 하나만 튀는 현상이 없었다. redis cache 를 사용해서 트레픽..

난 샤드 크기와 도큐먼트 사이즈가 알고싶다.  kibana 명령어 GET /_cat/shards?v&h=index,shard,prirep,state,docs,store,node 결과

뭐 대충 이런느낌 이랄까트래픽이 왔을때  8core 16Gb 로 띄운 X 6대의 data node prd data copy index 0710 (운영데이터) alias 변경local api (Local to ES)200건/초중복제거키워드 (10,000 x 2)sleep 0.3초최초 1회 es cache 초기화 후 실행이렇게 테스트 하면 저런 결과가 나온다. 샤드 구성도 맞춰놓고  샤드 구성 변경 reroute api POST _cluster/reroute{ "commands": [ { "move": { "index": "prd-ds-item-20240710", "shard": 1, "from_node": "node-qa-totalsearch-data-..

Elasticsearch에서 샤드(Shard)는 인덱스를 분할하여 데이터 분산 저장과 병렬 처리를 가능하게 하는 단위입니다. 샤드의 개수가 검색 성능에 미치는 영향은 다양한 요소에 따라 달라질 수 있습니다.샤드가 많을 때의 이점병렬 처리: 더 많은 샤드는 검색 쿼리를 병렬로 처리할 수 있는 기회를 제공합니다. 이는 특히 클러스터 내 여러 노드가 있을 때 검색 성능을 향상시킬 수 있습니다.데이터 분산: 데이터를 더 세분화하여 분산 저장할 수 있으므로, 각 샤드에 저장된 데이터 양이 적어지고 개별 샤드의 검색 속도가 빨라질 수 있습니다.리소스 활용: 클러스터의 리소스를 더 효과적으로 활용할 수 있습니다. 특히 여러 노드에 걸쳐 데이터가 분산될 때, 각 노드의 CPU 및 메모리 사용을 최적화할 수 있습니다.샤..

Elasticsearch 쓰기 작업의 3단계1. 조정 단계(coordination stage)2. 주 샤드 단계(primary stage)요청을 넘겨받은 이후 수행하는 작업들in-sync 복제본마스터 노드가 관리하는 작업을 복제받을 샤드 목록주 샤드는 in-sync 복제본에 병렬적으로 요청을 넘긴다.모든 복제본들이 작업을 성공적으로 수행하고 주 샤드에 응답을 돌려주면 주 샤드가 작업 완료 응답을 보낸다.3. 복제 단계(replica stage)각 in-sync 복제본 샤드는 주 샤드에게 받은 요청을 로컬에서 수행하고 주 샤드에게 작업이 완료됐음을 보고하는 단계→ 종료는 역순이다.최초 요청 받아 전달했던 노드에게 작업 완료 결과를 보내야 조정 단계가 종료된다.메세지 순서의 역전분산 환경에서 여러 작업을 병..

검색 과정Elasticsearch 의 검색은 1 Query, 1 Shard, 1 Thread를 바탕으로 이루어짐노드는 샤드를 1개씩 가지고 있다 노드는 4개의 코어를 가지고 있다이 경우 검색 쓰레드 풀에 4개의  검색 Thread를 가지고 있게 된다.  레플리카 샤드의 수에는 trade-off 관계가 있다.레플리카가 많아질 수록 색인 성능은 떨어지고, 읽기 성능은 좋아진다.반대로 레플리카가 적으면 색인 성능은 좋지만, 읽기 성능은 떨어진다.그럼 샤드수를 늘리면 읽기 성능이 좋아니지 많을 수록 좋은거 아니냐..  클러스터 내 너무 많은 수의 샤드가 있는 경우클러스터에 존재하는 모든 샤드는 마스터 노드에서 관리하며, 샤드가 많아질수록 마스터 노드의 부하도 같이 증가이로 인해 마스터 노드의 부하가 증가하면 검..

몰라도 상관없지만 알아두면 요긴한 기본상식elasticsearch 의 search api  response 구조 { "took": 5, // 검색에 소요된 시간 (밀리초 단위) "timed_out": false, // 타임아웃 여부 "_shards": { "total": 5, // 전체 샤드 수 "successful": 5, // 성공적으로 처리된 샤드 수 "skipped": 0, // 건너뛴 샤드 수 "failed": 0 // 실패한 샤드 수 }, "hits": { "total": 1, ..