개발할때 확실히 도움이 되는 tip!!
잘난척 하지 말고 꼭 보시길~

https://blog.jetbrains.com/idea/2023/02/debugger-upskill-stepping/

The best UUID type for a database Primary Key

소개

이 기사에서는 기본 키 제약 조건이 있는 데이터베이스 열에 가장 적합한 UUID(Universally Unique Identifier) ​​유형을 살펴보겠습니다.

표준 128비트 임의 UUID가 매우 인기 있는 선택이지만 이것이 데이터베이스 기본 키 열에 적합하지 않다는 것을 알게 될 것입니다.

표준 UUID 및 데이터베이스 기본 키

UUID(Universally Unique Identifier)는 식별자의 고유성을 보장하는 단일 중앙 시스템 없이도 독립적으로 생성할 수 있는 128비트 의사 난수 시퀀스입니다.

RFC 4122 사양은 다양한 데이터베이스 기능 또는 프로그래밍 언어로 구현되는 5가지 표준화된 UUID 버전을 정의합니다 .

예를 들어 UUID()MySQL 함수는 버전 1 UUID 번호를 반환합니다.

그리고 Java UUID.randomUUID()함수는 버전 4 UUID 번호를 반환합니다.

많은 개발자에게 이러한 표준 UUID를 데이터베이스 식별자로 사용하는 것은 다음과 같은 이유로 매우 매력적입니다.

• ID는 애플리케이션에서 생성할 수 있습니다. 따라서 중앙 조정이 필요하지 않습니다.
• 식별자 충돌 가능성은 매우 낮습니다.
• id 값은 무작위이므로 사용자가 다른 식별자 값을 추측하여 다른 사람의 데이터를 보는 데 사용할 수 없으므로 안전하게 UI로 보낼 수 있습니다.

그러나 임의의 UUID를 데이터베이스 테이블 기본 키로 사용하는 것은 여러 가지 이유로 좋지 않습니다.

첫째, UUID는 거대합니다. 모든 단일 레코드는 데이터베이스 식별자로 16바이트가 필요하며 이는 연결된 모든 외래 키 열에도 영향을 미칩니다.

둘째, 기본 키 열에는 일반적으로 조회 또는 조인 속도를 높이기 위해 연결된 B+Tree 인덱스가 있으며 B+Tree 인덱스는 데이터를 정렬된 순서로 저장합니다.

그러나 B+Tree를 사용하여 임의의 값을 인덱싱하면 많은 문제가 발생합니다.

• 값이 무작위로 제공되기 때문에 인덱스 페이지의 채우기 비율은 매우 낮습니다. 따라서 8kB의 페이지는 몇 가지 요소만 저장하게 되므로 인덱스 페이지가 버퍼 풀에 캐시될 수 있으므로 디스크와 데이터베이스 메모리 모두에서 많은 공간을 낭비하게 됩니다.
• B+Tree 인덱스는 등거리 트리 구조를 유지하기 위해 자체적으로 균형을 재조정해야 하기 때문에 트리 구조를 채우는 미리 결정된 순서가 없기 때문에 무작위 키 값으로 인해 더 많은 인덱스 페이지 분할 및 병합이 발생합니다.

SQL Server 또는 MySQL을 사용하는 경우 전체 테이블이 기본적으로 클러스터된 인덱스 이기 때문에 상황은 더욱 악화됩니다 .

그리고 이러한 모든 문제는 보조 인덱스 리프 노드에 기본 키 값을 저장하기 때문에 보조 인덱스에도 영향을 미칩니다.

실제로 거의 모든 데이터베이스 전문가는 표준 UUID를 데이터베이스 테이블 기본 키로 사용하지 말라고 말합니다.

• Percona: UUID는 인기가 있지만 성능에는 좋지 않습니다.
• 기본 키로 UUID 또는 GUID? 조심해요!
• 정체성 위기: 시퀀스 대 기본 키로서의 UUID

TSID – 시간순으로 정렬된 고유 식별자

