배치 삽입을 위한 엔티티 ID 전략 논의: IDENTITY(JdbcTemplate) vs. SEQUENCE

[yeonnhuu]

1. 논의 제안 배경

현재 프로젝트에서 엔티티 ID 생성 전략으로 GenerationType.IDENTITY를 사용하고 있습니다. IDENTITY 전략은 구현이 간단하지만 JPA의 배치 삽입 기능을 비활성화시킵니다. IDENTITY 전략 하에서 JpaRepository의 saveAll(List<Entity> entities)을 호출하면, 영속성 컨텍스트가 엔티티를 관리하기 위해 persist() 시점에 즉시 INSERT 쿼리를 실행하여 DB로부터 ID를 받아와야 합니다. 결과적으로 100개의 엔티티를 saveAll하면 1개의 Batch INSERT 가 아닌 INSERT 쿼리 100개가 실행됩니다.

현재 이 문제를 해결하기 위해 available_date_slot, available_time_slot과 같이 배치 삽입이 필요한 로직에서 JdbcTemplate의 batchUpdate를 사용하는 별도의 Repository(JdbcSlotBatchRepository)를 구현해 사용하고 있습니다.

이는 JPA와 JdbcTemplate 코드가 공존하여 코드 복잡성 증가한다는 문제가 있습니다.

이에 JdbcTemplate 의존성을 제거하고 JPA saveAll의 배치 삽입 기능을 활성화하기 위해 일부 엔티티의 ID 생성 전략을 GenerationType.SEQUENCE로 변경하는 것을 제안합니다.

2. IDENTITY vs. SEQUENCE 전략 비교

IDENTITY

• ID 생성 방식: 데이터베이스의 auto_increment 기능에 전적으로 의존합니다. (ex. MySQL의 AUTO_INCREMENT)
• INSERT 쿼리 시점: persist() (저장) 호출 즉시 DB로 INSERT 쿼리가 실행됩니다.
  • JPA가 영속성 컨텍스트에서 엔티티를 관리하려면 PK(ID)가 필요한데, IDENTITY 전략은 INSERT를 해야만 ID를 알 수 있기 때문입니다.
• 배치 삽입 (Batch Insert): 불가능합니다.
  • saveAll(100개) 호출 시, 쿼리를 모으지 못하고 INSERT 쿼리가 100번 실행됩니다.
• 장점
  • 설정이 @GeneratedValue(strategy = GenerationType.IDENTITY) 하나로 간단합니다.
  • ID에 공백(Gap)이 절대 생기지 않습니다.
• 단점
  • 배치 삽입이 불가능하여 대량 데이터 적재 시 성능 저하가 발생합니다.
• 주요 사용 DB: MySQL, MariaDB, H2

SEQUENCE

• ID 생성 방식: 데이터베이스의 독립된 SEQUENCE 객체를 사용합니다.
• INSERT 쿼리 시점: persist() 시점에는 INSERT가 실행되지 않습니다.
  • 대신 allocationSize만큼의 ID를 DB 시퀀스로부터 미리 받아와 메모리 ID 풀에 보관합니다.
  • 엔티티에는 이 메모리 풀에서 ID를 할당해 줍니다.
  • 실제 INSERT 쿼리는 트랜잭션 커밋 시점에 "쓰기 지연"되었다가 한 번의 배치로 실행됩니다.
• 배치 삽입 (Batch Insert): 가능합니다.
  • saveAll(100개) 호출 시, batch_size 설정에 맞춰 Batch INSERT 1번 (혹은 몇 번)으로 실행됩니다.
  • saveAll() 동작: (시퀀스 조회 1~2번) + Batch INSERT 1번
• 장점
  • 대량 데이터 삽입 시 성능이 좋습니다.
  • allocationSize와 batch_size 튜닝을 통해 성능을 극대화할 수 있습니다.
