미리보기

DB탐색 [Indexing]

MySQL을 사용한 Spring boot 프로젝트에서 게시글을 검색하는데
JPA을 사용하여 단순 ORM을 날려서 검색을 한다고 가정해보면

List<Posts> postsList = postsRepository.findByTitleContaining(keyword);

이는 쿼리문으로 다음과 같습니다.

SELECT p From Posts p WHERE p.title LIKE %:keyword%

이 쿼리문의 문제점은 2가지입니다.

1. 정확하게 "특정한 단어"가 포함된 title의 Post만 가져온다는 것

2. JPA의 특성상 N+1 문제가 생길 수 밖에 없다는 것

그래서 해결 방법으로 indexing, Querydsl을 사용했습니다.
우선 사용하고 있는 DB, MySQL에 title column을 indexing 하였습니다.
이 때, indexing을 하는 방법으로 MySQL에서 기본적으로 제공하는 Indexing인,

FULL-TEXT Indexing (with N-gram parser)이 있습니다.

제목과 같은 특정 단어를 검색했을때 검색이 되도록하려면 FULL-TEXT Indexing을 해야된다 생각하였고,
한글의 특성상 N-gram parser를 꼭 사용해야 검색의 결과가 유의미하다 생각하여 추가하였습니다.

CREATE FULLTEXT INDEX idx_title_fulltext ON Posts(title) WITH PARSER ngram;;

이렇게 만들어진 FULL-TEXT 인덱스를 사용하기 위해서는 Querydsl이 필요합니다. 이를 PostServiceImpl 에 다음과 같이 Querydsl를 사용해 쿼리문을 작성합니다.

