블로그이름을고민하다보니이거제목의길이가어디까지일지궁금하게되어이렇게해봤습니다

블로그이름을고민하다보니이거제목의길이가어디까지일지궁금하게되어이렇게해봤습니다

  • 분류 전체보기 (116)
    • About Me (6)
      • 자기소개 (0)
      • 회고 (6)
    • Java (7)
    • Spring (7)
    • CS (19)
      • 디자인 패턴 (2)
    • 클라우드 (3)
    • 트러블슈팅(소프트) (4)
    • Gradle (1)
    • Project 해축갤 (27)
      • [시나리오] 인기게시물의 트래픽은 얼마일까? (1)
      • 테스트 코드 (9)
      • 에러 해결 (2)
      • CI CD (6)
      • 인프라 (1)
      • 고민 (2)
      • 데이터베이스 (4)
      • 코드개선 (2)
    • International Sign Lang 프로젝트 (17)
      • 기획 (1)
      • 프론트엔드 (5)
      • 백엔드 (9)
      • 트러블슈팅 (1)
    • Project 우아한남형제들 (7)
      • 기획 (2)
      • 기술적 고민 (1)
      • 애자일 프로세스 (2)
      • 데이터베이스 (1)
      • 팀원을 위한 WIKI 문서 (1)
    • 세미나 & 컨퍼런스 (2)
    • 책 리뷰 (2)
    • 광고차단 머신러닝 (10)
  • 홈
  • 태그
  • 방명록
RSS 피드
로그인
로그아웃 글쓰기 관리

블로그이름을고민하다보니이거제목의길이가어디까지일지궁금하게되어이렇게해봤습니다

컨텐츠 검색

태그

프로그래밍 spring boot 자바 MSA Github Actions DevOps BERT JUnit JPA Spring CI 프론트엔드 기계학습 JavaScript 개발자성장 Express gradle Java CI/CD MySQL

최근글

댓글

공지사항

아카이브

배치처리(1)

  • 호텔 데이터 마이그레이션 최적화 - 인덱스 & UPSERT

    들어가며: 호텔 표준 데이터 최신화의 시작"36GB의 호텔 데이터 마이그레이션 해주세요."호텔 표준 데이터 최신화 프로젝트에서 마주한 첫 번째 과제였습니다. 호텔 데이터는 단순한 flat한 구조가 아닌, 6개의 테이블로 분산되어 저장되어야 했습니다:제가 생각한 이 마이그레이션의 핵심 요구사항은 "데이터 정합성"이었습니다. 하나의 호텔 데이터가 이 6개 테이블에 모두 성공적으로 저장되거나, 아니면 전혀 저장되지 않아야 했습니다("All or Nothing").또한 기존 데이터가 있을 수 있어 INSERT가 아닌 UPSERT를 사용해야 했죠.메모리 한계를 고려해 batch size를 100으로 설정했습니다. 36GB 전체를 한 번에 처리하는 것은 현실적으로 불가능했고, 실패 시 복구도 용이해야 했기 때문입니..

    2025.02.16
이전
1
다음
티스토리
© 2018 TISTORY. All rights reserved.

티스토리툴바