• 단점
  • allocationSize로 인해 ID 공백(Gap)이 발생할 수 있습니다. (서버 재시작 시 메모리에 있던 ID 풀이 유실됨)
  • @SequenceGenerator 설정, allocationSize 설정, batch_size 설정 등 상대적으로 설정이 복잡합니다.
• 주요 사용 DB: Oracle, PostgreSQL

3. 적용 대상 엔티티 논의

SEQUENCE 전략은 한 번의 요청으로 여러 건의 데이터 삽입이 발생하는 엔티티에 주로 적용합니다.
현재 프로젝트에서 이에 해당하는 엔티티는 다음과 같습니다.
• available_date_slot (일정 생성 시 여러 날짜 슬롯 생성)
• available_time_slot (일정 생성 시 여러 시간 슬롯 생성)
• vote (사용자가 여러 슬롯에 한 번에 투표)
이 엔티티들에 대해서만 SEQUENCE 전략을 도입하는 것을 제안합니다.

4. 결론

JdbcTemplate을 사용하는 현재의 배치 방식 대신 SEQUENCE 전략을 도입해 JPA의 saveAll을 통한 깔끔하고 효율적인 배치 삽입 처리가 장기적으로 옳다고 생각합니다.

아래 사항에 대한 의견 부탁드립니다!

1. SEQUENCE 전략 도입에 따른 ID 공백(Gap) 발생에 동의하는지
   • 개인적으로는 PK는 고유하기만 하면 되므로 문제없다고 생각합니다.
2. 적용 대상 엔티티(available_date_slot, available_time_slot, vote)가 적절한지
3. allocationSize와 batch_size는 몇으로 설정하는 것이 적절한지
   • 개인적으로 available_date_slot과 available_time_slot의 최대 조합을 고려해 available_date_slot, available_time_slot, vote의 allocationSize와 batch_size를 모두 50으로 통일하면 좋을 것 같습니다.

[m-a-king]

깔끔히 정리해주셔서 단번에 맥락을 이해했습니다~

---

JPA로 문제를 해결해야한다는 요구사항이 있다면, 분명 시퀀스 방식으로 변경하는 것이 맞다고 생각합니다.
맞는 것을 넘어서, 반드시 그렇게 해야할 것 같습니다.

그렇지만 JPA로 문제를 해결해야하는 것이 요구 사항이 아님이 떠오르네요...

1. 데이터의 정합성을 지킬 수 있다면? 배치 인서트를 해내기만 하면 되는 상황이고,
2. 리버의 정리덕분에, JPA로 문제를 어떻게 해결하는지 모두가 확신을 갖고 설계할 수 있는 상황이고,
3. 아이디 전략을 시퀀스로 변경하면, BaseEntity를 상속받는 현재 상황에 전체적으로 변경이 생기는 것
4. MySQL에서 시퀀스 전략을 사용한다면 Hibernate가 내부적으로 테이블을 만들어 처리하는데,

• 배치 삽입이 필요한 엔티티들만 특별한 내부 전략을 갖게 되는 것이
  • 코어 모듈에 도메인은 원래 순수한 것이 원칙이지만, JPA 엔티티에 간단한 애노테이션(메타데이터)까지만 허락하려 했음
    • 아이디 생성 전략이 더해지며 복잡성이 더해지는 것이 우려되는...

뿐만 아니라 실무에서 JdbcTemplate를 성능 최적화나 JPA에서 지원하지 않는 무언가를 해결하기 위해서 종종 사용된다는 조언을 들어봤을 때, 이번 문제를 해결하는 방법으로 시퀀스도 있지만, JdbcTemplate를 활용해서 JPA 컨텍스트 없이 배치 인서트를 해결하면 어떨까 싶습니다. 물론, 이때문에 JPA 캐시측에서 바라보는 값과 데이터베이스 값이 다르면 안되므로, 애플리케이션에서 실수를 하지 않도록 주의해야겠지만요.

