[JPA] @GeneratedType - 키 생성 전략 알아보기

🌱 JPA 기본 키 생성 전략 

JPA에서 제공하는 기본 키 생성 전략은 크게 5가지로 나누어진다.
- TABLE, SEQUENCE, IDENTITY, UUID, AUTO

각 전략에 대해서 하나씩 알아보도록 하자.

---

 

🌱 TABLE

💡 Indicates that the persistence provider must assign primary keys for the entity using an underlying database table to ensure uniqueness.

- 데이터베이스 테이블을 사용하여 엔티티에 기본 키를 할당해야 한다.

 

💬 엔티티 설정

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.TABLE)
    val id: Long = 0L
)

- 가장 간단하게 설정하기 위해서 User 엔티티에 아이디에 대한 필드만 설정해두었다.

 

 

💬 h2 database

h2에서는 먼저 user 테이블과 시퀀스를 관리하기 위한 hibernate_sequences 테이블을 만든다.

이때 내부적으로 시퀀스 값 자체를 관리하기 위한 next_val과 시퀀스 이름 필드인 sequence_name을 만들며, 생성하는 테이블 각각에 대해 시퀀스를 관리하게 된다.

이후, 가장 처음 시퀀스 값을 초기화하기 위해서 insert를 진행하며, 0으로 초기화를 해두었다.

💬 mysql

mysql 역시 마찬가지로 user와 시퀀스를 관리하기 위한 테이블을 추가한다.

innoDB 스토리지 엔진을 사용한다는 점 빼고는 동일하다.

 

 

💬 postgresql

postgresql에서도 완전히 동일하게 동작하기 때문에 생략하겠다.

 

 

💬 insert 시 동작 과정

기본적으로 select를 통해서 현재 테이블에 저장되어 있는 시퀀스 값을 가져온다. 

이때, select for update 구문을 활용하여 락을 걸고 있기 때문에 외부에서 해당 테이블에 값을 삽입할 수가 없어 데이터의 일관성은 만족된다. 이후, 가져온 값을 바탕으로 시퀀스 값을 update 해주고, 최종적으로 user 엔티티에 대해 insert를 진행한다.

 

위의 상황에서는 디폴트로 0이 저장되어 있고, update 시 1을 추가하여 0 + 1 = 1의 값을 가지고, insert 시 업데이트된 값을 통해서 id를 할당한 상황이라고 볼 수 있다.

 

💬 @TableGenerator

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.TABLE, generator = "user_seq_generator")
    @TableGenerator(name = "user_seq_generator", table="user_sequence",
        pkColumnName = "name", pkColumnValue = "user_col", allocationSize = 50)
    val id: Long = 0L
)

테이블 전략의 경우 @TableGenerator 어노테이션과 함께 사용하면 시퀀스 테이블에 대한 정보를 커스텀할 수 있다.

- name: 생성하는 제너레이터의 이름 (@GeneratedValue의 인자로 제너레이터를 참조할 때 참조하는 이름이다.)
- table: 생성하는 제너레이터 테이블의 이름
- pkColumnName: 제너레이터 테이블에서 지정할 시퀀스 이름 필드명
- pkColumnValue: 시퀀스 이름 필드에 대해서 해당 테이블을 어떤 이름으로 관리할지 지정
- allocationSize: 사전에 정의한 시퀀스 사이즈. DB에서는 할당한 사이즈만큼 먼저 수를 증가시켜두고, 트랜잭션이 끝날 때마다 사이즈만큼 추가한다. (기본값이 50이기 때문에 필요하다면 1로 설정!)

 

위의 정보 외에도 다양한 설정값들을 세팅할 수 있다.

 

  

    
    
    
    
  
@Test
@Transactional
fun test() {
    userRepository.save(User())
}

실제로, allocationSize에 대해 테스트를 하기 위해 위와 같이 사용자 정보를 저장해보자.

우선, 앞서 봤던 것처럼 시퀀스 정보를 select 후 해당 값을 update 한 것을 볼 수 있다.

그리고 sequence 정보를 확인해보면, user 하나만 저장했음에도 할당한 크기(50)만큼 값이 추가된 것을 볼 수 있다.

 

만약, 다시 한 번 테스트 코드를 실행하게 된다면 다음 sequence는 어떻게 될까? (ddl는 update로 설정)

