ItemReader에서 chunkSize의 두 사용 방법 비교

지나가는 학생입니다.상황 1의 경우 스프링 배치에서 제공하는 ItemReader에는 없을 것 같군요.굳이 구현한다면 ItemReader 인터페이스를 직접 구현해서 사용할텐데, 해당 구현 내용에는 select * from table limit 1 offset 0...2000 이렇게 증가하면서 조회한다고 가정하겠습니다. 상황 1과 상황 2의 성능을 비교한다면,차라리 상황 1이 더 더 빠르다고 생각되네요.어차피 상황 1과 2 둘다 커넥션 풀에 있는 커넥션을 사용할거라 커넥션 생성 비용은 동일할텐고요.다만, 상황 2에서는 chunk size 단위로 커밋이 이뤄지기 때문에 커밋(네트워크 통신) 2000번이 발생하겠네요.상황 1에서는 write 커밋은 1번할테니 둘의 커밋 차이는 2000배가 되겠네요. 도움이 되셨기를~

KStream, KTable 조인 스트림즈 애플리케이션에서 에러가 발생하고 있습니다.

자답입니다.m1 칩을 사용할 때 kafka-streams 라이브러리의 rocksDB 버전이 6.29.4.1 이상이여야 정상 동작합니다.https://github.com/facebook/rocksdb/issues/7720(사진)kafka-streams 2.5.0 + rocksDB 6.29.4.1을 사용할 경우 2개의 버전이 호환이 되지 않아 에러가 발생합니다.정상적으로 사용하기 위해서 implementation 'org.apache.kafka:kafka-streams:3.2.0' 이상의 버전을 사용하시면 됩니다.

POST를 사용한 회원 삭제

http method는 단순히 스펙일 뿐이지 사실 delete에서 데이터를 생성하는 로직을 만들수 있습니다.당연히 post에서도 데이터를 삭제할 수 있고요.기본적으로는 uri와 httpmethod만 보고 이 api는 사용자를 생성 하구나~ 이렇게 식별할 수 있게 만드는 것이 좋은 api 설계입니다.질문자님이 얘기하신 delete를 사용한다고 알아서 삭제해주는 것이 아니라 delete를 호출했을 때 실행되는 메서드에서 삭제하는 로직을 직접 작성하셔야 합니다.post를 호출했을 때 동작하는 것은 post uri에 해당되는 메서드를 호출하는게 전부입니다. post를 호출했다고 알아서 해주는건 없습니다~

test DB 설정 질문

지나가다 들린 학생입니다. 스프링은 기본 원칙은 더 "자세한 설정을 사용한다" 입니다. properties에 설정된 설정보단 직접 @Bean을 사용한 설정이 더 우선 순위를 갖게 되어 사용되는게 맞습니다.

레거시 코드에서 DriverManager를 사용하는데요...

강의를 듣는 학생입니다. 커넥션을 1개로 계속 사용하면 커넥션 풀에 1개인 것과 비슷하다고 볼 수 있네요. 다만 커넥션을 일정 시간 사용하지 않으면 커넥션 타임 아웃이 발생하겠네요. 개인적으로 커넥션을 1개로 돌리면 배치에서 작업하는 특성에 따라 다를 수 있을 것 같네요. 예를 들어 중복 체크하는 로직이 들어가 있어야 하는데 커넥션을 1개로 돌린다면 빠져도 될 수 있겠어요. 커넥션을 맺는 작업은 맺는 당시에만 비용이 발생하니 비용이 비싸서 1개를 사용하는 것 같진 않네요. 다른 숨은 의도가 있을 수도 있을 것 같네요. 보통 배치가 오래걸리면 그 시간 만큼 서비스에서 배치 결과를 늦게 보여주는 거니 저라면 커넥션을 늘리고 멀티 쓰레드를 사용하여 배치를 돌려 작업 시간을 줄일 것 같네요. 동시 처리 작업이 5개라고 하니 최소 5개는 사용할 것 같고요. 제 답변이 도움될진 모르갰지만 지나가다 적어봅니다. 선생님 답변도 기다려보겠습니다~

RDS 보안 그룹 설정을 위한 인바운드 규칙 편집에서 아래와 같은 에러가 납니다

저도 동일한 증상이 나타납니다. (사진) (사진)