기본 키 열에 UUID 값을 저장하려는 경우 TSID(시간 정렬 고유 식별자)를 사용하는 것이 좋습니다.

이러한 구현 중 하나 는 다음 두 부분으로 구성된 64비트 TSID를 제공하는 TSID Creator OSS 라이브러리 에서 제공됩니다 .

• 42비트 시간 구성요소
• 22비트 랜덤 구성 요소

랜덤 구성 요소는 두 부분으로 구성됩니다.

• 노드 식별자(0~20비트)
• 카운터(2~22비트)

tsidcreator.node애플리케이션을 부트스트랩할 때 시스템 속성 에서 노드 식별자를 제공할 수 있습니다 .

-Dtsidcreator.node="12"

노드 식별자는 TSIDCREATOR_NODE환경 변수를 통해 제공될 수도 있습니다.

export TSIDCREATOR_NODE="12"

라이브러리는 Maven Central에서 사용할 수 있으므로 다음 종속성을 통해 가져올 수 있습니다.

<dependency>
    <groupId>com.github.f4b6a3</groupId>
    <artifactId>tsid-creator</artifactId>
    <version>${tsid-creator.version}</version>
</dependency>

Tsid다음과 같이 최대 256개의 노드를 사용할 수 있는 개체를 만들 수 있습니다 .

Tsid tsid = TsidCreator.getTsid256();

개체 에서 Tsid다음 값을 추출할 수 있습니다.

• 64비트 숫자 값,
• 64비트 값을 인코딩하는 Crockford 의 Base32 문자열 값,
• 42– 비트 시퀀스 에 저장된 에포크 이후 Unix 밀리초

이러한 값을 시각화하기 위해 로그에 인쇄할 수 있습니다.

long tsidLong = tsid.toLong();
String tsidString = tsid.toString();
long tsidMillis = tsid.getUnixMilliseconds();

LOGGER.info(
    "TSID numerical value: {}",
    tsidLong
);

LOGGER.info(
    "TSID string value: {}",
    tsidString
);

LOGGER.info(
    "TSID time millis since epoch value: {}",
    tsidMillis
);

그리고 다음과 같은 결과를 얻습니다.

TSID numerical value: 388400145978465528
TSID string value: 0ARYZVZXW377R
TSID time millis since epoch value: 1670438610927

10개의 값을 생성할 때:

for (int i = 0; i < 10; i++) {
    LOGGER.info(
        "TSID numerical value: {}",
        TsidCreator.getTsid256().toLong()
    );
}

값이 단조롭게 증가하는 것을 볼 수 있습니다.

TSID numerical value: 388401207189971936
TSID numerical value: 388401207189971937
TSID numerical value: 388401207194165637
TSID numerical value: 388401207194165638
TSID numerical value: 388401207194165639
TSID numerical value: 388401207194165640
TSID numerical value: 388401207194165641
TSID numerical value: 388401207194165642
TSID numerical value: 388401207194165643
TSID numerical value: 388401207194165644

굉장하죠?

애플리케이션에서 TSID 사용

유틸리티 를 통해 제공되는 기본 TSID 팩터리는 동기화된 임의 값 생성기와 함께 제공되므로 다음과 같은 최적화를 제공하는 TsidCreator사용자 정의를 사용하는 것이 좋습니다 .TsidFactory

• 를 사용하여 임의의 값을 생성할 수 있으므로 ThreadLocalRandom동기화된 블록에서 스레드 차단을 방지합니다.
• 적은 수의 노드 비트를 사용할 수 있으므로 임의 생성 수치에 더 많은 비트를 남길 수 있습니다.

따라서 새 개체를 생성할 때마다 사용할 수 있도록 TsidUtil다음 을 정의할 수 있습니다 .TsidFactoryTsid

public static class TsidUtil {
    public static final String TSID_NODE_COUNT_PROPERTY =
        "tsid.node.count";
    public static final String TSID_NODE_COUNT_ENV =
        "TSID_NODE_COUNT";

    public static TsidFactory TSID_FACTORY;

