이번 팀 프로젝트의 주제는 프로젝트 협업도구 만들기로, 칸반보드 형태로 프로젝트를 관리하는 사이트를 만드는 것이다.
프로젝트 S.A.를 작성하면서 사용자 Use case들을을 정리하였는데,
이 과정에서 고민했던점에 대해 기록해보려고 한다.
1. 회원탈퇴 구현 방식에 대한 고민
1) 기존에는 회원탈퇴를 하면 delete 쿼리를 날려 관련 테이블의 자료도 삭제를 했다. (orphanRemover 등 사용)
2) 하지만 협업도구의 특성상 관련된 토의, 토론이 진행된 댓글은 회원이 탈퇴하더라도 삭제되지 않는게 맞다고 생각을 하였고, 그럼 어떻게 하면 회원탈퇴시 comment를 남길 수 있을지에 대해 고민하게 되었다.
고민한 방법
팀원들과 이야기 해서 나온 해결방안은 2개다
1. DB에 익명 사용자를 하나 넣어두고 탈퇴시 해당 댓글의 user를 익명사용자(unknow)으로 변경하고 회원을 삭제하는 방법(사용자 delete쿼리, 댓글 update 쿼리)
2. DB에 저장된 로그인 정보(email, password)만 바꾸고 사용자 정보(nickname)는 유지 하는 방법 + 삭제됐는지의 field를 추가하기(사용자 update 쿼리)
1번 방법으로 했을 때의 문제는 모두 같은 사용자로 교체하니 댓글 사용자 구분이 안된다는 점과,
2번 방법으로 했을 때는 활동중인 사용자보다 탈퇴한 사용자가 많을 경우 데이터 조회시 성능적으로 좋은지에 대한 고민을 했다.
이에 대해 관련 자료를 찾아보니 SoftDelete와 HardDelete에 대한 정보를 찾을 수 있었다.
Soft Delete VS Hard Delete
* Soft Delete란?
소프트 삭제는 논리적으로 삭제하는 것으로, 실제 DB상에서 제거하는 것이 아니라
안보이도록 필드 값을 설정하는 방식으로 (방식은 다양) 사용자입장에서는 삭제한것처럼 보이는 방식이다.이 방식을 사용하면 사용자가 실수로 삭제한 경우에도 복구가 가능하고, 데이터를 보존 할 수 있으며, 일시적으로 사용하지 않도록 만든다.
* Hard Delete란?
하트 삭제는 물리적으로 데이터를 삭제하는 것으로, 실제 DB상에서 완전히 제거하는 것이다.
이 작업을 수행하면 데이터베이스나 시스템에서 해당 정보가 영구적으로 사라지고, 복구할 수가 없다.
어찌보면 1번 방식의 경우 Hard Delete, 2번 방식의 경우 Soft Delete인데
현업에서도 개인 정보 관련 보호법으로 인해 일정 기간동안 데이터를 가지고 있도록 하기때문에 Soft Delete를 많이 사용한다고 한다.
또한 이번 프로젝트에서 사용하는 DB인 MySQL에서는 DELETE보다 UPDATE가 훨씬 빠르단 점에서 2번 방식을 채택하는게 성능적으로 나을 수 있단 결론이 나왔다.
(물론 이후 데이터가 커져 조회적 측면을 고려하면 DELETE를 사용하는게 좋을 수도 있지만 의도에 따라 다르게 결정할 수 있다)
문제 해결
2번방식을 채택하는 대신, deletedAt이란 필드를 추가해서 삭제한 시간을 기록하고 스케줄러를 통하여 일정기간이 지난 사용자는 삭제하도록 구현하기로 했다. 2번 방안에서 문제가 되었던 조회시 회원탈퇴인원까지 탐색하게 되는 부분에 대해 일정 방안이 될 . 수있다.
+) JPA Soft Delete를 검색해서 추가 방안을 찾아보기로
2. Column과 Card의 순서 이동 구현방식에 대한 고민
고민한 방법
1) 우서순위 필드를 추가하여 이 값을 참조하여 정렬하기
2) 자료구조를 사용하여 (linkedList) 구현
이 두가지 방법이 있었는데,
1번의 경우 예를들어 100번째순위를 2번순위로 바꾼다하면 이 이동으로 인해 여러번의 쿼리가 날라간다는 점에서 성능에 문제가 될거라는 생각이 들어 다른 좋은 방법이 없을까 고민을 하게 되었다.
2번의 경우 Database상에서 구현이 가능한지에 대한 의문이 들었다.
결론
해당 방법은 튜터님들과 이야기하며 풀었는데
1번의 경우 Update쿼리를 날릴 때 Between을 사용하여 하나의 쿼리로 날릴 수 있는 방법이 있다.
쿼리는 하나가 날라가지만 DB에서 하는 동작은 해당 범위의 값이 모두 수정되어야하니 성능적으로 문제가 있지 않을까 했지만, MySQL로 구현할 수 있는 방식으로는 최선이라고 했다.
제일 좋은 방법은 NoSQL로 해당 부분을 구현하는게 좋지만, 이 부분은 일단 보류하기로 했다.
2번의 경우 관계형 데이터베이스인 MySQL에서 구현할때는 1번보다 여러 쿼리가 생성되어 성능이 매우 안좋고, 추천되지 않는 구현방식이라고 하였다.