[yeonnhuu]

그렇지만 JPA로 문제를 해결해야하는 것이 요구 사항이 아님이 떠오르네요...

물론 JPA로 문제를 해결하려는 요구사항은 없었으나, 대량의 데이터를 효율적으로 처리하는 측면에서 SEQUENCE 전략을 생각하게 되었습니다.

3. 아이디 전략을 시퀀스로 변경하면, BaseEntity를 상속받는 현재 상황에 전체적으로 변경이 생기는 것

이 부분을 고려해서 available_date_slot, available_time_slot, vote만 SEQUENCE ID 전략을 사용하도록 BaseIdentityEntity, BaseSequenceEntity 이런 식으로 구분해서 관리하는 건 어떨까요?

4. MySQL에서 시퀀스 전략을 사용한다면 Hibernate가 내부적으로 테이블을 만들어 처리하는데,

MySQL 8.0부터는 SEQUENCE 객체를 네이티브 처럼 지원하는 것으로 알고 있는데, 제가 잘못 알고 있다면 추가적인 설명 부탁드립니다!

코어 모듈에 도메인은 원래 순수한 것이 원칙이지만, JPA 엔티티에 간단한 애노테이션(메타데이터)까지만 허락하려 했음

ID 전략을 다르게 한 BaseEntity를 상속받거나 @SequenceGenerator를 오버라이딩하는 방식은 인프라 관련 내용이 도메인에 들어가게되는 건 맞다고 생각합니다. 개인적으로 이미 @Entity, @Id 등을 사용한 순간부터 JPA 의존성을 갖고 있기 때문에 이 정도까지는 타협이 가능하다고 생각하는데, 이 부분은 코어 모듈의 도메인을 얼마나 순수하게 가져가야할지에 대한 다른 분들의 의견도 궁금합니다.

뿐만 아니라 실무에서 JdbcTemplate를 성능 최적화나 JPA에서 지원하지 않는 무언가를 해결하기 위해서 종종 사용된다는 조언을 들어봤을 때

저희 상황 같은 경우 JPA가 충분히 지원할 수 있어 오히려 JdbcTemplate을 사용할 필요가 없어 보이는데, 실무에서 JdbcTemplate을 사용해야만 하는 사례에 대해 더 설명해주실 수 있을까요?

물론, 이때문에 JPA 캐시측에서 바라보는 값과 데이터베이스 값이 다르면 안되므로, 애플리케이션에서 실수를 하지 않도록 주의해야겠지만요.

"애플리케이션에서 실수를 하지 않도록 주의"하면서까지 JdbcTemplate을 사용해야만 하는 이유가 궁금합니다! 실수 하는 경우 캐시 불일치 문제를 파악하기 어렵다고 알고 있습니다. 1차 캐시를 사용할 수 있고 수동으로 관리할 필요가 없는 SEQUENCE 전략의 장점을 포기했을 때 득보다는 실이 더 클 것 같은데, JdbcTemplate을 선택했을 때의 이점이 궁금합니다.

[m-a-king]

물론 JPA로 문제를 해결하려는 요구사항은 없었으나, 대량의 데이터를 효율적으로 처리하는 측면에서 SEQUENCE 전략을 생각하게 되었습니다.

JPA에서 생기는 오버헤드가 존재하지 않는 JdbcTemplate이 훨씬 빠르고 좋습니다. 하지만 효율적으로 처리라는 것이 객체 지향적인 코드로 이해가 빠르게 되고, 다소 복잡한 비즈니스 로직을 고려한 유지 보수성까지 포함한다면 말씀해주신 SEQUENCE가 더 좋은 선택이라는 것에 동의합니다. 그렇지만 BaseEntity가 2개 이상이 되고, 각 엔티티들의 배치처리가 BaseEntity를 무엇을 상속받았는가로 판단된다면 그또한 유지 보수성을 해칠 수도 있다고 생각합니다.
결론적으로 SEQUENCE 전략이 은탄환이 아니라는 점을 말하고 싶었습니다.