    static {
        String nodeCountSetting = System.getProperty(
            TSID_NODE_COUNT_PROPERTY
        );
        if(nodeCountSetting == null) {
            nodeCountSetting = System.getenv(
                TSID_NODE_COUNT_ENV
            );
        }

        int nodeCount = nodeCountSetting != null ?
            Integer.parseInt(nodeCountSetting) :
            256;

        int nodeBits = (int) (Math.log(nodeCount) / Math.log(2));

        TSID_FACTORY = TsidFactory.builder()
            .withRandomFunction(length -> {
                final byte[] bytes = new byte[length];
                ThreadLocalRandom.current().nextBytes(bytes);
                return bytes;
            })
            .withNodeBits(nodeBits)
            .build();
    }
}

그리고 동일한 애플리케이션 노드에서 여러 스레드를 사용하는 경우에도 충돌이 발생하지 않는다는 것을 입증하기 위해 다음 테스트 사례를 사용할 수 있습니다.

int threadCount = 16;
int iterationCount = 100_000;

CountDownLatch endLatch = new CountDownLatch(threadCount);

ConcurrentMap<Tsid, Integer> tsidMap = new ConcurrentHashMap<>();

long startNanos = System.nanoTime();

for (int i = 0; i < threadCount; i++) {
    final int threadId = i;
    new Thread(() -> {
        for (int j = 0; j < iterationCount; j++) {
            Tsid tsid = TsidUtil.TSID_FACTORY.create();
            assertNull(
                "TSID collision detected",
                tsidMap.put(
                    tsid,
                    (threadId * iterationCount) + j
                )
            );
        }

        endLatch.countDown();
    }).start();
}

LOGGER.info("Starting threads");
endLatch.await();

LOGGER.info(
    "{} threads generated {} TSIDs in {} ms",
    threadCount,
    new DecimalFormat("###,###,###").format(
        threadCount * iterationCount
    ),
    TimeUnit.NANOSECONDS.toMillis(
        System.nanoTime() - startNanos
    )
);

이 테스트를 실행하면 다음과 같은 결과를 얻습니다.

16 threads generated 1,600,000 TSIDs in 781 ms

ISID 생성은 충돌이 없었을 뿐만 아니라 800밀리초 이내에 160만 개의 ID를 생성했습니다.

결론

표준 UUID를 기본 키 값으로 사용하는 것은 첫 번째 바이트가 단조롭게 증가하지 않는 한 좋은 생각이 아닙니다.

이러한 이유로 시간 정렬된 TSID를 사용하는 것이 훨씬 더 좋은 생각입니다. 표준 UUID로 절반의 바이트 수를 필요로 할 뿐만 아니라 B+Tree 인덱스 키로 더 적합합니다.

SQL Server는 NEWSEQUENTIALID 를 통해 시간 정렬된 GUID를 제공하지만 GUID의 크기는 128비트이므로 TSID보다 두 배 큽니다.

동일한 문제는 시간 정렬된 UUID를 제공하는 UUID 사양 버전 7 에서도 발생합니다. 그러나 너무 큰 동일한 표준 형식(128비트)을 사용합니다. 기본 키 열 저장소의 영향은 참조하는 모든 외래 키 열에 의해 증폭됩니다.

모든 기본 키가 128비트 UUID인 경우 버퍼 풀이 테이블 페이지와 인덱스 페이지를 모두 보유하므로 디스크와 데이터베이스 메모리 모두에서 기본 키 및 외래 키 인덱스에 많은 공간이 필요합니다.

버전 6.0의 새로운 기능

JDK 17+ 및 Jakarta EE 9+ 기준선

• 이제 Java 17 소스 코드 수준을 기반으로 하는 전체 프레임워크 코드베이스입니다.
• Servlet, JPA 등의 네임스페이스를 위해 javax 에서 jakarta로 마이그레이션됩니다
• Jakarta EE 9 및 Jakarta EE 10 API와의 런타임 호환성.
• 최신 웹 서버와 호환: Tomcat 10.1 , Jetty 11 , Undertow 2.3 .
• 가상 스레드 와의 초기 호환성 (JDK 19 현재 미리 보기).

