안녕하세요 강의 듣다가 문득 궁금한점이 생겨서 질문드립니다. ArticlePageResponse 클래스에 List<ArticleResponse> articles; 를 구성으로 하여 클래스를 생성해주셨는데 ArtlcieResponse를 상속하여 만들어진 ArticlePageResponse를 활용하여도 상관 없을까요?? 자바, 스프링을 동시에 공부하고 있다보니.. 주니어의 허접한 질문에 답변해주시면 감사드리겠습니다..
안녕하세요! 강의 늘 잘 듣고 있습니다, 감사합니다. 다름이 아니고, Comment 테이블 관련한 질문인데요. 일전에 비슷한 경우를 보았는데, parentCommentId를 null로 둔걸 본 것 같습니다.(용량절약을 위한 목적이였다고 들었습니다) 혹시 최상위 자신의 commentId로 parentComentId를 지정한 부분에 대해 궁금해서 글 올리게 되었습니다. 감사합니다.
위 도표를 보여주시면서 설명을 해주실때, 10시 정각에 스레드 1이 쿠폰 발급 로직을 시작 10시 2분에 완료가 된다면, 스레드 2는 스레드 1의 작업이 모두 종료될때까지 기다렸다림. 스레드 2는 10시 2분에 작업을 시작 이렇게 설명해주셨는데, 이게 잘 이해가 안됩니다... 제 생각에는 아래와 같이 10시에 동시에 처리되는 흐름이 되어야 할 것 같은데요... 즉, 스레드2는 쿠폰 생성 로직이 끝날 때까지 기다리지 않고, 스레드 1이 쿠폰 발급 로직을 수행 중이라도 스레드 2는 곧바로 Redis 값을 받고 독립적으로 로직을 수행 할 수 있을 것 같은데 아닌가요?? 레디스 자체는 싱슬스레드이니 레디스를 찌를때는 무조건 하나씩만 들어가겠지만 스레드 1은 레디스에 찌르고 값을 받아온 후 본인의 비즈니스 로직 수행할때 스레드2가 레디스 서버에 찌를 수는 없는건가요? 제가 이렇게 이해한 부분이 잘못된 것인지, 아니면 제가 강의 설명을 오해한 것인지 혼란스러워 질문을 드리게 되었습니다.
안녕하세요! 강사님 늘 강의 잘 듣고 있습니다. 다름이 아니고 아래 사항에 대해 궁금한 부분이 있는데요. (아래 강의 20:16 시점입니다) https://inf.run/1668e secondary index -> clustered index로 limit 개수만큼 접근해주신다고 설명해주셨는데요 ! where board_id = 1만 조건이 있어서 이미 어떤 row인지 세컨더리 인덱스에서 판단이 가능할 것 같은데, 클러스터 인덱스로 접근하게 되는 이유가 어떻게 되는걸까요? 만약 where board_id = 1 AND writer_id = 1 이 있다면 writer도 검증이 필요하기 때문에, 클러스터 인덱스 까지 가는 부분은 이해되기는 합니다만 board_id만 조건이 걸린 상태에서 클러스터 인덱스도 간다는 부분을 보고 이해가 잘 안되어서 문의드립니다 .. !
쿠케님 안녕하세요! 그간 안녕하셨는지요. 몇 주 놀다가 다시 반성하고 각성 모드로 강의 시청 하고 있습니다. Redis에 24시간 이내의 최신글을 저장하는거 까지는 이해했습니다! 그렇다면 레디스에 저장한 최신글은 프론트에서 어떻게 활용할수 있는 걸까요? 제가 생각한 아래 흐름이 맞는지 검토 부탁드립니다! 서버 게시판 종류마다 24시간 이내의 최신글을 레디스에 저장 게시판 종류와 데이터 개수를 request로 받는 최신글 API를 별도로 만듬 프론트 사이트의 메인 페이지 일부 화면에 특정 게시판의 최신글을 뿌려주는 요구사항이 존재 서버의 최신글 API를 호출하여 각 게시판 종류마다 최신글을 뿌려줌 감사합니다~!
안녕하세요. 예전부터 목록 조회 관련 궁금한게 있었는데 어떻게 설계하는게 좋은지 몰라서 문의드립니다. 강의의 예제처럼 하나의 테이블에 대해서 게시글 목록을 보여주는 기능들은 어떻게 해야하는지 잘 이해가 됩니다. 근데 보통 개발을 하다 보면 리스트를 보여주는 경우가 많잖아요. 그런 ux들을 보면 3~4개 이상의 테이블을 join하고, 여러 테이블에 대한 필터링도 하고, 여러 테이블의 여러 컬럼에 대해서도 정렬까지 하고, 페이지네이션까지 해야 하는 경우가 많았던 것 같습니다. 거기에 N:M구조를 join하는 경우가 있다면... 이런 기능들을 구현하려면 아무리 머리를 굴려도 full scan이 발생할 수 밖에 없을 거 같은데요. 필터링이나 정렬이 각각 다른 테이블 기준으로 선택이 된다면 속도가 나올 수 없어 보입니다. 대책을 생각해보면 그냥 원래 느리니까 db 성능을 믿고 그냥 join해서 보여줄수도 있고, 아니면 전체를 join 한 새로운 테이블을 만들기도 하는건지 궁금하네요. 근데 만약 새로운 테이블을 만들었더라도 N:M구조가 있었다면 또 1:N 구조가 여전히 남아있을테니 또 성능이 좋지 않을것이기에 생각이 많아지네요.
안녕하세요 다름이 아니라 application.yaml에서 설정값 모두 맞추고, gralde 빌드도 되었습니다 그런데 ArticleApplication 실행하는 부분부터 강의와 다르게 정상실행이 되고, ArticleService에서 OutboxEventPublisher 빈을 못 찾고 있습니다 outbox-message-relay 패키지 내 설정값 혹은 어노테이션 살펴봐도 감이 잘 오지 않습니다 지식공유자님의 코드와 샅샅이 차이점을 찾으려 했으나, 차이는 메세지릴레이 부분 뿐이었습니다 위 빈 문제를 해결하기 위해서 어느 부분을 확인하면 될 지 여쭤보려 합니다
안녕하세요 비관적 락에 대해서 잘 배우고 있습니다. 비관적 락1이 단순히 네이티브 쿼리를 이용하여 update 문 해서 바로 count를 수정하는건데 초반에 알려주신 조회할 때, 조회 락이 안 걸려서 데이터 일관성이 깨지는 거 알려주셨는데 비관적 락 1은 조회 자체를 생각하고 바로 갱신만해서 좋아요 수 카운트를 하는 건가요? 만약에 그렇다면 업데이트 시 락이 걸려 다른 트랜잭션 접근이 안되어 일관성이 유지가 되는 것은 이해가 갑니다. 테스트시 100번 동시 접근할 때 비관적 락2처럼 정합성이 보장되는거면 굳이 1이 더 빠르고 정확할텐데 비관적 락2를 쓰는 이유가 궁금합니다. 그리고 챗gpt한테 물어보니 단순히 update문하여 수정하는 것은 동시성 접근에 해결책이 안된다고 비관적 락 2쓰라고 하는데 테스트에서는 동시 100개가 접근해도 일관성이 충족이 되는거 보니 어느쪽이 맞는건지 모르겠습니다
안녕하세요 쿠케님! 강의에 나온 10분의 TTL이 없을시 조회수 증가 관련되서 질문드립니다!' 현 상황에서 게시글 접근시 마다 조회수 증가 API를 호출하고 있습니다. 테이블 정보는 다음과 같습니다. Board 테이블 id(auto-increment) readCount BoardRead 테이블 id(auto-increment) boardId userId 게시글 상세 접근시 마다 호출하는 '조회수 증가 API'의 흐름은 다음과 같습니다. 1. 해당 게시글을 유저가 조회 했는지 검증 (BoardRead 테이블에서 검증) 1-1. 조회 한 이력이 있으면 return; 2. Board 비관적 락 조회 3. Board 테이블 readCount 업데이트 4. BoardRead 테이블 insert Board의 readCount는 게시글 조회수를 나타내고, BoardRead는 '각 사용자는 게시글 1개당 1번 조회수 증가'를 검증하기 위한 용도 입니다. '각 사용자는 게시글 1개당 1번 조회수 증가' 정책을 반드시 가져가야 한다면 BoardRead 테이블에 있는 데이터도 레디스로 옮겨야 할까요? 그런데 조회수 데이터는 계속해서 쌓일테고 비즈니스에 중요하지 않은 데이터가 레디스 메모리만 차지하는 느낌이 들어서 꺼려지더 라구욤.. 강의 내용대로 TTL을 걸수 밖에 없는건가 고민도 듭니당.. (레디스는 클러스터 환경으로 사용하고 있습니다.) 기능은 그대로 유지하되 비관적 락을 뺄 수 있는 방법이 있을까요? ※ 번외로 트래픽 바로 몰리니까 비관적 락 로직 때문인지 잠금 이슈 나서 디비 바로 터졌버렸네요 하하하 ㅠ 비관적 락을 선호하지 않는 이유를 체감해버렸다.. ※ 뇌 + GPT 갈구니까 아래와 같은 여러 결론이 나왔습니다. 해결책1 1. Redis SET 자료구조로 중복 체크, 최초 조회면 TTL 걸어줌 2. 분산락(Redis)을 걸고, Board 테이블 readCount 업데이트 및 BoardRead Insert 수행 3. 락 해제 해결책2 1. Redis SET 자료구조로 중복 체크, 최초 조회면 TTL 걸어줌 2. 비동기로 Board 테이블 readCount 업데이트(낙관적 락 적용) 및 BoardRead Insert 수행 작성하면서 문득 'readCount를 정규화 할까?' 했는데 스케이링 넘 클것 같네요.. 이유는 테이블 설계를 JPA의 상속을 활용하는 방안으로 했기 때문에 readCount 필드가 '게시판'이란 추상 클래스에 위치해 있습니다. 주저리 주저리 적어봤는데 머릿속에 혼란이 오네요 ㅠㅠ 자기전 마지막 생각 레디스의 incr를 이용해 조회수 관리, 조회수 데이터는 mysql에 주기적으로 백업
안녕하세요. 쿠케님 강의 너무나 잘 보고 있습니다. 쿠케님 질의응답 게시글 정독하고 있는데 1:1 멘토링 부럽지 않을만큼의 고퀄리티 답변 언제나 감사드립니다. (갬동갬동) 현재 회사에서 조회수를 RDB에만 저장하고 있습니다. 이를 강의 내용처럼 'Redis 이전 & MySql 백업'을 적용 하고 싶은데 아래 흐름대로 적용 하면 될까요? 1⃣ (개발) redis 저장 및 조회, mysql 백업 코드 작성 2⃣ (개발) 기존 MySQL 데이터를 Redis에 저장하는 마이그레이션 코드 작성 => 이렇게 일회성 마이그레이션 같은 경우 테스트 코드로 한번만 돌리는데 쿠케님은 어떤 방식으로 하시나요? 3⃣ (배포 전) 1번 코드 배포 직전에 2번 로직 실행 4⃣ (배포) 1번 코드 배포 위 방식에서 발생할 수 있는 문제점 1. 3번(마이그레이션)과 4번(배포) 사이에 조회수가 누락될 가능성 - 마이그레이션 실행 후 MySQL에는 새로운 조회수가 계속 업데이트 되지만, Redis는 아직 트래픽을 받지 않음. - 즉, 마이그레이션 실행 이후 MySQL에 새로 기록된 조회수는 Redis에 반영되지 않음 → 데이터 불일치 발생 가능. 2. 처음 Redis로 전환할 때, Redis에 캐싱되지 않은 일부 조회수가 MySQL에 계속 쿼리될 가능성이 있음. - 처음 Redis로 전환할 때, Redis에 캐싱되지 않은 일부 조회수가 MySQL에 계속 쿼리될 가능성이 있음. - 특정 조회수가 빠르게 증가하면 Hot Key 이슈 발생 가능. 조회수 누락을 최소화 하는 방법 1⃣ (개발) redis 저장 및 조회, mysql 백업 코드 작성 2⃣ (개발) 기존 MySQL 데이터를 Redis에 저장하는 마이그레이션 코드 작성 및 실행 3⃣ (1번 코드 배포 전) 더블 라이트(Double Write) 모드 개발하여 운영에 적용 4⃣ (배포) 기존 MySQL 기반 조회수 코드 제거, Redis 기반으로 전환 5⃣ (배포 후) MySQL 백업 로직 실행 및 기존 MySQL 조회 로직 완전히 제거 제가 혹여나 놓친게 있거나 더 좋은 방법이 있으면 천천히 답변 부탁드립니닷! 출처: 내 뇌 + GPT 센세