---

이 부분을 고려해서 available_date_slot, available_time_slot, vote만 SEQUENCE ID 전략을 사용하도록 BaseIdentityEntity, BaseSequenceEntity 이런 식으로 구분해서 관리하는 건 어떨까요?

좋습니다. 아마도 선택을 한다면 우선 그렇게 적용하는 방법이 가장 쉽고 빠를 것 같습니다!

---

MySQL 8.0부터는 SEQUENCE 객체를 네이티브 처럼 지원하는 것으로 알고 있는데, 제가 잘못 알고 있다면 추가적인 설명 부탁드립니다!

https://dev.mysql.com/doc/refman/8.4/en/faqs-general.html#faq-mysql-have-sequences 위 공식문서를 참고할 수 있습니다~ Hibernate가 MySQL에서 SEQUENCE 전략을 사용할 수 있게 추상화해줍니다. 다만 이는 네이티브 SEQUENCE가 아닌 테이블 기반 에뮬레이션 방식이며, 이로 인한 성능 이슈(테이블 락, SELECT+UPDATE 오버헤드)를 고려해야 한다고 합니다.

---

ID 전략을 다르게 한 BaseEntity를 상속받거나 @SequenceGenerator를 오버라이딩하는 방식은 인프라 관련 내용이 도메인에 들어가게되는 건 맞다고 생각합니다. 개인적으로 이미 @entity, @id 등을 사용한 순간부터 JPA 의존성을 갖고 있기 때문에 이 정도까지는 타협이 가능하다고 생각하는데, 이 부분은 코어 모듈의 도메인을 얼마나 순수하게 가져가야할지에 대한 다른 분들의 의견도 궁금합니다.

충분히 합리적인 접근이라고 생각합니다. 하지만 MySQL이 네이티브 sequence를 지원하지 않는 이유로 벤더가 고정되는 코드는 없는지(벤더 변경시 문제가 생기는 코드는 없는지?), MySQL에서 sequence 전략을 주로 사용하지 않기에 발생하는 문제를 해결하는 방법을 쉽게 찾을 수 없는 그런 문제들이 우려됩니다.

---

저희 상황 같은 경우 JPA가 충분히 지원할 수 있어 오히려 JdbcTemplate을 사용할 필요가 없어 보이는데, 실무에서 JdbcTemplate을 사용해야만 하는 사례에 대해 더 설명해주실 수 있을까요?

저도 복잡한 문제를 다뤄본 적은 없지만 대량 업데이트/인서트에서 사용한다는 것을 자주 들었습니다. 다른 방법도 존재할 것 같습니다. 예시를 알기 위해서 간략하게 ai에게 질문을 해보니 아래와 같은 요약을 할 수 있었습니다.

---

"애플리케이션에서 실수를 하지 않도록 주의"하면서까지 JdbcTemplate을 사용해야만 하는 이유가 궁금합니다! 실수 하는 경우 캐시 불일치 문제를 파악하기 어렵다고 알고 있습니다. 1차 캐시를 사용할 수 있고 수동으로 관리할 필요가 없는 SEQUENCE 전략의 장점을 포기했을 때 득보다는 실이 더 클 것 같은데, JdbcTemplate을 선택했을 때의 이점이 궁금합니다.

캐시 불일치 문제를 고려해야하는 시점에서 JdbcTemplate를 사용하면 문제가 생기듯, 각자에게 장단점이 있을 것 같습니다. 말장난같지만 JPA의 sequence전략을 사용해서 생기는 생기는 문제점들은 JdbcTemplate으로 해결이 되고, JdbcTemplate로 생기는 문제는 sequence 전략으로 해결이 되는거죠...

---

