안녕하세요, 강사님 늘 강의 잘 듣고 있습니다, 감사합니다 ! 다름이 아니고, @Transactional과 @TransactionalEventListener 설정 관련해 궁금한 사항이 있어서 문의드리게 되었습니다. 강의내용은 @Transactional, @TransactionalEventListener가 전역적으로 선언되었고 outbox 관련 로직만 존재하기 때문에 괜찮지만 제 업무환경에서는 @TrasnactionalEventListener가 사용되면 프로젝트의 모든 @Transactional으로 관련된 내용이 바인딩되기 때문에 이를 scope 별로 구분하는 방법이 필요해보였는데요. 따로 알아보았지만, payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니 혹시 관련하여 TrasnactionalEventListener 어노테이션 필드 혹은 커스텀 어노테이션만으로 구분할 수 있는 방법이 있을까요 ? 문의드리는 가장 큰 이유는 outbox 로직이 필요없는 DB처리에도 TrasnactionalEventListener이 우선은 호출되고 payload를 통해 early return 시키려고 하다보니, 불필요한 리소스 사용을 방지하고 싶어서 문의드리게 되었습니다.
안녕하세요. 예전에 리뷰 이벤트를 신청했었던 사람이니다. 당시 구매한 강의 3개(레디스, 스칼라, 그래들)를 수강했던 수강생입니다. 당시 리뷰 이벤트로 강의를 제공받은 후, 개인적인 오해와 감정적인 대응으로 인해 영자 측에 해당 강의들 모두 철회 요청을 드렸었습니다. 지금 돌이켜보면 너무 감정적으로 행동했던 것 같고, 다소 어리석은 선택이었음을 느끼고 있습니다. 그 후 지식공유자님께도 별도로 사과의 말씀을 전한 적이 있으며, 그때의 제 행동에 대해 진심으로 반성하고 있습니다. 이메일 cis940320@gmail.com 으로 신청을 드렸었고, 해당 메일 내역을 통해 당시 리뷰와 신청한 강의 내역도 확인 가능하실 것이라 생각됩니다. 혹시 가능하다면, 철회했던 강의들을 다시 수강할 수 있는 기회를 부탁드릴 수 있을까요? 당시에 제가 작성했던 리뷰도 정성스럽게 남겼던 기억이 있어, 다시 한 번 수강할 수 있게 된다면 더욱 성실하게 공부하고 의미 있게 활용하고 싶습니다. 번거롭게 해드려 정말 죄송하고, 답변 기다리겠습니다. 감사합니다.
안녕하세요! 우선 강의 너무 잘 듣고 있습니다! 강의 자료에서 좋아요 수 설계 부분에서 11:17 1:1 관계이지만, 테이블 비정규화의 필요성을 살펴본 것이다. 이 부분은 1:1 관계이므로 비정규화의 필요성이 있지만, 레코드 락으로 인한 자원 한계를 고려하여 '정규화'의 필요성을 살펴본 것 이 맞지 않나 싶습니다! 혹시 제가 잘못 이해한 부분이 있다면 알려주시면 감사하겠습니다!
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 3-6. 쿼리플랜이란? 여기까지 이해하신 내용은 무엇인가요? 옵티마이저가 스토리지 엔진으로부터 가장 효율적으로 데이터를 가져오기 위해 쿼리플랜을 작성한다는 것을 이해했습니다. 2. 어려움을 겪는 부분 어떤 개념이 헷갈리시나요? 이때 인덱스를 참고해서 데이터를 가져온다면 이 인덱스는 메모리에 올라와 있는 상태인가요?? 아니면 디스크에 있는 인덱스를 확인하고 디스크에서 데이터를 가져오는 건가요? 데이터를 가져오는 전체적인 흐름이 궁금합니다! 3. 시도해보신 내용 문제 해결을 위해 어떤 시도를 해보셨나요? 에러가 발생했다면 어떤 에러인가요? 현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
위의 내용과 같이 언제, 어떻게 만료 시킬 지에 대한 만료 방식을 cache eviction이라고 해주셨는데 검색해보니까 내용 상의 차이가 있다는 것을 알게 됐습니다. TTL, TTI와 같은 특정 시간, 점유 시간에 대해 발동되어 cache expiration으로 정의가 됐습니다. 반면 cache eviction은 메모리 공간이 부족한 경우 발동되어 LRU, LFU, FIFO 등으로 구분됐습니다. 결국 둘 다 캐시 삭제 기법이긴 하나, 트리거 조건에 차이가 있었습니다. 면접에서 eviction 관련 질문을 받는다면 둘을 혼용해도 무방할까요?
안녕하세요 선생님 좋은 강의 감사합니다. 저희 articleController에서 readAll 부분을 보면 @GetMapping("/v1/articles") public ArticlePageResponse findAll( @RequestParam("boardId") Long boardId, @RequestParam("page") Long page, @RequestParam("pageSize") Long pageSize ) { return articleService.readAll(boardId, page, pageSize); } 이런식으로 pageSize를 쿼리 파라미터로 넘겨주도록 설계가 되어 있는데, pageSize라는 파라미터는 값을 받아서 처리하는 것이 아니라, 서버에서 값을 정하고 항상 똑같은 pageSize를 써야하는 것 아닌가요 ?? 왜 pageSize를 인자로 받는지 이해가 잘가지 않습니다.
안녕하세요 선생님 강의 잘 듣고 있습니다 . controller를 구현하실때 중복되는 부분을 전부 다 쓰신 이유가 따로 있으신가요 ? 예를 들어 ArticleController에서 @RequestMapping("/v1/articles") public class ArticleController{ ... } 이런식으로 RequestMapping 애노테이션을 붙여 중복을 줄일 수도 있는데 선생님은 전부 다 그냥 쓰셔서 어떤 의도가 있는 것인지가 궁금합니다.
현재 페이지네이션 기반 조회 시 조회 과정이 궁금해서 질문드립니다. secondary index에서 offset 위치까지 순차탐색 -> secondary index -> 클러스터링 인덱스에서 primary key 조회 -> 실제 데이터 조회 일단 위 과정이 맞는지 궁금합니다. 2 . 위 과정이 맞다면 이 과정에서 db에서 데이터 조회를 limit만큼 반복하는 것인지, 아니면 실제 db에서 데이터 조회는 한 번에 이루어지는 것인지 궁금합니다. 페이지 조회 말고 그냥 범위 조회일 시에는 한 번에 조회되서 값이 많아도 시간 차이가 많이 안나는지 궁금합니다. offset 없이 조회해보니 바로 조회되는 거 같긴합니다.
현재 댓글 무한 depth까지 수강했는데 snowFlake를 통해 Id값을 넣고 있는데 해당 부분을 service단에서 entity.create를 통해 구현하는 점에 대해 궁금증이 생겼습니다. 이런 방식으로 계속 진행이 되면 보일러 플레이트방식이 되는것 같은 느낌이 들어서 차라리 커스텀 IdentifierGenerator를 통해 Entity안에서 값을 넣어주면 어떨까하고 생각을 해보게 되었습니다. 이렇게 진행하면 기존 service를 통해 진행하는 것보다 비효율적일까요?? 두개의 차이점이 궁금합니다
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요 항상 좋은 강의 잘 보고 있습니다. 다름이 아니라, 현재 강사님 프로젝트 구조가 정확하게 실무에서 사용하는 MSA 프로젝트가 맞나요? 아니면 , 모놀리식 기반 멀티 모듈 구조를 통해 MSA 학습을 위한 구조인가요? 현재 강의를 보면서 토이 프로젝트로 MSA 학습을 진행해보려고 하는데, 해당 구조가 실제 현업에서 사용하는 구조가 맞는지 궁금합니다 !
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 3-9강 여기까지 이해하신 내용은 무엇인가요? B+Tree 작동 원리, INDEX 생성 2. 어려움을 겪는 부분 select o1_0.id, o1_0.created_at, o1_0.member_id, o1_0.order_date, o1_0.order_number, o1_0.status, o1_0.total_amount, o1_0.updated_at from ch3_orders o1_0 where o1_0.order_date>='2023-01-01T00:00' and o1_0.status= 'COMPLETED' and o1_0.total_amount>=500 order by o1_0.order_date desc; 위와 같은 쿼리를 실행할 때, INDEX의 첫번째 필드를 date로 하였을 때, date의 정렬 방식에 따라서 속도가 달라지는 이유가 궁금합니다. (즉, 아래처럼 2가지 방식의 INDEX) CREATE INDEX ids_order_date_status_amount ON ch3_orders(order_date desc, status, total_amount); CREATE INDEX ids_order_date_status_amount ON ch3_orders(order_date, status, total_amount); 날짜 기준으로 최신 데이터를 100개 가져오는 쿼리를 실행시켰을 때, B+Tree의 leaf 노드에서는 양방향으로 이동할 수 있기 때문에 date가 ASC 정렬된 상태에서 역방향으로 읽어 최신 데이터를 읽으나, DESC 정렬된 상태에서 순방향으로 읽어 가져오나 읽는 노드의 수는 동일하다고 생각이 듭니다. 실제로 date를 각각의 정렬조건으로 INDEX를 만들어서 실제로 실행을 시켰을 때에도 거의 차이가 존재하지 않았습니다. (데이터가 많지 않아서 그런지는 모르겠습니다...) 하지만 제가 시도 한 내용이 맞는지 잘 모르겠습니다. 3. 시도해보신 내용 ASC, DESC 정렬을 시킨 INDEX를 사용하여 analyze 한 결과입니다. Limit: 100 row(s) (cost=50413 rows=100) (actual time=0.874..0.899 rows=100 loops=1) -> Index range scan on o1_0 using ids_order_date_status_amount over ('2023-01-01 00:00:00.000000' <= order_date AND 'COMPLETED' <= status AND 500 <= total_amount)... Limit: 100 row(s) (cost=50413 rows=100) (actual time=0.43..0.446 rows=100 loops=1) -> Index range scan on o1_0 using ids_order_date_status_amount over (order_date <= '2023-01-01 00:00:00.000000' AND status <= 'COMPLETED'), with index condition: (... 1번은 ASC로 정렬한 INDEX입니다. 2번은 DESC로 정렬한 INDEX입니다. 여기에서 desc로 정렬한 acutal time이 거의 2배 빨라진 것을 확인 할 수 있습니다. analyze가 정확한 값을 알려주지 않을 수도 있다는 사실을 알고 있지만, 제가 판단한 내용이 맞는지 의심이 듭니다. 딩코딩코님도 desc로 정렬을 하신거 보면 이유가 있을 것이라고도 생각합니다. Q1. 위 상황에서 INDEX의 첫번째 칼럼은 정렬 조건이 의미가 없는 게 맞나요? Q2. 만약 의미가 있다면 어떤 부분에서 의미가 있는지 궁금합니다.
