soft delete 와 hard delete 비교

wally·2022년 9월 29일

Database

생각해보기

목록 보기

10/11

soft delete, hard delete 란

hard delete 는 테이블에서 제거하는 거고 sofe delete 는 필드로 flag 체크하는 거다. 실제 제거는 굉장히 위험하므로 hard delete 하는 경우 따로 해당 데이터를 관리해야 한다.

요약

출처 : https://abstraction.blog/2015/06/28/soft-vs-hard-delete#recommendation

해당 사이트의 내용을 한국어로 변환한 글입니다.
soft delete 는 결국 쿼리조건이 늘어나 성능에 영향을 미치고, soft delete 는 테이블 내부에서 분리가 없기 때문에 가시성이 좋지 않습니다.
조건문 추가에서 발생할 수 있는 개발자의 실수는 ORM 에서 자체적으로 제공하는 다양한 기능들로 막을 수 있습니다.
실무 수준에서 hard delete 된 데이터를 audit table 에서 관리하는 환경이 조성된다면 hard delete 를 토이 프로젝트 등 단순한 경우에는 soft delet 가 더 좋을 수도 있을거 같습니다.

용어 정리

audit table

관리권한이 있는 경우에만 접근할 수 있는 테이블.
특별한 기능이 있는 테이블은 아니다.
특정 테이블에서 수행되는 작업을 추적하는 기능을 한다.(Who, What, When)

create table SensitiveInformation
(
    SensitiveNumber int not null,
    SensitiveData varchar(100) not null
)

create table SensitiveInformationAudit
(
    SensitiveNumberNew int null,
    SensitiveNumberOld int null,
    SensitiveDataNew varchar(100) null,
    SensitiveDataOld varchar(100) null,
    Action varchar(50) not null,
    AuditDate datetime not null,
    LastUpdatedUser varchar(100) not null
)

누가 어떤 레코드(종종 스냅샷 전후 포함)를 수행했는지 추적하는 것 외에도 audit table이 한 번 기록된다는 것이 중요한 특징이다.
audit table의 레코드는 업데이트하거나 삭제할 수 없으며(참고 참조) 삽입만 할 수 있습니다
- 오래된 레코드를 지우려면 추가 승인 등의 프로세스가 필요
audit table 는 추가적으로 민감한/기밀 테이블의 변경 사항을 추적하려는 경우에 사용된다.

Active data

시스템의 운영 체제 또는 생성된 응용 프로그램 소프트웨어 에서 볼 수 있는 데이터 를 나타낸다

Soft delete vs hard delete

Ease of Setup

Soft Delete 는 update 만 하므로 더 세팅하기 쉽다. hard delete 는 audit table 에 복사하는 작업이 포함되므로 구현하기 더 복잡하다.
Advantage : Soft Delete

Debugging

Soft Delete를 사용하면 deleted_flag로 인해 데이터 문제를 쉽게 디버그할 수 있습니다.
그러나 Audit table을 통한 디버깅도 쉽게 가능합니다
Advantage : NA

Restoring data

delete_flag 설정 해제만 포함되어 있기 때문에 일시 삭제를 통해 '삭제된' 데이터를 복원하는 것은 매우 쉽습니다.
그러나 데이터 복원은 극히 드문 경우이다.
Advantage : Soft Delete

Querying for active data

경험상 개발자가 문제가 발생한 선택 쿼리에 "deleted_flag = '0'" 조건을 추가하는 것을 잊었을 때 많은 문제가 발생했다고 말할 수 있다.
하지만 ORM 을 사용한다면 @Query 나 @SQLDelet 와 같은 기능들이 제공되므로 이러한 체크 문제로 발생할 수 있는 상황을 회피할 수 있다.
Advantage : Hard Delete

View Simplicity

테이블의 모든 데이터를 active data 로 유지하는 것에서 soft delete 는 한테이블에 존재하므로 분리가 되지 않는다.
Hard Delete에서 모든 '삭제된' 데이터는 audit table 에만 있고 시스템의 나머지 테이블에는 active data가 있다. 따라서 Hard Delete에 대한 관심 분리가 되어있다.
Advantage : Hard Delete

Performance of operation

Update 는 delete 보다 약간 빠르다 (microseconds).
따라서 soft delete는 기술적으로 hard delete(고려할 audit table 삽입도 포함)보다 빠르다.
Advantage : Soft Delete

Application Performance

Speed
- soft delete를 지원하려면 모든 선택 쿼리에 "WHERE deleted_flag = '0'" 조건이 있어야 한다.
- JOIN이 관련된 상황에서는 이러한 조건이 여러 개 있을 것이다.
- 조건이 적은 select 쿼리는 조건이 많은 쿼리보다 빠르다
- Advantage : Hard Delete
Size
- 더 빠른 soft delete 를 지원하려면 모든 테이블의 모든 deleted_flag에 대한 인덱스가 필요하다.
- 또한 테이블에 ‘soft deleted’ data + active data 가 있으므로 테이블 크기가 계속 증가한다.
- 테이블 크기가 증가하면 쿼리가 느려질 수 있다
- Advantage : Hard Delete

Database features compatibility(기능 호환성)

Unique Index(고유 인덱스)
- Unique index 는 데이터베이스 수준에서 행이 여러 번 발생하는 것을 방지하여 데이터 무결성을 보장한다.
- soft delete를 사용하면 Unique index를 사용할 수 없다.
  - 예:
    - 필드 A 및 필드 B 및 deleted_flag에는 composite unique index 가 있다.
    - 데이터 A1 & B1이 있는 행이 'soft deleted'된 경우 고유 인덱스는 값 A1-B1-1(즉, deleted_flag)에 대한 것이다.
    - 새 항목 A1-B1이 테이블에 추가되면 고유 인덱스로 인해 다시 soft deleted 될 수 없다.
- 또한 old soft deleted entry of A1-B를 업데이트할 수 없다. 이는 일부 데이터를 다시 작성하여 기록된 데이터가 손실되는 것을 의미하기 때문이다(예: update date time or some other deleted_by column if it exists).
- Advantage : Hard Delete
Cascading
- For soft delete, we cannot make use of ‘ON DELETE’ cascading.
- The alternative is to create an ‘UPDATE’ trigger which keeps track of deleted_flag.
- Advantage : Hard Delete