이때는 db에 next_val이 100으로 저장이 되어 있다. (기존 next_val 값 50 + allocationSize 50 = 100)

  

    
    
    
    
  
@Test
@Transactional
fun test() {
    // 한 번 더 실행했을 때의 결과
    val user = userRepository.save(User())
    assertThat(user.id).isEqualTo(2)
}

하지만, user의 pk 값은 2로 나오는 것을 확인할 수 있다. 이는 내부적으로 받아온 next_val의 값과 allocationSize 값을 바탕으로 pk를 계산한 값이다. 레코드 1개를 삽입할 때, 처음 select 시 얻어온 (next_val - allocation_size) + 1으로 할당된다.

 

---

🌱 SEQUENCE

💡 Indicates that the persistence provider must assign primary keys for the entity using a database sequence.

데이터베이스에서 제공하는 시퀀스를 사용하여 엔티티의 기본 키를 할당해야 한다.

이때, 시퀀스를 지원하지 않는 DB라면 테이블 전략을 사용한다.

 

 

💬 엔티티 설정

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE)
    val id: Long = 0L
)

💬 h2 database

h2의 경우 sequence를 지원하기 때문에 ‘create sequence’라는 것을 통해서 sequence 관리한다.
이때, 디폴트로 시퀀스 값은 1부터 시작하여 50씩 증가한다. 즉, 하나의 트랜잭션이 끝나면 50개 이하를 삽입하더라도 50씩 시퀀스 값이 증가하기 때문에 중간중간 비어있는 PK 값을 가질 수 있다는 것이 특징이다.

 

💬 mysql

⭐️ 그러나, mysql에서는 sequence를 지원하지 않기 때문에 테이블 전략처럼 user_seq라는 테이블이 생성된다.
이때, 시퀀스 테이블에 대한 네이밍은 엔티티명 + _seq와 같은 형태로 동작한다.

 

 

💬 postgresql

h2와 마찬가지로 postgresql 역시 sequence를 지원하기 때문에 create sequence를 통해서 시퀀스를 생성한다.

 

💬 insert 시 동작 과정

먼저, 시퀀스로부터 다음 값을 받아오는 select 쿼리가 발생한다. ("next value for" = 1이라는 값을 받아온다.)

이전의 TABLE 전략과 다르게 '그 다음 insert 시 사용할 시퀀스 값'을 저장하기 때문에 시퀀스에 대한 별도의 update를 쿼리로 관리하는 것이 아닌 내부적으로 관리된다고 추측된다. (물론 MySQL이라면 테이블 전략이기 때문에 update 쿼리 발생)

또한, 추후 나올 IDENTITY 전략과 다르게 persist 시 insert를 하지 않아도 돼서 트랜잭션 커밋 시 insert가 이루어진다. (쓰기 지연 가능) 

 

 

💬 @SequenceGenerator

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_seq_generator")
    @SequenceGenerator(name = "user_seq_generator", sequenceName = "user_sequence",
        initialValue = 10, allocationSize = 50)
    val id: Long = 0L
)

 

@SequenceGenerator를 활용하면 시퀀스에 대한 정보를 설정해줄 수 있다.
- name: 생성하는 제너레이터의 이름 (@GeneratedValue의 인자로 제너레이터를 참조할 때 참조하는 이름이다.)
- sequenceName: 생성하는 시퀀스의 이름
- initialValue: 시퀀스의 초기값
- allocationSize: 사전에 정의한 시퀀스 사이즈. DB에서는 할당한 사이즈만큼 먼저 수를 증가시켜두고, 트랜잭션이 끝날 때마다 사이즈만큼 추가한다.
마찬가지로 위의 정보 외에도 다양한 설정값들을 세팅할 수 있다.

 

키 할당 전략은 table 때와 똑같이 (next_val - allocation_size) + 1와 같이 설정된다.

 

---

🌱 IDENTITY

💡 Indicates that the persistence provider must assign primary keys for the entity using a database identity column.

- 데이터베이스의 auto-increment 열을 사용하여 엔티티에 기본 키를 할당해야 한다.
레코드가 새롭게 추가될 때마다 자동으로 고유값을 생성하고 증가시킨다.

 

💬 엔티티 설정

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

💬 h2 database

