하위 폴더 및 북마크 삭제 완벽히 안됨.

[Sun26-Avrin]

a83d197#r63703508

하위 노드 삭제 방안

1. 삭제로직을 재귀함수로 구현.

• 자손노드 완벽히 삭제가능 (자손노드 갯수가 많으면 OOM 발생할 듯)

2. 해당 폴더의 child들을 저장하는 매핑 테이블을 따로 만든다.

• 테이블 구현에 따라 select 1회로도 실현가능하지만 1회 실현을 위한 DB 공간 비용이 더 비싸보인다.

3. 대상노드의 바로 아래 자식노드들만 삭제처리 (추가)

이렇게만 해도 사실 프론트단에서 대상노드의 자손노드로 접근 할 수 없음.
그러나, 추후 데이터에 기초한 비즈니스를 할 때 삭제처리가 유의미한 벡터가 될 수도 있으므로 임시방편에 불과

4. 실제 리소스 접근때에 lazy하게 쿼리를 내보낸다. (추가)

• 바로 아래 자식노드만 삭제처리하고, 더 하위의 노드들에 접근 시 그때 lazy하게 삭제쿼리를 실행.

3번 방안의 2번째 이유와 같은 이유로 임시방편에 불과
Job을 예약할 수 있으나, 굳이 그렇게 처리해야할 매력을 느끼지 못함.
(서비스 특성상 Depth 보다 Width가 더 클 것으로 예상)

5. 큐를 이용한 BFS 구현으로 다음 Depth 로 넘어가기 전까지 같은 레벨의 노드정보를 담아 Select 횟수를 줄인다. (추가)

= @batchsize 의 작동원리와 유사

• 자가참조엔티티로 구성하여 @batchsize로 구현가능하나, Folder 와 Bookmark 가 @OneToMany 관계라서 getFolders() 호출 후 가져온 폴더들(N개)을 대상으로 다시 getBookmarks() 를 호출해야 함.

@batchsize 로 getFolders()에서 Select 한번 + JPA 쿼리메소드 IN절로 getBookmarks()에서 Select 한번으로 처리가 가능

6. 조인전략으로 테이블을 구성하여 Item -> Folder (OneToOne) , Item -> Bookmark (OneToOne) 으로 구성하면, getItems() Select 1회 호출로 Folder Bookmark 구분 없이 Fetch 가능. (최종)

쿼리문 갯수 비교

대상노드의 자손노드가 N개 일 때

[1번 방안] 재귀함수 호출시마다 쿼리문이 호출. (N개의 Select + N개의 Update)

[2번 방안] 해당 폴더의 모든 child 를 가져오는 하나의 select 문이 호출된다. (1개의 Select + 1개의 Update)

메모리 사용량 비교

대상노드의 자손노드가 N개 일 때

[1번 방안] 재귀호출 첫 종료시 시그마연산(노드갯수(N)*각노드의 리프노드)개의 아이템이 메모리에 올라감 + 재귀호출마다의 select 호출비용

[2번 방안] Select문으로 조회시 N개의 아이템이 메모리에 올라감

DB 사용량 비교

2번 > 1번

[Sun26-Avrin]

692632c

3 번 방법을 채택. 대상노드와 자식노드만 삭제처리 했음.

나중에 서비스가 어떻게 변할지 모르기에, 현재 서비스에서만 작동하는 것은 옳지 않음.
추후 4번 방안, lazy 하게 연결된 모든 노드가 삭제되도록 구현 예정.

[Sun26-Avrin]

Depth+1 번의 Select 호출로 엔티티 삭제 처리 예정.

서비스 특성상 depth보다 width가 클 예정이라 매우 만족스러운 성능을 기대

[Sun26-Avrin]

f3c07c9 해결

[Sun26-Avrin]

5, 6번 방법을 섞어서 다시 리팩토링 예정