1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 4-8 여기까지 이해하신 내용은 무엇인가요?외래키 제약조건으로 인해 발생한 데드락 문제를 해결하기 위해 INSERT하려는 테이블에 외래 키를 제거한다.  2. 어려움을 겪는 부분외래키를 만약에 제거한다면, 어플리케이션 레벨에서 직접 관리한다고 했는데, 구체적으로 어떻게 관리를 하는 건지 궁금합니다!INSERT하려는 테이블과 연관된 테이블들을 먼저 조회(findXXX())를 하고, 만약에 없다면 예외를 발생시켜서 트랜잭션을 롤백시키는 방식으로 처리하나요? 실무에서 주로 어떻게 해결하는지 궁금합니다.그리고 외래키를 사용하지 않는 첫 번째 방법은 이미 테이블이 생성된 시점(INSERT하려는 테이블에 외래키가 추가되어 있는 상황)에서도 적용할 수 있는건가요?예를 들어, 이미 테이블에 데이터가 추가되어 있는 상황에서 첫 번째 방법을 적용하려면, 테이블 구조를 아예 바꿔야 할텐데 이 경우에는 두 번째 방법인 쿼리 순서를 바꾸는 걸 대안으로 사용하는 건가요?

안녕하세요 영한님. 강의 정말 잘 듣고 있습니다.common_code_detail은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다. 서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요.예를 들면, 다음과 같은 요구사항이 있을 거 같습니다.group_code가 ORDER_STATUS 인 code에 대한 변경 요청.SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED)변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다. 설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요.공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다.공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요?아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.

이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다.9. 논리적 모델링 - 실습.pdf 파일 제외하곤 모든 파일의 목차들이 다 마지막 정리로 이동하더라고요.그동안 영한님 강의들 자료에는 각 챕터로 쉽게 이동 하기 좋았거든요. 이부분이 개선 가능할까요?이 상태여도 학습은 가능한데, 건의드립니다. 감사합니다.

'섹션 5. 클라우드에서 내 서비스 띄우기: AWS로 배포하기' - '26. AWS EC2 서버에 애플리케이션 배포' 강의를 듣던 중 문제가 생겨 AI를 활용해 문제를 해결해보다가 해결을 못 했습니다. 이미 너무 많이 만져서 원래 상태로 복구하긴 힘들 거 같네요.강의를 처음부터 다시 들으면서 다시 만들어야 할까요? 깃허브 같이 중간 결과물을 다운 받을 수 있는 곳은 없나요?