별도의 시퀀스 테이블을 생성하지 않고, pk로 사용된 컬럼에 as identity라는 이름이 들어간다.

 

💬 mysql

h2와 거의 비슷하지만 auto_increment가 pk 컬럼에 붙게 된다.

cf. 참고로 innoDB에서는 auto_increment를 위한 자동 증가 락이라는 것을 통해서 해당 값을 관리한다.

 

💬 postgresql

postgresql의 경우 bigserial이라는 값을 통해서 관리한다.
이는 postgresql에서 사용하는 자동 증가 타입으로, 컬럼이 삽입될 때마다 1씩 증가된 값이 저장된다.

 

 

💬 insert 시 동작 과정

앞서 본 테이블, 시퀀스 전략과 다르게 select 쿼리가 없이 바로 insert 쿼리가 발생한다.

이때, ()와 같이 빈 값이 들어가는 것을 볼 수 있는데, 이는 삽입하는 시점에는 id 값을 알 수 없기 때문에 빈값 (java라면 null)이 들어가는 것이다. 즉, 삽입 시점의 id 값을 애초에 모르니까 삽입 전에 select 쿼리를 날릴 수 없는 것이다.

IDENTITY 전략 사용 시 트랜잭션 커밋 시점이 아닌, persist 시점에 쿼리가 발생하여, 쓰기 지연이 불가능하다.

기본적으로 JPA의 영속성 컨텍스트에서 객체를 관리하기 위해서는 @Id 속성이 꼭 필요한데 auto_increment의 경우 DB에 직접 레코드를 insert를 한 뒤에 ID 값을 알 수 있기 때문에 persist() 시점에 insert를 진행하여 식별자를 미리 알아둔다. 이후, 알아본 값을 영속성 컨텍스트의 1차 캐시 내부에 저장한다.

💬 IDENTITY with generator

두 속성을 같이 쓰면 어떻게 동작할지 궁금해서 실험해보았다.

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY, generator = "user_seq_generator")
    @SequenceGenerator(name = "user_seq_generator", sequenceName = "user_sequence",
        initialValue = 10, allocationSize = 50)
    val id: Long = 0L
)

확인 결과, 시퀀스 옵션이 더 우선으로 적용되는 것을 볼 수 있다.

참고로, 테이블 제너레이터를 사용하더라도 마찬가지로 우선 적용된다.

 

---

🌱 AUTO

💡 Indicates that the persistence provider should pick an appropriate strategy for the particular database.
The AUTO generation strategy may expect a database resource to exist, or it may attempt to create one.
A vendor may provide documentation on how to create such resources in the event that it does not support schema generation or cannot create the schema resource at runtime.

특정 데이터베이스에 따른 적절한 전략을 선택하며, 벤더 사에 따라서 자동으로 결정된다.

 

💬 엔티티 설정

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    val id: Long = 0L
)

💬 h2 database

h2의 경우 시퀀스를 지원하기 때문에 시퀀스 전략을 자동으로 채택한다.

 

 

💬 mysql

시퀀스 전략을 지원하지 않는 mysql의 경우 테이블 전략을 사용한다.

 

💬 postgresql

h2와 마찬가지로 시퀀스 전략을 사용한다.

 

💬 SEQUENCE vs AUTO

여기까지만 봤다면 시퀀스 전략이나 auto나 별다른 게 없다고 생각이 들 것이다.
하지만, pk가 uuid인 ‘엔티티를 저장할 때’ 시퀀스 전략의 경우 오류가 발생하고, auto의 경우 정상적으로 동작한다.

이때, 단순히 테이블 생성 자체는 정상적으로 동작한다.

 

 

sequence

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE)
    val id: UUID = UUID.randomUUID()
)

h2로 테스트를 진행했기 때문에 시퀀스 테이블을 생성하는 것을 볼 수 있다.

이때, user 테이블의 id가 uuid로 설정된 것을 볼 수 있다.

 

  

    
    
    
    
  
userRepository.save(User())

기본적으로 User 객체의 id에 기본값을 정의하였기 때문에 select 쿼리를 통해서 이미 객체가 존재하는지 확인한 다음, 존재하지 않으면 user_seq의 시퀀스 값으로부터 다음 값을 가져온다.

 

Unknown integral data type for ids: java.util.UUID

