쿠케님 안녕하세요! 그간 안녕하셨는지요. 몇 주 놀다가 다시 반성하고 각성 모드로 강의 시청 하고 있습니다. 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 센세
안녕하세요. 강의 잘 듣고 있습니다. 제가 원래 질문이 많은데 개념을 이해가 잘 되도록 쉽게 설명해 주셔서 질문 드릴게 별로 없네요. 보통 api path에 id를 추가하시는거 같은데요. 현업에서도 auto_increment나, snowflake id같은 db에서 쓰는 id를 그대로 넣고 사용하시나요? 아니면 prefix등을 추가하여 조금 더 가공을 한다든지 하시나요? 숫자만 들어가니 좀 밋밋해 보이기도 하고 알아보기도 힘들거 같기도 해서요.
안녕하세요 쿠케님 강의 잘 듣고 있습니다. 아웃박스 패턴과 로그 테일링 기법은 물론 애플리케이션의 특징마다 다르겠지만 로그 테일링 기법이 선호되는 경우는 어떤게 있을까요? LLM 챗봇들과 열심히 논의해본 결과 둘은 실시간성과 구현의 단순성에서 가장 큰 차이로 느꼈는데요. 실제로도 두 가지가 핵심적인 기준 역할을 하는지가 궁금하고 이외에 제가 찾지 못한 다른 것이 있다면 무엇이 있을까요?
안녕하세요 쿠케님 ! CommentApiTest에서 readAll() 메서드의 body(CommentPageResponse.class); 부분에서 SQLException이 발생하는 것을 확인했습니다. 하지만 테이블 컬럼을 확인해보니, Comment 테이블에 content 컬럼이 분명히 존재하는걸 확인할 수 있었습니다. 그리고 실제로 readAll() 메서드가 사용되는 쿼리에서는 content 컬럼이 사용되지도 않는데, 어째서 content 컬럼을 찾을 수 없다고 하는지 모르겠습니다. findAll()의 쿼리가 잘못됐나 해서 쿼리문을 직접 실행을 해도 잘 돌아가는걸 확인할 수 있었습니다. 코드도 첨부하겠습니다.
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. findParent 메서드에서 return문을 보면 getDeleted로 부모 댓글이 삭제됐는지 여부를 확인하는 코드가 있는데, 부모가 삭제됐을때를 체크하는 이유가 무엇인가요? 부모 댓글이 삭제됐을 때, 더이상 하위 댓글을 달 수 없도록 하기 위함인가요? 하위 댓글이 남아있는 이상 부모 댓글은 "삭제됐습니다"와 같이 표시만 할 뿐이고 db에서 삭제되지는 않더라도 deleted=true로 바뀌어 있을텐데 만약 부모 댓글이 삭제됐을때 하위 댓글을 추가로 달 수 없는게 아니라, 계속해서 하위 댓글을 달 수 있다면 부모 댓글이 삭제된 상태라 하더라도 create 메서드를 실행할때 부모 댓글의 id를 넣어도 문제 없지 않은가라는 의문이 들어서요 create 메서드를 보면 parent가 null이라면 부모댓글이니까 null을 넣고 하위 댓글이라면 findparent에서 찾은 부모 댓글의 id를 넣어주는 코드인데, 부모 댓글이 deleted=true로 바꼈다 할지라도 DB 자체에서 완전히 삭제되지 않은 이상 즉, 하위 댓글이 여전히 남아있는 상황이라면 deleted=true로 바뀐 부모 댓글의 id를 넣어줘도 되지 않나?라는 생각이 들어서 질문드립니다!
안녕하세요, 강사님. 강의대로 진행했음에도 불구하고 계속 사진처럼 빨갛게 뜹니다. 제가 처음에 클라우데라 매니저 설치할 때 실수를 반복하여 클러스터를 세 번 정도 설치했다가 삭제하고 마지막으로 한 번 더 제대로 설치했는데, 이전에 설치했던 parcel 혹은 다른 잔여 파일이 남아서 그런 걸까요? parcel을 설치할 때마다 c 디스크 공간이 줄어들었던 걸 보면 잔여 파일이 남은 것 같긴 한데 어떻게 삭제해야 할까요?
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 구조를 보면 마지막 페이지로 갈 수록 모든 페이지 목록을 불러오는거 같은데 제가 이해한게 맞나요? pageLimitCalculator를 보면 page=4, pageSize=10, movablePage=3일때 pageLimitCalculaotr를 계산하면 61인데 현재 4페이지에 있다면 2번째 그룹인데 2번째 그룹의 데이터 목록들만 불러오는게 아니라 1번째 그룹데이터까지 포함해서 총 60개를 불러오는게 맞는거죠? 그렇다면 pageLimitCalculator 공식에서 (((page - 1) / movablePageCount) + 1) pageSize movablePageCount + 1; 마지막에 1을 더해주는데 왜 해주는 건가요? 다음 페이지에 데이터가 있나 없나를 확인하기 위해 1을 더하는건줄 알았는데 제가 생각한대로 마지막페이지로 갈수록 모든 데이터를 불러오는 구조라면 굳이 마지막에 1을 더할 필요가 있나 싶어서요 궁금합니다!
