1031 ~ 1113

# 1031 ~ 1113

# 1031 - [Gradle] implementation vs compile

[ api(compile) ]

The dependencies required to compile the production source of the project which are part of the API exposed by the project. For example the project uses Guava and exposes public interfaces with Guava classes in their method signatures.

[ implementation ]

The dependencies required to compile the production source of the project which are not part of the API exposed by the project. For example the project uses Hibernate for its internal persistence layer implementation.

compile은 상위 모듈까지 가져온다. compile은 implementation 보다 더 많은 라이브러리를 빌드한다. 예를 들어 다음과 같이 의존하는 관계의 프로젝트 세 개가 있다고 가정했을 때

myApp -> mySpring -> myJava

compile을 사용해서 mySpring을 빌드하게 되면 의존하고 있는 myJava까지 함께 빌드한다.
implementation을 사용해서 빌드하면 mySpring 모듈만 가져오기 때문에 빌드 속도가 빠르고 필요한 API만 노출해서 사용할 수 있다. 또한 complie은 deprecated 되고 api로 대체됐다.

# 1103 - 커서 기반 페이지네이션

[ 오프셋 기반 페지 네션의 한계 ]

각각의 페이지를 요청하는 사이에 데이터의 변화가 있는 경우 중복 데이터가 노출된다.
대부분의 RDBMS에서 OFFSET 쿼리의 퍼포먼스 이슈가 있다.

오프셋은 단순히 레코드를 조회하기 전에 데이터 베이스가 건너 뛰는 레코드의 수다.
즉, 요청한 데이터를 바로 조회하는 것이 아니라 이전의 데이터를 모두 조회하고 그 ResultSet에서 오프셋을 조건으로 잘라내는 것이다.

# 커서 기반 페이지네이션(Cursor-based Pagination)이란?

커서 개념을 사용한다. 사용자에게 응답해준 마지막의 데이터의 식별자 값이 Cursor가 된다.
커서를 기준으로 다음 n개의 데이터를 응답해주는 방식이다.

[ 구현 ]

Querydsl

public Page<Club> findClubsByCondition(Long cursorId, ClubFindCondition condition, Account loginAccount,
                                       Pageable pageable) {

    List<AccountClub> findAccountClubs = queryFactory.selectFrom(accountClub)
						...
            .where(
                    cursorId(cursorId)
										...
            )
            .limit(pageable.getPageSize())
            .fetch();

    ...
}

private BooleanExpression cursorId(Long cursorId){
    return cursorId == null ? null : club.id.gt(cursorId);
}

public List<BookPaginationDto> paginationNoOffset(Long bookId, String name, int pageSize) {

    return queryFactory
            .select(Projections.fields(BookPaginationDto.class,
                    book.id.as("bookId"),
                    book.name,
                    book.bookNo))
            .from(book)
            .where(
                    ltBookId(bookId),
                    book.name.like(name + "%")
            )
            .orderBy(book.id.desc())
            .limit(pageSize)
            .fetch();
}

private BooleanExpression ltBookId(Long bookId) {
    if (bookId == null) {
        return null; // BooleanExpression 자리에 null이 반환되면 조건문에서 자동으로 제거된다
    }

    return book.id.lt(bookId);
}

[ 단점 ]

where에 사용되는 기준 Key가 중복이 가능할 경우
- 이를 테면 group by 등으로 기준으로 잡을 Key가 중복이 될 경우 정확한 결과를 반환할 수 없어서 사용할 수가 없다.
UX관점에서 페이징 버튼 형식으로 해야할 경우 사용불가

# 1109 - 커버링 인덱스

# Using index

커버링 인덱스 (쿼리의 모든 항목이 인덱스 컬럼으로 이루어진 상태)

# Non Clustered Key와 Clustered Key

Clustered Key
- 대상 : PK, PK가 없을땐 유니크키, 둘다 없을 경우 6byte의 Hidden Key를 생성(rowid)
- 제한 : 테이블당 1개만 존재 가능
Non Clustered Key
- 대상 : 일반적인 인덱스
- 제한 : 여러개 생성 가능

Non Clustered Key(일반적인 인덱스)에는 인덱스 컬럼의 값들과 Clustered Key(PK)의 값이 포함되어 있다
Clustered Key 만이 실제 테이블의 row 위치를 알고 있다

인덱스 조건에 부합한 where 조건이 있더라도 select에 인덱스에 포함된 컬럼 외에 다른 컬럼값이 필요할때는 Non Clustered Key에 있는 Clusterd Key 값으로 데이터 블록을 찾는 과정이 필요하다.
다만 PK를 사용할 경우 인덱스 탐색 시간이 없어지기 때문에 향상된 데이터 파일 접근이 가능하다.
커버링 인덱스는 여기서 "실제 데이터 접근"의 행위 없이 인덱스에 있는 컬럼값들로만 쿼리를 완성하는 것을 이야기한다.

[ WHERE + GROUP BY ] GROUP BY 인덱스 적용 조건

