IDENTITY vs SEQUENCE 전략과 배치처리

Question

기존에 IDENTITY 전략을 사용했는데, 이 경우 id가 persist 이후에 생성되므로 대량 배치 처리에 적합하지 않다는 문제점이 있었습니다.이를 해결하기 위해 SEQUENCE 전략 + 프리 로딩(사전에 필요한 테이블을 모두 메모리로 올림)방식을 도입하였고, 별도의 시퀀스 테이블이 생성되는 것을 피하고자 하나의 _seq 테이블로 통합해서 사용하도록 구성했습니다.이 방식을 로컬 환경에서 테스트한 결과, 처리 시간이 약 8분에서 1분 30초로 크게 단축되는 효과를 확인했습니다.하지만 실제 배포 환경과 동일한 인스턴스(vCPU 2개, 메모리 1GB)에서는 처리 시간이 약 7분으로, 기존 방식과 큰 차이가 없었습니다.다만 서비스 특성상 매일 데이터가 업데이트되며, 대량 데이터 전체를 올리는 경우는 거의 없고 주로 델타(증분) 로드 방식으로 처리됩니다.이 점을 고려했을 때, 굳이 구조를 변경하지 않고 IDENTITY 전략인 기존 방식(배치 비활성화)을 유지하는 것이 나아 보이는데, 이런 판단이 적절한 선택일지 고민 중입니다.-> 기존 방식으로 했을 때-> 프리로딩(새로운 방식)적용했을 때,배포환경에서는 거의 비슷한 것 같습니다.

캐티 · Answer

uuid, short uuid 이런거 이쩌. 이렇다 하더라도 db가 분산되어 있음 터지게쩌. 사용자 계정에 따라서 독립된 시퀀스를 가지는 거를 고려해볼 수 있어요. 이럼 int 키 값으로 하여도 앵간하고 페이징은 datetime 기준으로 하여야 하겠어요.

톰소여 · Answer

로컬환경과 배포환경을 똑같이 세팅해야 하지 않을까요?차이점이 어디에 있는지(cpu, memory, network) 체크를 해 보시고 그 부분을 해결해야겠죠.물론 앱의 시스템 설계상 프리로드의 이점이 있으니 했겠지만 이 부분도 배포환경에 어울리지 않으면 다른 방식으로 처리를 해야겠죠.그럼 화이팅..

IDENTITY vs SEQUENCE 전략과 배치처리

2개의 답변

Q&A 목록