하지만, 이후 UUID 타입으로는 save가 되지 않는다는 오류가 발생한다.
이는, 초기 sequence 정의를 보면 1부터 시작하여 50씩 증가하는 디폴트 설정을 가지고 있지만, pk 값이 uuid로 되어 있다 보니 uuid에 대해 증가 연산을 할 수 없어 데이터 타입에 대한 오류가 발생한다.

 

auto

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    val id: UUID = UUID.randomUUID()
)

시퀀스를 지원하는 h2임에도, 시퀀스를 생성하지 않고 단순히 pk가 UUID인 user 테이블을 생성하는 것을 볼 수 있다.

 

  

    
    
    
    
  
userRepository.save(User())

우선 아이디 값에 대해서 UUID.randomUUID()를 활용하여 기본값을 설정하게 되면, 이미 존재하는 레코드인지 확인하기 위해 저장 전에 select 쿼리가 발생하고 이후 insert 쿼리가 날라간다. 이때, 레코드 삽입 시 해당 PK 값을 증가시키면서 관리할 필요가 없기 때문에 오류가 발생하지 않고 잘 지정되는 것을 볼 수 있다.

 

identity (번외)

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

참고로, identity로 설정했을 때는 save가 아닌 테이블을 생성하는 시점부터 오류가 발생한다.

uuid 자체를 자동 증가값으로 관리할 수 없기 때문에 발생하는 오류이다.

 

⭐️ 결과적으로 식별자 타입이 UUID면 UUID를 식별자로 사용하고, 숫자면서 시퀀스를 지원하면 시퀀스로, 아니면 테이블로 사용한다고 생각하면 된다.

 

---

🌱 UUID

💡 Indicates that the persistence provider must assign primary keys for the entity by generating an RFC 4122 Univerally Unique IDentifier.

- RFC 4122 Universally Unique Identifier를 통해서 엔티티의 기본 키를 할당할 수 있다.
PK 필드 자체를 UUID로 설정하고, AUTO 전략을 사용하는 것과 동일하게 동작한다.

 

💬 엔티티 설정

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.UUID)
    val id: Long = 0L
)

 

 

💬 h2 database

id 값의 타입으로 uuid가 설정되는 것을 볼 수 있다. 이때 별도의 시퀀스가 있다든지, 자동 증가 컬럼으로서 동작하지는 않는다.

 

 

💬 mysql

mysql의 경우 binary라는 타입을 활용하여 필드가 생성이 된다.

마찬가지로 자동 증가로 관리되지 않고, 별도의 시퀀스 테이블이 생성되지 않는다.

 

💬 postgresql

h2와 동일하게 uuid라는 필드값으로 생성된다.

 

---

🌱 @IdGeneratorType

@TableGenerator, @SequenceGenerator 외에도 범용적으로 사용할 수 있는 @GenericGenerator라는 어노테이션이 존재한다.
하지만, 공식 문서에서 @IdGeneratorType을 대신 사용하는 것을 권고하였기 때문에 사실상 deprecated 되었다고 생각한다.
@IdGeneratorType을 사용하면 어노테이션이 아닌 인터페이스를 활용하여 조금 더 세세하게 커스텀을 진행할 수 있다.

 

  

    
    
    
    
  
public class CustomSequenceGenerator implements IdentifierGenerator {

	public CustomSequenceGenerator(
			Sequence config,
			Member annotatedMember,
			CustomIdGeneratorCreationContext context) {
		//...
	}

	@Override
	public Object generate(
			SharedSessionContractImplementor session,
			Object object) {
		//...
}

@IdGeneratorType( CustomSequenceGenerator.class )
@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface Sequence {
	String name();
	int startWith() default 1;
	int incrementBy() default 50;
	Class<? extends Optimizer> optimizer() default Optimizer.class;
}

 

사실 직접 사용할 일은 없을 것 같아서 그냥 Member 위에 @Sequence라는 커스텀 어노테이션이 적용되었을 경우를 보여주는 예제 코드를 가져왔다.

 

  

    
    
    
    
  
public class TableGenerator implements PersistentIdentifierGenerator {
	...
  @Override
  public Object generate(final SharedSessionContractImplementor session, final Object obj) {
    final SqlStatementLogger statementLogger = session.getFactory().getServiceRegistry()
            .getService( JdbcServices.class )
            .getSqlStatementLogger();
    final SessionEventListenerManager statsCollector = session.getEventListenerManager();

    return optimizer.generate(
            new AccessCallback() {
              @Override
              public IntegralDataTypeHolder getNextValue() {
                return session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
                        new AbstractReturningWork<>() {
                          @Override
                          public IntegralDataTypeHolder execute(Connection connection) throws SQLException {
                            return nextValue( connection, statementLogger, statsCollector );
                          }
                        },
                        true
                );
              }

              @Override
              public String getTenantIdentifier() {
                return session.getTenantIdentifier();
              }
            }
    );
  }
}

 

