[DB] Soft Delete 도입에 관해

논리적 삭제를 통해 얻게되는 장단점을 먼저 정리해보자

📌 Soft Delete 개요

Soft Delete 장점

1. 정보 보존에 따른 복구 가능
2. DELETE 보다 빠른 속도의 UPDATE
3. 데이터를 활용한 추후 서비스 및 활용이 가능

Soft Delete 단점

1. 데이터베이스 용량 증가
2. 모든 쿼리에서 소프트 딜리트된 데이터를 제외시켜야 함

🤔 도입해야 할까?

우리 서비스에 필요한가?

현재 서비스에서 제공되는 기능 중 주요한 데이터라고 생각되는 것은 도면과 결제, 주문, 회원이라고 생각된다.
도면의 경우, 추후 도입될 업로드 기능이 생길 경우 복구가 불가피할 것으로 보인다. 또한 삭제한 데이터도 가지고 있어 도면에 대한 데이터를 축적할 수 있다는 장점을 가진다.
회원의 경우도 회원가입 시 선택되는 직업, 나이에 대한 정보가 우리 서비스를 이용하는 주 타겟층을 아는데 많은 도움이 된다.

개인정보 보호법에 따라, 쇼핑몰은 정보통신서비스를 1년 동안 이용하지 않는 이용자의 개인정보를 파기 또는 분리보관해야 합니다.

현재 법률 상 1년 동안 사용되지 않는 데이터는 파기해야하기 때문에 일정 시간 후에 삭제되도록 하는 기능이 포함되어야 할 것 이다.

모든 데이터에 적용하는 것이 좋은가?

그렇지 않다. 데이터 분석, 중요한 정보를 제외한 나머지 정보(카테고리, 문의사항 등)은 저장 공간을 확보하면서 까지 보존할 필요가 없다.
현재는 4가지 데이터에 대해서만 적용하는 것이 맞다고 판단하지만 서비스가 커지면 얼마든지 변할 수 있다.

🔨 적용해보자

Spring에서의 Soft Delete

기존에 팀원 분께서 @SQLDelete를 통해 다음과 같이 구현해주셨다. 회원탈퇴 기능 수행 시 정상적으로 작동하는 것을 확인할 수 있었다. 이 코드의 문제점은 모든 회원 관련 쿼리에 is_deleted = false라는 구문이 추가되어야 한다. 아래 코드처럼 매우 불편해지고, 코드의 가독성 또한 매우 떨어지기 때문에 @Where 를 통해 공통처리하는 것이 필요해보인다.
@Where가 Deprecated 됨에 따라 Hibernate에서 @SQLRestriction을 대안책으로 권고하고 있다.

전체 조회가 불가능?

@SQLRestriction이 설정된 이상 is_deleted가 true인 데이터를 조회하는 것이 불가능하다. 현재는 삭제된 데이터를 통해 이루어지는 로직이 없지만, 서비스가 커지게 되면 이런 기능이 사용될 상황이 충분히 발생할 수 있다. 따라서, 이를 해결하기 위한 해결책이 필요하다. @SQLRestriction으로 추가된 where 절을 무시하는 방법이 2가지가 있다.

 

1. @Query의 NativeQuery=true

2. @FilterDef와 @Filter

 

2번의 경우, 어노테이션에 설정해야할 점이 많고 EntityManager에 필터를 설정하는 과정이 필요하다. 2번보다 1번을 통해 @SQLRestriction을 사용해보려고 한다.

연관 관계를 갖는 Soft Delete는 어떻게 되는가?

https://lovelyunsh.tistory.com/305

Soft Delete에 보존 기간을 설정할 수 있는가?

MySQL Event Scheduler vs. Spring Batch (@Scheduled)

 

• 소량의 Soft Delete 데이터를 삭제한다면 MySQL Event Scheduler가 적합.

• 대량 데이터를 삭제해야 하고 성능 튜닝이 필요하다면 Spring Batch로 페이징 처리 + Batch Delete 방식 추천.

• 트래픽이 많은 서비스라면 MySQL 파티셔닝 활용 (DROP PARTITION 방식 사용).

 

https://jaeseo0519.tistory.com/375