반응형

Cluster 상태 모니터링

삭제 작업 중 Kibana의 Monitoring이나 /_cat/health API를 사용하여 클러스터 상태를 모니터링 할 수 있다

GET /_cat/health?v=true

curl 코드

curl -X GET "localhost:9200/_cat/health?v=true&pretty"

 

결과 예시

cluster       status node.total node.data shards pri relo init unassign unassign.pri pending_tasks max_task_wait_time active_shards_percent
elasticsearch green           1         1      1   1    0    0        0            0             0                  -                100.0%

 

상태(status)

- grenn : 모든 샤드가 정상적으로 작동 중

- yellow : 일부 복제본 샤드가 활성화되지 않았지만, 데이터는 사용 가능

- red : 일부 데이터 샤드가 손실된 상태

 

노드 상태 모니터링

GET /_nodes/stats

curl코드

curl -X GET "localhost:9200/_nodes/stats?pretty"

 

출력 예시

- CPU 사용량

- Heap 메모리 사용량

- 디스크 사용량 및 가용량

샤드 상태 모니터링

GET /_cat/shards?v

curl 코드

curl -X GET "localhost:9200/_cat/shards?v=true&pretty"

출력예시 : 

index       shard prirep state   docs  store ip            node
user_data   0     p      STARTED 10000 5mb   192.168.1.10 node-1
user_data   1     r      STARTED 10000 5mb   192.168.1.11 node-2

p : primary 샤드

r : replica 샤드

 

state : STARTED, RELOCATING, INITIALIZING, UNASSIGNED 등의 사앹 확인 가능

 

작업 큐 상태 확인

GET /_cat/thread_pool?v

curl 코드

crul -X GET "localhost:9200./_cat/shards?v=true&pretty"

출력 예시

node_id   name    active queue rejected
node-1    write   2      15    0
node-2    search  0      10    5

queue : 작업 대기열의 크기

rejected : 처리할 수 없어 거부된 작업 수(거부 작업이 많다면 리소스가 부족하다는 신호다)

 

_tasks를 통해 특정 작업 모니터링 하기(나의 경우 delete_by_query)

curl 코드

curl -X GET "localhost:9200/_tasks?detailed=true&actions=*/delete/byquery&pretty"

출력예시

{
  "nodes": {
    "node-1": {
      "tasks": {
        "node-1:12345": {
          "action": "indices:data/write/delete/byquery",
          "status": {
            "total": 100000,
            "deleted": 5000,
            "version_conflicts": 0,
            "throttled_millis": 0
          }
        }
      }
    }
  }
}

 

 

굿굿

 

반응형
반응형

엘라스틱 서치 작업을 해야하는데

RDBMS만 다루다보니 삭제 작업에서 락이 발생하지는 않을지 궁금하여 찾아본 내용 정리

 

*RDBMS 는 MySQL 기준으로 작성

 

혹시 잘못된 내용이 있다면 댓글 주시면 감사하겠습니다.

MySQL의 동작방식

REBMS에서 데이터 삭제가 조회/수정에 영향을 미치는 이유

- 트랙잭션 관리 : MySQL은 ACID를 준수한다. 데이터를 삭제할 때, 해당 행을 잠그고 삭제가 완료되기 전까지 다른작업이 영향을 받을 수 있다.

 

- 물리적 삭제 : MySQL은 데이터를 삭제할 때 디스크에서 데이터를 즉시 제거한다.

 

- 락의 종류

행 레벨 락 : 삭제가 진행 중인 특정 행에 대해 검색/삽입 작업이 대기 상태가 된다.

테이블 락 : 대량 삭제가 테이블에 걸리는 락을 유발할 경우, 모든 작업이 영향을 받을 수 있다.

 

Elasticsearch의 동작방식

NoSQL기반으로 분산형 아키텍처라 데이터 삭제 방식이 RDBMS와 다르다

 

삭제 마킹

엘라스틱에서 데이터를 삭제할 때 해당 문서를 디스크에서 즉시 제거하는게 아니라 삭제된 것으로 표시만 한다

물리적 삭제는 나중에 처리됨

삭제 마킹된 데이터는 백그라운드 병합 작업 중 물리적으로 디스크에서 제거된다.

따라서 삭제 작업이 진행 중일 때도 검색 및 삽입 작업이 계속 정상적으로 이루어질 수 있다.

 