안녕하세요 첨부된 sql 파일 [-- ### 해결책 - 코드값 분리] 에서 orders 테이블 order_status의 타입이 common_code의 code 타입과 동일하게 VARCHAR(50)으로 변경되어야 할 거 같습니다.  -- ### 해결책 - 코드값 분리 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, order_status VARCHAR(20) NOT NULL, total_amount INT NOT NULL, created_at DATETIME NOT NULL ); CREATE TABLE common_code ( code VARCHAR(50) PRIMARY KEY, name VARCHAR(100) NOT NULL );

안녕하세요, 강의 05:40 경 나타나는 기본 베이스 쿼리 중에 CAST(name AS CHAR) AS path 부분이 존재하는데요, name 컬럼이 이미 문자열 타입인데도 캐스팅을 하는 이유가 궁금합니다. 혹시 따로 이유가 있으실까요?

안녕하세요. 강의 잘 들었습니다. 기업에서 인턴할때 진행했던 프로젝트라 코드 공개가 불가능하면 어떤식으로 만드는게 좋을까요.

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다.그렇다면, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서 불필요한 DB 부하와 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하고 처리하는 것이 적절한가요?좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다.다만, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서는 애플리케이션 단의 단순한 선행 검증만으로는 이를 제어하기 어렵다고 느꼈습니다.예를 들어, 아래와 같은 코드에서는 다음과 같은 경쟁 상태(race condition)가 발생할 수 있습니다.T1: exists → false T2: exists → false T1: insert T2: insert ❌ (유니크 제약 위반) if (!likeRepository.exists(postId, userId)) { likeRepository.save(...); } 이처럼 애플리케이션 레벨의 exists → insert 패턴이 동시성 문제를 해결하지 못하는 상황에서DB 예외에만 의존하지 않고 불필요한 중복 요청과 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하는 것이 바람직하다고 보시는지 궁금합니다.

수업자료 최신화좀 해주세요.pdf 자료 보면서 하다가 하다 하다 안되서 커뮤니티랑 찾다보니까 버전 안맞아서 설치 안되고 있엇네요.자료 최신화 하면 좋을것 같습니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요.    여기 고급 가죽 지갑으로 되어있어야할 것 같은데, 'SQL 마스터 가이드' 로 되어있어서 QnA 남깁니다.

'섹션 3. 데이터를 저장하기, MySQL로 시작하기' - '17. MySQL 데이터베이스 설정하기 (Docker)' 질문입니다. 제가 기존에 만들어둔 도커 컨테이너도 3306 포트를 쓰고 있어서 포트 문제 때문에 기존 컨테이너를 삭제하고 진행했습니다. 여러 컨테이너를 만들려면 어떻게 해야되나요?안쓰는 포트 아무대나 만들면 되나요?예를 들어 지금 3306 포트를 쓰고 있으니까 다음에 만들 컨테이너는 3307을 쓰면 되는건가요? docker run --name mysql-twitter \ -e MYSQL_ROOT_PASSWORD=root123 \ -e MYSQL_DATABASE=twitterdb \ -e MYSQL_USER=dev \ -e MYSQL_PASSWORD=dev123 \ -p 3306:3306 \ -d \ mysql:9.33306 포트 말고 다른 포트를 사용할 경우 위 명령어에서 -p 3306:3306는 어떤 식으로 바꾸면 되나요?

강의에서는 비관적 락과 낙관적 락을 다루셨는데, 일반적으로 대규모 서비스가 아닌이상 좋아요 자체가 순식간에 많은 트래픽이 몰릴것같지않아 낙관락으로 처리하는 것이 더 효율적일것같다고 생각이듭니다. 그래도극단적인 상황을 대비해서, 뒤에서 나오는 조회수 처리처럼 레디스로 좋아요 수를 증가시키고 스케줄링같은걸로 RDB에 백업하는 방식은 어떤가요?동시성처리에서 비관적 락으로만 처리해야 하는 상황이 있을까요? 레디스의 분산 락을 사용하는 것이 성능 측면에서 비관락보다 유리할 때도 있을 것 같은데, 실제로 비관락을 반드시 써야 하는 예시나 사례가 궁금합니다.RDB 트랜잭션(@Transactional) 내부에서 레디스를 함께 업데이트하는 경우, RDB에서 장애가 발생해서 롤백이됬는데 Redis 만 데이터가 업데이트 되는 경우도 발생할수도 있을것같은데. 이런 경우를 어떻게 처리하는지, 2PC를 적용하는지 아니면 다른 방법이 있는지도 궁금합니다.

'섹션 2. 데이터 주고받기, Spring Boot API 서버 만들기' - '10. Postman으로 API 테스트하기' 질문 입니다. 오타로 @PostMapping과 @GetMapping의 URL이 불일치해서 포스트맨에서 제대로된 값이 안나왔더라고요.이럴 경우 오류도 안떠서 해결하기가 힘든데, URL 오타를 방지하는 방법이 있을까요?

1. 현재 학습 진도redis 2. 어려움을 겪는 부분 간단하게 제 프로젝트를 소개하자면 RSS피드를 통해 블로그의 글들을 불러와서 하나의 게시판에서 볼 수 있는 서비스 입니다.스케쥴러 작업에서 구독한 피드의 새로운 글들을 불러옵니다. 피드마다 비동기로 병렬 처리됩니다.이때 새로운 글인지 아닌지를 판단할 때 피드마다 redis를 사용하거나 피드마다 db의 조회를 통해 차이를 확인했는데 redis를 사용했을 때 빨라질 것이라 생각했지만 빠르지 않았습니다.3. 시도해보신 내용앞선 강의를 토대로 쿼리발생 횟수를 모니터링 횟수로 측정한 결과 피드가 100개일 경우 db의 조회를 활용했을 때 비동기 병렬 처리 되므로 100개의 select문이 나갑니다.redis를 사용했을 때는 0개의 select문으로 감소합니다. 하지만 성능은 비슷합니다.예상 가는 이유로는 redis를 사용했을 때 그 횟수가 너무 잦아서 redis에 연결하는 네트워크 시간 때문에 차이가 미미하다는 말이 있던 것 같습니다.만약 제 가설이 맞다고 한다면 redis를 사용할 때 항상 네트워크의 횟수를 최소화 해야만 redis의 성능을 온전히 이끌어 낼 수 있는건가요?보통 레디스를 사용할 때 이걸 다 생각하면서 1번만 redis가 조회 되도록 하고 생각하면서 쓰나요?그렇다면 제 코드에서 redis의 성능을 올바르게 나타내려면 피드의 새로운 글들을 하나의 List로 전부 묶은 후 redis에서 한번의 연결을 통해 한번에 캐싱을 확인해서 성능을 높여야 하는건가요?  

1. 현재 학습 진도부하테스트 2. 어려움을 겪는 부분부하 테스트의 코드를 통해 성능 개선 사례를 적으려고 합니다. 하지만 현재 평균 req_duration 즉 레이턴시가 너무 낮게 나옵니다. vus를 300으로 두었는데 아마 커넥션 풀이 모자라서 대기가 길어지는게 원인 같긴 합니다. 하지만 이걸 떠나서도 vus 300치고 너무 느리다고 판단되어서 이걸 개선했다고 포트폴리오에 쓰는게 의미가 있을지 걱정됩니다.또한 커넥션 풀이 모자라다고 대기업 개발자들이 항상 aws의 사양을 up시켜  커넥션 풀만 늘려서 해결하는 해결 방식을 사용하지는 않을 것 같은데 보통 성능 최적화를 통해 커넥션풀 점유를 짧게 해서 최대한 커넥션풀 고갈을 방지하는 방식으로 해결하나요?만약 그렇다면 성능 최적화 하는 방법에 부하를 분산하기 위한 kafka, redis, msa같은 기술들이 들어가는 건가요?마지막으로 성능 최적화를 포트폴리오 이력에 쓸 때 적절한 vus수가 궁금합니다 예를들어 면접관이 봤을 때 300명이라면 너무 적다고 판단되지 않을까 걱정되어서 어느 정도의 대략적으로 vus가 적정 인원인지가 궁금합니다, 3. 시도해보신 내용시도하진 않았지만 개선할 방법으로는 강의에서 제공해주신 mysql의 실행계획을 통해 index 추가와 커넥션풀 사이즈 늘리는 것 그리고 캐싱 도입을 생각하고 있긴합니다.

안녕하세요 영한님! 기초부터 설계까지 영한님의 강의 덕분에 실무에서 테이블을 설계할 때 큰 자신감을 얻고 있습니다. 늘 감사드립니다.강의를 듣고 운영 중인 서비스의 ERD를 검토해보니 과거 설계된 테이블들이 비식별 관계가 아닌 식별 관계로 되어 있는 등 개선이 필요한 상황입니다. 하지만 1인 개발 상황에서 데이터 마이그레이션을 수반한 대규모 리팩토링은 리스크가 크고, 기획팀의 신규 기능 배포 속도도 맞춰야 하는 딜레마에 빠져 있습니다.조만간 동료 개발자가 합류할 예정인데, 현시점에서 제가 취해야 할 스탠스에 대해 의견을 여쭙고 싶습니다.방안 A: 기획팀에 상황 공유후, 일괄 재설계를 통해 '기술 부채'를 완전히 청산하고 신규 기능을 올린다.방안 B: 영향도가 큰 부분부터 점진적으로 수정하며, 팀원이 합류한 뒤 안정적으로 함께 리팩토링을 진행한다.영한님의 실무 경험에 비추어 보았을 때 어떤 결정을 내리는 것이 팀과 서비스 관점에서 더 좋을지 조언해주시면 큰 도움이 될 것 같습니다. 감사합니다.

좋은강의 너무 감사드리며 많이 배워가는것같습니다.강의를 들으면서 질문이 있어 드립니다.포트 번호로 분리된 MSA 서버를 프론트엔드에서 쉽게 사용하도록 통합하는 방법이 궁금합니다. 일단 단순히 생각했었을때 ngnix 로 리버스프록시 적용해서 /article 이면 localhost:9000 이런식으로 리버스프록시로 구성해도 될것같은데현업에서 nginx 를 이용해서 구성을 하는지 또다른 많이 쓰는 방법이 있는지 궁금합니다.CQRS 환경에서 서버끼리 http 통신article-read 에서 cqrs 를 적용하여 각 서비스에서 필요한 정보를 http 통신으로 가져오는데 클라이언트와 서버가 아닌 서버와 서버끼리면 굳이 웹과관련된 정보가 전송되는 http가 비효율적(?)이지 않나? 라고 생각을했는데 데이터 통신을 할때 카프카로 필요한 데이터만 통신하는것은 어떤가요? 실제 msa 환경에서 서버끼리 통신할때 어떤방식으로 사용하는지도 궁금합니다. 

안녕하세요 영한님!섹션 3의 계층 구조 강의를 듣고, 계층(트리) 구조를 모델링하는 다른 방법에 대해서도 찾아보면서인접 리스트 모델 , 폐쇠 테이블 모델 이외에도 경로 열거 모델, 중첩 세트 모델 등이 있다는 점을 알게되었는데요 실무에서 경험을 묻고싶습니다!강의에서 소개해주신 이외에도 다른 모델을 상황에 맞게 자주 사용하시는지, 혹은 다른 방법들의 단점으로 인해 결국 인접 리스트와 폐쇠 테이블 모델의 사용으로 귀결되는 것인지 궁금합니다.

섹션 9의 퀴즈가 영어로 출력되요.

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 무한스크롤을 공부하면서 쿼리플랜을 자세히 살펴보았습니다. rows라는게 예상 스캔 행 수 라고 찾게 되었는데요, offset을 사용하지않고 마지막 last_article_id로 limit 30개 해서 30개만 스캔하면 될줄 알았는데, 저는 6백만개가 나오고 강사님은 5522497개 (무한 스크롤 설계 - 6:31초)가 나오는걸 알게 되었어요. 이게 시간은 빠르긴한데 뭔가 스캔하는게 많아서 이상하다 싶었어요.. 그래서 인덱스를 지우고, (article_id desc, board_id)로 위치도 바꾸거나, use index로 인덱스를 강제하게 해봤는데 결과가 똑같더라구요.. 이 row를 줄이기 위한 방법이 있는지 궁금합니다. cladue에서는 최악의 경우의 row를 보여준다고 하면서도, 또다른 답변으로는 쿼리 수정으로 최적화해야한다 나뉘더라구요. 최악의 경우라 해도 왜 6백만개나 scan하는지.. 그냥 속도빠르니깐 넘어가도 상관없는지 의심이 들어서 더 찾아볼수있는 방법이나 조언 부탁드립니다. 감사합니다. 강의 거의 완강햇다가 한번 더 다시 듣고있습니다.