조회 성능을 높이기 위한 PK 설계

인덱싱이 필요하다

@Table(name = "application")
@Entity
@Getter
public class Application {
    @Id
    private String id; // UUID.randomUUID().toString()
}

데이터베이스를 설계할때 애플리케이션 내부용 키로는 increment pk를, 외부에 공개할 키로는 uuid를 사용하는 것을 권장한다.

UUID의 문제

16바이트 문자열 길이로 인한 인덱스 크기가 크고 데이터베이스에 더 많은 저장 공간을 차지 한다.
데이터가 많으면 많아질수록 조회할때 랜덤문자열을 조회하는 경우 인덱스가 의미가 없어진다.

해결방법 1. 숫자형 PK로 변경

조회 이슈에 대한 해결방안이다. 문자형으로 UUID를 만들었을때 가장 큰 문제는 인덱싱을해도 뒤죽박죽한 문자열로 인한 조회성능이 좋지 않다.
+ 컴퓨터는 결국 0과 1로 이루어져있기 때문에 숫자형 PK는 비교적 짧은 길이를 가지기 때문에 인덱스 크기가 작고 저장공간을 적게 차지한다.
- 숫자형은 문자형에 비해 경우의 수가 작기때문에 다중 데이터베이스나 분산 시스템에서 PK 충돌 발생가능성이 있다.

해결방법 2. name을 통한 조회

@Table(name = "application", indexes = {@Index(name = "idx_name", columnList = "name")})
@Entity
@Getter
public class Applications {
    @Id
    private String id; // UUID.randomUUID().toString()
}
	private Stinrg name;

name 애트리뷰트 추가하여 name 을 통환 조회로 해결

SELECT 	* 
FROM 	Applications 
WHERE 	name = ?

마무리

실험삼아 PK가 아닌 랜덤 문자열이 애트리뷰트를 생성하고 인덱스를 생성하려고 했었는데 인덱스 크기가 너무 커져서 적용이 안되는 문제가 발생하여 해결하는 데에 도움이 되었다.