묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 배치
step-in-muti-thread 질문
안녕하세요 강의에서 학습하고 디버깅한 바탕으로 제 생각이 맞는지 궁금하여 질문 드립니다. 1. 4개의 스레드 풀이 존재하고 chunkSize=100, pageSize=300을 주었다고 쳤을 때 맨 처음 스레드가 데이터 베이스에서 300개를 조회2. AbstractPagingItemReader의 CopyOnWriteArrayList에 저장하고 이후 다른 스레드들은 해당 Reader를 공유하여 락 메커니즘이 적용된 doRead() 호출하여 list(count++)에서 데이터를 하나씩 가져와 개별 스택 안의 Chunk에 설정한 chunkSize 만큼 저장3. 그 후 process -> write 이렇게 작동하여 단일 스레드가 100개씩 3번 처리를 멀티 스레드를 이용해 마치 한 번 만에 300개 처리가 가능하여 속도를 향상시키는 게 맞을까요?
-
미해결스프링 배치
chunk 처리 기반에서 cursor 방식과 메모리 사용
안녕하세요. 비전공자로 배치 프로그램에 관심이 많아서 해당 강의를 듣다가 커서 방식과 페이징 방식을 스프링 배치에서 사용할 때 고려사항과 관련하여 질문이 있습니다. 커서가 페이징 방법에 비해 데이터 일관성이 보장이 쉽고 속도도 더 빠른 것으로 알고 있습니다. 그리고 청크 기반 배치 처리 로직으로 구현한다면, 커서 기법을 사용하는 경우에도 페이징 방법처럼 트랜잭션 단위를 청크 크기만큼 나눌 수 있을 텐데요.(페이징에서 chunk와 paging 단위를 같이 하는 것처럼 커서에서도 chunk와 fetchsize를 같게 해주면 될 것으로 고려합니다.)그리고 멀티 스레드를 고려한다면,SynchronizedItemStreamReader로 reader 영역을 감싸서 처리할 수도 있는 걸로 알고 있습니다. 그렇다면, 이러한 상황 속에서 커서와 페이징을 사용함에 고려해야할 트레이프 오프가 커넥션 타임 뿐인 걸까요??이런 상황에서도 커서가 메모리 할당 방식으로 인해서 메모리 사용량이 커진다는 단점이 있는 건가요??( 더 정확하게 말하자면 결과를 메모리에 할당한다는 점이 명확히 와닿지 않습니다.제 나름 추론하자면,커서가 fetch size나 chunk로 전체 데이터를 분할하여 메모리에 올리고 읽고나서도 모든 결과값이 메모리에 쌓여 한번에 write(ex- db에 저장) 되기 때문에 메모리 사용량이 많아 진다는 것인가여??반면에, 페이징은 기반 처리는 페이징 단위로 데이터를 읽고 읽은 데이터 크기를 처리 후 메모리에 올리고 write한 후에 다시 정해진 크기 만큼 읽는 방식인건가요??즉, 이것이 커넥션을 맺고 끊는 것 방식과 관련이 깊은 것인지 궁금합니다.)이상 cs적인 지식이 부족한 비전공자의 긴 질문을 읽어주셔서 감사합니다.
-
미해결스프링 핵심 원리 - 기본편
[혹시]스프링 배치프로그램 강의 예정은 없는지요 ?
[혹시]스프링 배치프로그램 강의 예정은 없는지요 ?