제가 말씀드리고 싶은 것은 JPA SEQUENCE 전략 자체를 반대하는 것이 아니라, MySQL + SEQUENCE 조합 특성상 발생할 수 있는 트레이드오프를 인지하고 선택하셨으면 하는 바람입니다~ 건설적인 토론에서 많이 배우네용 😮

[yeonnhuu]

어떤 측면에서 SEQUENCE 도입을 우려하셨는지 이해가 되네요~덕분에 목표와 환경을 고려해서 신중하게 선택해야 된다는 것을 배운 것 같습니다. 이에 관한 추가 논의는 오프라인에서 진행해도 좋을 것 같아요 👍

[AppleMint98]

1. SEQUENCE 전략 도입에 따른 ID 공백(Gap) 발생에 동의하는지

• 동의합니다~ 고유성이랑 정렬가능성만 유지하면 충분하다고 생각합니다.

2. 적용 대상 엔티티(available_date_slot, available_time_slot, vote)가 적절한지

• 지금은 문제대상인 vote만 먼저 적용하고, available_date_slot, available_time_slot 는 vote에서의 경과를 지켜본 뒤 결정해도 된다는 의견입니다!
  • BaseSequenceEntity 를 새로 만들어서 pk를 구분하는것도 괜찮은 것 같아요. BaseEntity를 수정해 모든 엔티티의 키 전부를 sequence로 바꾸는건 무서워요

3. allocationSize와 batch_size는 몇으로 설정하는 것이 적절한지

• 이것도 동일하게 50/50 기본값 설정 후 경과를 지켜보고 수정하자는 의견입니다.

[jhan0121]

정리하느라 고생하셨습니다 리버! 이번 기회에 identity와 sequence의 차이를 명확하게 알 수 있게 되어 좋네요~

SEQUENCE 전략 도입에 따른 ID 공백(Gap) 발생에 동의하는지

리버의 의견대로 PK는 고유하기만 하면 되기 때문에 sequence를 적용했을 때의 단점이 크지 않아 공백 발생 문제는 크리티컬하지 않다고 생각합니다!

적용 대상 엔티티(available_date_slot, available_time_slot, vote)가 적절한지
allocationSize와 batch_size는 몇으로 설정하는 것이 적절한지
개인적으로 available_date_slot과 available_time_slot의 최대 조합을 고려해 available_date_slot, available_time_slot, vote의 allocationSize와 batch_size를 모두 50으로 통일하면 좋을 것 같습니다.

저는 3개 모두 sequence를 적용하거나 JdbcTemplate를 적용하거나 하나로 통일하는 것이 좋을 것 같습니다! 개인적으로는 sequence 방식으로 적용하면 SequenceBaseEnrtity와 같이 공통되는 엔티티를 구성한다면 빠르게 적용할 수 있다는 장점이 크다고 생각이 드네요. 자동 쿼리 생성과 연관관계 매핑과 같은 Jpa의 강력한 유틸 기능을 사용할 수 있다는 점도 큰 것 같아 3개 모두 sequence를 적용하는 것에 찬성합니다!

batch size 설정 근거는 충분히 타당하다고 생각합니다! slot의 경우에는 time이 24 * 2, date가 7이라 50이 적절했는데, vote의 경우에는 최대 개수가 24 * 2 * 7 = 336 이라서 batch 사이즈를 조정하거나 별도로 관리해야 할 수 있을 것 같다고 생각합니다.

[yeonnhuu]

vote 같은 경우 336개를 다 선택할 확률이 극히 적어 allocation_size, batch_size을 50/50으로 설정한 경우 (예: 월화수목금(5일) 각각 10개 선택했을 때 한 번에 처리) 충분하다고 생각하는데 이에 대해 어떻게 생각하시나요?

[jhan0121]

확실히 모두 선택하는 경우는 매우 극단적인 경우일 것 같네요!!👍 이에 대한 근거도 잘 작성해주셔서 처음에 제안했던 50/50이면 충분할 것 같습니다!!