일반 핵심 개정

• ASM 9.4 및 Kotlin 1.7로 업그레이드합니다.
• CGLIB 생성 클래스 캡처를 지원하는 완전한 CGLIB 포크.
• AOT( Ahead-Of-Time) 변환 을 위한 포괄적인 기반 .
• GraalVM 네이티브 이미지 에 대한 최고 수준의 지원 ( 관련 Spring Boot 3 블로그 게시물 참조).

코어 컨테이너

• 기본적으로 java.beans.Introspector 없이 기본 빈 속성 결정됩니다. 
• GenericApplicationContext(refreshForAotProcessing) 에서 AOT 처리 지원.
• 미리 해결된 생성자와 팩토리 메서드를 기반으로 한 빈 정의 변환.
• AOP 프록시 및 구성 클래스에 대한 초기 프록시 클래스 결정을 지원합니다.
• PathMatchingResourcePatternResolver가 NIO 및 모듈 경로 API를 스캔에 사용하여 각각 GraalVM 네이티브 이미지 및 Java 모듈 경로 내에서 클래스 경로 스캔을 지원합니다.
• DefaultFormattingConversionService가 ISO 기반 기본 java.time유형 구문 분석을 지원합니다.

데이터 액세스 및 트랜잭션

• 사전 결정 JPA 관리 유형 지원(AOT 처리에 포함).
• Hibernate ORM 6.1 에 대한 JPA 지원 (Hibernate ORM 5.6과의 호환성 유지).
• R2DBC 1.0 으로 업그레이드합니다 (R2DBC 트랜잭션 정의 포함).
• JCA CCI 지원 제거.

스프링 메시징

• @RSocketExchange 서비스 인터페이스 를 기반으로 하는 RSocket 인터페이스 클라이언트 .
• Netty 5 알파 를 기반으로 하는 Reactor Netty 2를 조기에 지원합니다 .
• Jakarta WebSocket 2.1 및 표준 WebSocket 프로토콜 업그레이드 메커니즘을 지원합니다.

일반 웹 개정

• @HttpExchange 서비스 인터페이스 를 기반으로 하는 HTTP 인터페이스 클라이언트 .
• RFC 7807 문제 세부 정보 지원 .
• 통합 HTTP 상태 코드 처리.
• 잭슨 2.14 지원.
• Servlet 6.0과의 정렬(Servlet 5.0과의 런타임 호환성을 유지하면서).

스프링 MVC

• PathPatternParser기본적으로 사용됩니다( 옵트인 기능 PathMatcher포함).
• 오래된 타일 및 FreeMarker JSP 지원 제거.

스프링 WebFlux

• 멀티파트 양식 업로드를 스트리밍하는 새로운 PartEvent API( 클라이언트 및 서버 모두 ).
• ResponseEntityExceptionHandler WebFlux 예외를 사용자 지정하고 RFC 7807 오류 응답 을 렌더링하는 새로운 기능 입니다.
• Flux비스트리밍 미디어 유형에 대한 반환 값(더 이상 List작성 전으로 수집되지 않음).
• Netty 5 알파 를 기반으로 하는 Reactor Netty 2를 조기에 지원합니다 .
• JDK HttpClient는 WebClient.

관찰 가능성

Spring Framework의 여러 부분에서 Micrometer Observation 을 사용한 Direct Observability instrumentation . spring-web모듈은 이제 컴파일 종속성으로 필요 합니다 io.micrometer:micrometer-observation:1.10+.

• RestTemplateHTTP 클라이언트 요청 관찰 을 WebClient생성하도록 계측됩니다.
• Spring MVC는 새로운 org.springframework.web.filter.ServerHttpObservationFilter.
• Spring WebFlux는 새로운 org.springframework.web.filter.reactive.ServerHttpObservationFilter.
• 컨트롤러 메서드 에 대한 마이크로미터 컨텍스트 전파Flux 및 반환 값과의 통합.Mono