GROUP BY 절에 명시된 컬럼이 인덱스 컬럼의 순서와 같아야 한다.
- 아래 모든 케이스는 인덱스가 적용 안된다. (index: a,b,c)
- group by b
- group by b, a
- group by a, c, b
인덱스 컬럼 중 뒤에 컬럼이 GROUP BY 절에 명시되지 않아도 사용할 수 있다.
- 아래 모든 케이스는 인덱스가 적용된다. (index: a,b,c)
- group by a
- group by a, b
- group by a, b, c
반대로 인덱스 컬럼 중 앞에 있는 컬럼이 GROUP BY 절에 명시되지 않으면 인덱스를 사용할 수 없다.
- ex: (index: a,b,c), group by b, c 는 인덱스 적용 안됨
인덱스에 없는 컬럼이 GROUP BY 절에 포함되어 있으면 인덱스가 적용되지 않는다.
- ex: (index: a,b,c), group by a,b,c,d 는 인덱스 적용안됨

여기서 WHERE 조건과 GROUP BY가 함께 사용되면 WHERE 조건이 동등 비교일 경우 GROUP BY 절에 해당 컬럼은 없어도 인덱스가 적용된다.

WHERE a = 1 
GROUP BY b, c

WHERE a = 1 and b = 'b'
GROUP BY c

# 1113 - 커버링 인덱스를 활용한 페이징 성능 개선

커버링 인덱스란 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 이야기한다.
즉, select, where, order by, limit, group by 등에서 사용되는 모든 컬럼이 Index 컬럼안에 다 포함된 경우이다.

페이징 성능을 개선할때나 실제로 커버링 인덱스를 태우는 부분은 select를 제외한 나머지만 우선으로 수행한다.

-- AS BE
SELECT *
FROM items
WHERE 조건문
ORDER BY id DESC
OFFSET 페이지번호
LIMIT 페이지사이즈

-- TO BE
SELECT  *
FROM  items as i
JOIN (SELECT id
        FROM items
        WHERE 조건문
        ORDER BY id DESC
        OFFSET 페이지번호
        LIMIT 페이지사이즈) as temp on temp.id = i.id

[ 커버링 인덱스가 빠른이유 ]
일반적으로 인덱스를 이용해 조회되는 쿼리에서 가장 큰 성능 저하를 일으키는 부분은 인덱스를 검색하고 대상이 되는 row의 나머지 컬럼값을 데이터 블록에서 읽을 때이다.
페이징 쿼리와 무관하게 인덱스를 탔음에도 느린 쿼리의 경우 이 select절 항목때문이다.
이를테면 커버링 인덱스를 태우지 않은 일반적인 조회 쿼리는 order by, offset ~ limit을 수행할때도 데이터 블록으로 접근하게 된다. 반대로 커버링 인덱스 방식을 이용하면, where, order by, offset ~ limit을 인덱스 검색으로 빠르게 처리하고, 이미 다 걸러진 10개의 row에 대해서만 데이터 블록에 접근하기 때문에 성능의 이점을 얻게 된다.

[ Querydsl-JPA 구현코드 ]
querydsl-jpa에서 커버링 인덱스를 사용해야 한다면 2개의 쿼리로 분리해서 진행할 수 밖에 없다. 이유는 Querydsl-jpa에서 from절의 서브쿼리를 지원하지 않기 때문이다.

커버링 인덱스를 활용해 조회 대상의 PK를 조회
해당 PK로 필요한 컬럼항목들 조회

public List<BookPaginationDto> paginationCoveringIndex(String name, int pageNo, int pageSize) {
        // 1) 커버링 인덱스로 대상 조회
        List<Long> ids = queryFactory
                .select(book.id)
                .from(book)
                .where(book.name.like(name + "%"))
                .orderBy(book.id.desc())
                .limit(pageSize)
                .offset(pageNo * pageSize)
                .fetch();

        // 1-1) 대상이 없을 경우 추가 쿼리 수행 할 필요 없이 바로 반환
        if (CollectionUtils.isEmpty(ids)) {
            return new ArrayList<>();
        }

        // 2)
        return queryFactory
                .select(Projections.fields(BookPaginationDto.class,
                        book.id.as("bookId"),
                        book.name,
                        book.bookNo,
                        book.bookType))
                .from(book)
                .where(book.id.in(ids))
                .orderBy(book.id.desc())
                .fetch(); // where in id만 있어 결과 정렬이 보장되지 않는다.
}

[ JdbcTemplate 구현코드 ]

public List<BookPaginationDto> paginationCoveringIndexSql(String name, int pageNo, int pageSize) {
String query =
        "SELECT i.id, book_no, book_type, name " +
        "FROM book as i " +
        "JOIN (SELECT id " +
        "       FROM book " +
        "       WHERE name LIKE '?%' " +
        "       ORDER BY id DESC " +
        "       LIMIT ? " +
        "       OFFSET ?) as temp on temp.id = i.id";

return jdbcTemplate
        .query(query, new BeanPropertyRowMapper<>(BookPaginationDto.class),
                name,
                pageSize,
                pageNo * pageSize);
}