데이터를 완전히 삭제 시키는 것은 옳은 것인가? (Hard Delete, Soft Delete)

티스토리에 글을 작성하는 내가 탈퇴를 한다면 활동한 내용(게시글, 댓글)은 모두 삭제 되는 지 생각해보았을 때 그렇지 않다.

나는 탈퇴한 유저이지만, 내가 활동한 기록은 사라지지 않는다.

 

읽어보새 프로젝트는 책 읽는 '습관'을 목적으로 하는 플래너 서비스로, 하루하루 쌓이는 데이터가 중요하다.

그렇다면 유저가 탈퇴를 하거나, 플랜을 삭제했을 때 데이터를 완전히 삭제하는 게 옳은 것일까에 대한 생각을 하게 되었다.

 

---

 

논리삭제 - Soft Delete

논리적으로만 삭제하는 방법

UPDATE 쿼리가 발생한다.

사용자가 한때 접근할 수 있었지만, 더이상 접근할 수 없는 데이터로 만드는 프로세스이다.

예들면 User 테이블에서 userStatus를 만들어 '탈퇴' 상태로 만든다면, 유저는 더이상 로그인 할 수 없고 사적인 데이터는 null 값으로 바뀌지만, 데이터는 DB에 그대로 남아있게 된다.

 

 

물리삭제 - Hard Delete

데이터베이스에서 영구적으로 데이터를 삭제하는 방법

DELETE 쿼리가 발생한다.

 

---

데이터 복구의 용이성

삭제한 플랜을 복구하고 싶을 경우

물리삭제의 경우 history 같은 테이블을 만들어 데이터를 복사해 놓는 경우 복구를 진행할 수 있다.

논리삭제의 경우 칼럼의 값만 Update를 진행하면 된다.

 

활성 데이터 조회

논리삭제의 경우 조건에 삭제에 관한 부분을 빼먹었을 경우 문제가 발생할 가능성이 있다.

반면 물리삭제의 경우 삭제된 데이터가 조회 될 가능성이 없어 데이터의 무결성을 생각해 보았을 때는 물리삭제가 좋아보인다.

 

DB의 성능

update가 delete보다 microseconds 만큼 빠르다고한다.

테이블의 삽입과 인덱스의 재배열까지 고려하더라도 update가 훨씬 빠르다. (DBMS의 특성에 의해 다를 수 있다.)

다만 delete의 인덱스 재배열때문에 서비스가 느려질 정도라면 insert도 느려질 것이고, 파티션이나 샤딩을 고려할 시점이라고 생각된다..

 

DB 기능 호환성

논리삭제의 경우 DELETE 기능을 사용하지 않는다.

 

APP의 성능

논리삭제를 위해선 조건이 필요하고, join 시 조건이 많아질 가능성이 있다.

조건이 많은 것보다 적은 것이 빠르고, 오류가 날 확률이 적기 때문에 성능상으로 물리삭제에 이점이 있어보인다.

또, 논리삭제의 경우 테이블 크기가 계속해서 증가하기때문에 쿼리의 속도가 느려질 수 있다.

 

---

 

어떤 서비스를 만드는지에따라 적용해야할 방식이 다르다고 생각된다.

 

읽어보새의 경우 논리삭제가 맞다고 생각되어, Plan에서 status 칼럼을 통해 논리삭제를 진행 할 예정이다.