[Elasticsearch] 데이터 삭제 중 락이 발생하지는 않을까?

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

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

 

*RDBMS 는 MySQL 기준으로 작성

 

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

MySQL의 동작방식

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

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

 

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

 

- 락의 종류

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

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

 

Elasticsearch의 동작방식

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

 

삭제 마킹

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

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

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

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

 

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

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

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

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

 

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

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

 

3. document 기반 데이터 모델 :

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

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

 

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