작성하게된 계기
게임 회사를 취업하기 전에는 DB 테이블에 레코드를 삭제할 때 DELETE 쿼리를 작성했습니다.
그 이유는 아래와 같았습니다.
- DELETE 쿼리가 삭제의 개념에 맞고 직관적이다.
- DB에 데이터가 계속 쌓이게 되면 시간이 지나면 데이터가 많아 성능에 마이너스가 될 우려
하지만 개발 공부를 하면서 레코드를 삭제하지 않고 UPDATE 쿼리를 사용해 레코드에 명시하는 방법도 있다는 것을 알게 됩니다.
| id | username | password | isDeleted |
|---|---|---|---|
| PK | 유저네임 | 패스워드 | 삭제여부(1 or 0) |
| 11235 | naocya | naocya123 | 1 |
위와 같은 방식으로 테이블을 설계에서 삭제 여부 flag를 표시하는 것입니다.
여기서 데이터(레코드)를 아예 삭제하는 방법과 UPDATE로 flag 값만 변경해주는 방법의 각 차이점을 알기 위해 작성해봤습니다.
내용 요약
Delete 작업이 행을 실제로 제거하는 작업이므로 해당 행을 디스크에서 물리적으로 삭제해야 한다
반면에 Update 작업은 기존 행을 수정하고 새로운 데이터로 업데이트합니다.
이 글의 내용을 성능에 대한 관점에서 요약하면 위와 같습니다.
여기서 왜 성능적으로 각 차이점이 있는지를 정리해봤습니다.
Delete가 Update보다 성능적으로 안좋은 이유들
1. 로그 및 로그파일
대부분의 데이터베이스 시스템은 Delete 작업을 수행할 때 이를 로그에 기록합니다.
이 로그는 데이터 손실을 방지하기 위해 트랜잭션 롤백이나 복구를 위해 필요합니다.
따라서 Delete 작업은 로그에 쓰는 작업을 동반합니다.
반면 Update 작업은 이전 값과 새 값의 차이를 로그에 씁니다.
Delete 작업이 로그를 더 많이 기록하므로 시스템에 부하를 더 줄 수 있습니다.
2. 데이터 이동 및 인덱스 조정
Delete 작업은 데이터베이스에서 행을 완전히 제거합니다.
이로 인해 빈 공간이 발생할 수 있으며, 데이터베이스는 이 빈 공간을 재사용하려고 할 수 있습니다.
이렇게 되면 데이터 이동이 발생하고, 인덱스 업데이트도 필요할 수 있습니다.
하지만 Update 작업은 기존 레코드를 업데이트하기 때문에 데이터 이동이나 인덱스 조정이 덜 발생할 가능성이 높습니다.
3. 데이터베이스 로킹 및 동시성 문제
Delete 작업은 보통 더 많은 데이터를 영향을 미치므로 데이터베이스 락을 더 오래 유지할 수 있습니다.
이로 인해 다른 트랜잭션들이 기다려야 할 수 있습니다.
Update 작업은 해당 레코드만을 락하고 나머지 데이터에 대해서는 락을 피할 수 있는 경우가 많습니다.
크게 3 가지 이유로 인해 성능적 차이를 보입니다.
정리하면
- DELETE는 데이터 손실을 방지하기 위해 트랜잭션 롤백 복구 로그 쓰기 작업을 동반하는 로그를 더 작성한다.
- DELETE는 레코드(행)을 완전 제거하면서 빈 공간이 발생하고 이 빈 공간을 재사용 하면서 데이터 이동 및 인덱스 업데이트 소요가 생긴다.
- DELETE는 더 많은 데이터에 영향을 미쳐 락을 좀 더 오래 유지한다.
DELETE의 성능적 이슈
1. DELETE 시 HDD 메모리 단편화
사용하는 데이터베이스가 HDD 혹은 SSD를 사용하고 있는지 알 수 없습니다.
하지만 HDD를 사용한다는 가정하에는 DELETE 작업 진행 시 메모리 단편화가 발생합니다.
데이터베이스에서 사용하는 HDD는 조금 다를 수 있습니다.
그렇지만 기본적인 원리는 비슷합니다.
HDD는 데이터를 찾을 때 원형으로 된 플래터가 돌아가면서 데이터를 찾습니다.
그런데 일정한 간격으로 저장되어있던 데이터가 부분부분 삭제가 되어 빈 공간이 생기면 메모리 단편화가 발생합니다.
이런 상황이 반복되면 동일한 테이블에 있는 데이터를 찾는데도 플래터가 더 많이 회전해야 할 수있습니다.
=> 이런 문제를 해결하기 위해 리빌딩을 주기적으로 진행하는 곳도 있다고 합니다.
(리빌딩은 컴퓨터 디스크 조각 모음과 비슷한 작업니다.)
2. 인덱스 삭제 문제
인덱스 테이블은 위 사진과 같이 따로 있습니다.
DELETE를 하면 인덱스도 삭제가 되게 됩니다.
이런 문제를 해결 하기 위해 인덱스도 리빌딩을 합니다.
인덱스 리빌딩은 SSD에서는 성능 개선은 적지만 전체적인 테이블의 사이즈가 줄어들게 됩니다.
B-Tree 인덱스
- B-Tree를 사용한다고 해도 Tree의 구조가 성능적으로 이점을 찾기 위해 리빌딩
- B-Tree 인덱스에서 데이터를 지우면 해당 노드의 데이터가 비어있는 경우도 있을 수 있습니다.
3. SSD와 HDD의 차이에 따라서도 다르다.
특정 데이터베이스가 SSD를 주로 사용할 수도 있고, HDD를 주로 사용할 수 있습니다.
하지만 이 주제에서는 SSD와 HDD의 차이로 인해 DB 데이터 저장 시 발생하는 차이점을 다뤄봤습니다.
SSD는 플래시 메모리로 HDD와 다르게 플래터가 돌아서 데이터를 찾지 않습니다.
그래서 HDD보다는 높은 성능을 보여줍니다.
차이점을 정리하면 아래와 같습니다.
- HDD는 플랫터가 직접 돌면서 데이터를 찾기 때문에 Delete를 실행 시 메모리 단편화 발생
- SSD는 HashMap과 비슷해서 메모리 단편화에 대한 이슈가 적음
- 요즘에는 HDD보다는 SSD를 사용하기 때문에 메모리 단편화에 대한 이슈는 적다
작성하면서 느낀 점
기술에서 정답이 없다는 것을 다시 느끼게 되었습니다.
DELETE가 성능적으로 나쁘다고 해서 무조건 사용하면 안된다고 생각하면 안됩니다.
항상 기술에는 트레이드 오프가 있다는 것을 알고 차이점을 알아야 합니다.
차이점을 알기 위해서는 다양한 상황을 직접 경험해보거나 상황을 추론해 볼 수 있어야 합니다.
내가 사용하는 데이터베이스가 SSD를 주로 사용하는지 HDD를 주로 사용하는지 알 수 없습니다.
요즘 기술의 많은 곳들이 추상화 되어있는 인터페이스를 제공합니다.
이런 상황에서 결정을 하기 위해서는 모든 것을 알 수는 없지만 큰 맥락에서 차이점을 알아야 한다고 생각합니다.
참고 자료