테스트

• JVM 또는 GraalVM 네이티브 이미지 내에서 AOT 처리 애플리케이션 컨텍스트 테스트를 지원합니다.
• HtmlUnit 2.64+ 요청 매개변수 처리와 통합.
• 서블릿 모의( MockHttpServletRequest, MockHttpSession)는 이제 서블릿 API 6.0을 기반으로 합니다.

토르벤 얀센의 아티클 중 참고할 만한 내용을 퍼왔습니다.
https://thorben-janssen.com/6-performance-pitfalls-when-using-spring-data-jpa
먼저 글의 출처를 밝힙니다
이 사이트는 Hibernate와 JPA 의 최신 동향 정보를 확인할 수 있는 괜찮은 사이트입니다.

이 아티클의 내용은 JPA를 사용할 때 성능 문제를 회피하기 위한 6가지 함정을 소개하고 있습니다. 필요한 경우에는 어쩔 수 없이 써야겠지만 함정에 빠지지 않도록 조심해야겠네요.

• 1 함정 1: 개발 중에 데이터베이스 작업을 모니터링하지 마십시오
• 2 함정 2: 업데이트를 유지하기 위해 saveAndFlush() 메서드 호출
• 3 함정 3: 잘못된 전략을 사용하여 고유한 기본 키 값 생성
  • 3.1 데이터베이스 시퀀스 사용
  • 3.2 자동 증가 열 사용
• 4 함정 4: 즉시 가져오기 사용
• 5 함정 5: 가져올 연결을 지정하지 마십시오
  • 5.1 @EntityGraph 주석 사용
  • 5.2 JOIN FETCH 절 사용
• 6 함정 6: 복잡한 인터페이스 투영 사용
• 7. 결론

Spring Data JPA는 퍼시스턴스 레이어를 쉽게 구현할 수 있기 때문에 인기를 얻었습니다. 그러나 여전히 Spring Data JPA, JPA 구현 및 데이터베이스 작동 방식을 이해해야 합니다. 이를 무시하는 것은 성능 문제의 가장 일반적인 이유 중 하나이며 이 기사에서 설명하는 성능 함정에 빠지게 됩니다.

이러한 함정의 대부분을 피하려면 먼저 좋은 로깅 구성을 활성화해야 합니다. Hibernate의 통계는 실행된 모든 작업에 대한 개요를 제공하고 기록된 SQL 문은 데이터베이스와 상호 작용하는 방법을 보여줍니다.

업데이트 작업을 구현할 때 Spring Data JPA의 JpaRepository 에서 제공하는 saveAndFlush 메소드 호출을 피해야 합니다. 그리고 새로운 엔티티에 대한 기본 키 값을 생성할 때, GenerationType.SEQUENCE 를 선호하고  @SequenceGenerator 를 정의하여 Hibernate의 성능 최적화의 이점을 얻어야 합니다. 데이터베이스가 시퀀스를 지원하지 않는다면, Hibernate가 비효율적인 테이블 전략을 사용하는 것을 방지하기 위해 GenerationType.IDENTITY 를 명시적으로 정의해야 합니다.

엔터티 개체를 읽을 때 최상의 성능을 얻으려면 모든 연결의  FetchType  을 LAZY로 정의해야 합니다. 사용 사례에서 엔터티 간의 연결을 트래버스해야 하는 경우 엔터티 개체를 가져올 때 연결을 초기화하도록 지속성 공급자에게 알려야 합니다. 그렇게 하려면 쿼리에 JOIN FETCH 절을 추가하거나 @EntityGraph 주석으로 저장소 메서드에 주석을 추가할 수 있습니다.

또한 읽기 전용 작업에 DTO 프로젝션을 사용하는 경우 연결을 포함하는 복잡한 인터페이스 기반 DTO 프로젝션을 피해야 합니다. 그들은 Spring Data JPA가 DTO 프로젝션 대신 엔티티 프로젝션을 사용하도록 강제합니다.