Elasticsearch 에서 검색과 삽입이 영향을 받지 않는 이유 

1. 읽기/쓰기 동시성 처리 :

- 샤드 기반 분산 처리를 사용하여 데이터가 여러 샤드에 분산되어 작업이 특정 샤드에서 이루어져도 다른 샤드에서는 검색 및 삽입 작업이 독립적으로 실행

- 검색과 삭제 작업은 서로 다른 리소스를 사용하므로, 병렬 처리 가능

 

2. 삭제가 논리적으로 처리됨 :

- 삭제는 문서 검색 결과에서 제외하는 논리적 작업에 불과하여 문서가 삭제되더라도 검색은 실시간으로 작동

 

3. document 기반 데이터 모델 :

- 데이터를 독립적인 문서 단위로 저장

- 각 문서가 고유하여 삭제 작업이 진행 중이라도 다른 문서에 삽입되거나 검색될 수 있음

 

특징 MySQL Elasticsearch
삭제 방식 물리적 삭제 논리적 삭제 (삭제 마킹)
데이터 모델 행(row) 단위 관리 독립적인 문서(Document) 단위 관리
트랜잭션 강제성 ACID (강력한 일관성) 최종적 일관성 (Eventual Consistency)
삭제 중 검색/삽입 영향 락 발생 가능성 높음 영향 거의 없음
삭제 처리 시점 즉시 (삭제와 병합 동시 진행) 삭제는 나중에 병합 작업에서 처리

 

반응형
반응형

Elasticsearch란

검색 및 분석을 위한 분산형 오픈소스 데이터베이스

데이터를 index라는 구조로 저장하고, 이를 통해 빠르고 유연한 검색이 가능

 

Document : Elasticsearch에서 데이터의 최소 단위(예 : JSON 형식의 데이터)

Index : Document들이 모여있는 데이터베이스와 유사한 개념

Cluster/Node : 여러 개의 Index와 데이터를 저장하는 서버환경

 


Elasticsearch  데이터 삭제 방법

 

1. 인덱스 전체 삭제

DELETE /index_name

 

2. 조건에 맞는 Document 만 삭제

POST /index_name/_delete_by_query
{
  "query": {
    "match": {
      "field_name": "value" // field_name, value 특정 조건
    }
  }
}

3. Document ID 로 특정 데이터 삭제

DELETE /user_data/_doc/123

 

 

엘라스틱서치 데이터 삭제시 주의해야할 사항으로는

데이터 복구가 불가능하기 때문에 삭제한 중요한 데이터는 삭제 전 백업이 꼭 필요하다.

 

Elasticsearch 대량 삭제가 다른 작업에 미치는 영향

읽기

Elasticsearch는 분산형 아키텍처를 사용하기 때문에, 대량 삭제 작업이 진행되는 동안 검색 및 조회 가능하다

삭제 작업이 클러스터에 높은 부하를 줄 경우, 일부 검색 쿼리의 응답 속도가 느려질 수 있다

쓰기

삭제 작업은 노드 리소스를 소비하므로, 동시에 대량 데이터를 추가하거나 갱신하려는 작업이 진행중이면 성능 저하가 발생할 수 있다

 

_delete_by_query  사용시 데이터를 검색하고 삭제하므로 CPU와 디스크 I/O를 많이 사용

작업의 양이 많아질 경우 성능 서하가 발생할 수 있다

 

성능 저하를 최소화하는 방법

. 사용자 활동이 적은시간(업무 외 시간, 야간)에 삭제 작업을 진행

. 삭제 작업을 분할 처리

: 삭제 작업을 한번에 하지 않고 적게 나눠서 삭제한다.

. Throttling 설정

: request_per_second 값을 설정하여 삭제 제한 설정

ex) 초당 100건 삭제 제한

POST /index_name/_delete_by_query?requests_per_second=100
{
  "query": {
    "match_all": {}
  }
}

. Cluster 상태 모니터링

Kibana의 Monitoring 이나

/_cat/health

명령어를 사용해 클러스터 상태 모니터링

* 상태가 green  일 경우 클러스터가 안정적 상태라는 뜻

 


회사 업무 작업 전 정리 중.

연습삼에 로컬 컴퓨터에 환경을 구축해서 실험해볼 예정이다.

반응형

+ Recent posts