@Autowired private JPAQueryFactory queryFactory;
@Override public List<Posts> findByTitleContaining(String keyword) {

    QPosts posts = QPosts.posts;

    BooleanExpression matchExpression =
        Expressions.booleanTemplate( "MATCH({0}) AGAINST ({1} IN BOOLEAN MODE)",
        posts.title, keyword);
        return queryFactory.selectFrom(posts)
                 .leftJoin(post.post_writer, post_writer).fetchJoin()
                 .where(matchExpression)

이제 이렇게 작성된 코드는 JPA의 고질적인 문제인 N+1문제도 해결됩니다.

이후 PostServiceImpl을 PostService에 implements 하여 인터페이스를 불러오고,

그 PostService를 PostController에 불러와 사용하면 됩니다.

다만, 이렇게 만들어진 코드를 hibernate를 사용하여 로그를 확인해봤을때,

쿼리문의 갯수가 기존 N+1에서 1개로 확실하게 줄어들었긴했지만, 출력되는 시간은 비슷했습니다.

이렇게 된 이유로는 2가지가 추정되는데

1. 작성된 Post의 숫자가 적어서 딱히 시간 단축이 일어날 정도의 효과가 일어나지 않았다.

2. 가입된 Member의 숫자가 적어서 기존에도 딱히 N+1의 문제가 심각하기 일어나지 않았다.

그럼에도 db에 요청하는 query문의 갯수가 확연하게 줄어들었으며,

장기적인 서비스를 제공할시 이는 DB서버에 부하를 줄여주는 긍정적인 효과를 가져올 것입니다.

DB column 갯수 최적화 [확장성 있는 Table 설계]

plus x 전자 결재 시스템을 구현하는 과제를 하는 과정에서 이를 최적화 할 수 있는 방법이 없을까 고민했습니다.

기존의 column은 다음과 같습니다.

• 결재자 0, 결재자 0의 승인여부 (재고 중, 반려, 승인), 결재자 0의 결재 시간

• 결재자 1, 결재자 1의 승인여부 (결재자 1 null, 결재자 0이 아직 결재 안함, 재고 중, 반려, 승인), 결재자 1의 결재 시간

• 결재자 2, 결재자 2의 승인여부 (결재자 2 null, 결재자 1이 아직 결재 안함, 재고 중, 반려, 승인), 결재자 2의 결재 시간

이 정도로 하나의 row에 많은 정보를 담아야 되는 경우는 처음이였기 때문에,

지나치게 복잡하다 생각하여 Char Field와 Integer Field중에 무엇이 더 나은지 고민하게 되었습니다.

만약에 Char Field로 구성을 하게 된다면 다음과 같은 장점이 있습니다.

1. 직관적으로 사람이 읽고 이해하기 쉽습니다.

만약 Integer Field로 구성을 하게 된다면 다음과 같은 장점이 있습니다.

1. 정수형 데이터는 일반적으로 더 적은 저장 공간을 차지합니다.

2. 정수 비교는 텍스트 비교보다 빠르므로 성능이 더 좋습니다.

3. 사전에 정의된 숫자 ID와 매핑되므로 데이터가 더 일관되고 무결성이 보장됩니다.

결재자의 유무를 Boolean Field로 나누는 방법도 생각해봤으나, 오히려 복잡도를 가중시킬 것 같아서 제외했습니다.

결과적으로, 다음과 같은 이유로 Integer Field를 유지하게 되었습니다.

    # 결재 승인할 대상 (최대 3명) 0 -> 아예 없어야 함, 1 -> 결재를 해야되는 대상이지만 당장은 아님, 2 -> 재고 중, 3 -> 반려, 4 -> 승인
    reviewer_0 = models.ForeignKey(settings.AUTH_USER_MODEL, related_name='review_1st_approval', on_delete=models.PROTECT)
    is_pass_0 = models.IntegerField(default=2)
    is_pass_0_time = models.DateTimeField(auto_now=True)

    reviewer_1 = models.ForeignKey(settings.AUTH_USER_MODEL, related_name='review_2nd_approval',on_delete=models.PROTECT,null=True)
    is_pass_1 = models.IntegerField(default=0)
    is_pass_1_time = models.DateTimeField(auto_now=True)

    reviewer_2 = models.ForeignKey(settings.AUTH_USER_MODEL, related_name='review_3rd_approval',on_delete=models.PROTECT,null=True)
    is_pass_2 = models.IntegerField(default=0)
    is_pass_2_time = models.DateTimeField(auto_now=True)

    # 최종적으로 마지막까지 승인이 된다면...! 0 -> 아직 아무것도 진행안됨, 1 -> 최종반려, 2 -> 최종승인, 3 -> 이미 진행됨
    final_approval = models.IntegerField(default=0)
    final_approval_time = models.DateTimeField(auto_now=True)
    reject_reason = models.CharField(max_length=500, null=True,blank=True)

댓글, 대댓글 깊이 구현

댓글 밑에 대댓글이 달리면 깊이가 "1" 만큼 더 들어가 대댓글임을 표현할 수 있도록 구현했습니다.

1. Post가 작성됨

2. A가 Comment를 작성함

3. B가 A의 Comment에 reComment를 작성함

4. 이 때 B의 댓글은 A의 댓글의 '밑에 위치하며 깊이가 "1만큼" 더 들어가야함

이를 위해서 Comment의 column에는 다음과 같은 정보가 필요합니다.

1. Integer Ordernumber // 몇 번째 순서에 이 댓글이 위치할지

2. Integer Depth // 이 댓글은 깊이가 몇인지

이를 위해서 다음과 같이 Column을 구성했습니다.

@Entity
@Getter
@ToString
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Comment extends JpaBaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String content;

    ... 생략 ...

    private Integer depth;
    private Long orderNumber;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Comment parent;

    @OneToMany(mappedBy = "parent")
    private List<Comment> replies = new ArrayList();

    public Comment (String content, Post post, Comment parent, Member writer) {
        this.content = content;
        this.post = post;
        this.comment_writer = writer;
        this.parent = parent;
        if (parent == null) {
            this.depth = 0;
            this.orderNumber = post.getCommentCnt();
        } else {
            this.depth = Math.min(parent.getDepth()+1,5) ;
            this.orderNumber = parent.getOrderNumber();
        }
        this.deletedTime = null;
        this.deletedTrue = false;
        this.likes = 0L;
    }
    ... 생략 ...

    public void repliesSet (Comment comment) {
        this.replies.add(comment);
    }
}

1. 댓글을 작성한다

2. 부모 댓글이 없다면 Post의 OrderNumber +1 하여 row 저장

3. 만약 부모 댓글이 존재 한다면, 부모 댓글의 OrderNumber을 그대로 저장하고 부모 댓글의 Depth + 1 하여

   row에 저장됩니다.

이후 댓글을 불러오는 쿼리문은 다음과 같습니다.

QueryResults<Comment> results = queryFactory.selectFrom(qcomment)
                .leftJoin(qcomment.comment_writer,QMember.member)
                .where(qcomment.deletedTrue.eq(false),
                        qcomment.post.eq(post))
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())

                .orderBy(qcomment.orderNumber.asc(),
                        qcomment.id.asc())

                .fetchResults();

        List<Comment> comments = results.getResults();

다음과 같이 orderBy를 설정하면 구현하고 싶었던 댓글, 대댓글을 구현할 수 있고,

댓글의 Pagination도 문제없이 구현할 수 있습니다.

이후 html에서 템플릿 엔진으로 데이터를 가져올때 Depth에 따라 깊이를 설정하면

댓글, 대댓글, 그리고 대댓글의 깊이까지 구현이 가능합니다.