실제로 @TableGenerator 역시 IdentifierGenerator 인터페이스를 활용하여 구현되어 있는 것을 확인할 수 있다.

 

---

🌱 아예 아무것도 붙이지 않는다면?

  

    
    
    
    
  
@Entity
class User(
    @Id
    val id: Long = 0L
)

@GenerateType을 아예 붙이지 않아도 되는지 궁금해서 실험해보았다.

 

💬 h2 database

기본적으로 user table만 생성하고, id에도 auto_increment 같이 관리하는 조건이 들어가지 않는다.

이 상태로 삽입을 하게 되면 다음과 같다.

  

    
    
    
    
  
userRepository.save(User())

 

id에 대한 바인딩이 0으로 들어간 것을 볼 수 있다.

 

  

    
    
    
    
  
userRepository.save(User())
userRepository.save(User())

또한, save를 2번 호출하게 되면은 위와 같이 중복된 식별자를 사용한다는 오류가 발생한다. (PK는 unique 해야 하니까)

 

이는 PK 값에 대해 별도로 관리하는 방법을 지정하지 않았기 때문에 사용자가 직접 id를 넣어줘야 되면서 생긴 문제이다. 우선 엔티티 생성 시 아이디에 대한 기본값인 0L을 지정하면서 또 다시 '0L'이라는 동일한 키를 가진 엔티티가 삽입되면서 오류가 발생한 것이다.그래서 복합키 같은 특수 상황을 제외하면 웬만하면 생성 전략을 통해서 관리하는 게 좋다는 생각이 들었다.

 

💬 mysql

작동 과정은 앞과 똑같기 때문에 별도로 설명하지 않고, 테이블 형식만 보겠다.

마찬가지로 단순히 테이블의 필드값으로 bigint만 존재하는 것을 볼 수 있다.

 

💬 postgresql

h2와 동일하게 생성된 것을 볼 수 있다.

 

---

🌱 기본값을 할당해주지 않았다면?

여기서도 기본값을 어떻게 할당하는지에 따라서 결과가 달라진다. (generatedType을 지정하지 않았을 때의 결과)

  

    
    
    
    
  
@Entity
class User(
    @Id
    val id: Long = 0L
)

흔히 사용하는 Long 타입 id에 0L 같은 기본값으로 초기화하게 된다면, 엔티티 저장 시 단순히 하나의 insert 쿼리만 발생하게 된다. (Int 타입도 마찬가지)

하지만, 1L 같이 특정한 값으로 설정하게 되면 select 쿼리가 발생하고 그 다음 insert 쿼리가 발생한다.

이는 삽입 전에 이미 해당 레코드가 존재하는지 확인하고 (관리 전략을 설정해주지 않았으니까) insert를 날려서 존재하지 않는 것에 대해서만 insert를 하기 때문이다.

 

  

    
    
    
    
  
@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

같은 원리로 IDENTITY를 설정하게 되면 애초에 insert 시 아이디가 없으니까 애초에 검증할 값이 없으니 단순히 insert만 발생한다. (persist 시에 insert 쿼리 발생)

 

  

    
    
    
    
  
@Entity
class User(
    @Id 
    val id: String = ""
)

String의 경우 무조건 select가 발생한다. (애초에 String? 타입으로 설정 후 기본 값을 null로 지정하면 오류가 발생한다.)

이는, save() 시의 메서드를 보면 파악할 수 있다.

save() 시 메서드를 보면 엔티티가 새로우면 persist, 아니면 merge를 하게 되는 걸 볼 수 있다.

여기서 isNew() 메서드를 타고 들어가면 다음과 같다.

primitive 타입이 아니라면 null로 체크, Number 형이라면 0L으로 체크해서 이게 새로운 값인지 테스트하게 된다.