안녕하세요 영한강사님! 좋은 강의 너무 잘들었습니다! 강의에는 없는 내용이긴한데요! 실무에서는 실제 FK제약조건을 설정하지 않더라구요. 선배님들은 확장성때문이라고 말씀해주시는데 이것말고도 다른 이유가 있는지 궁금합니다!

안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s SQL 쿼리는 분석결과 약 1700MS -> 70MS 까지 단축한 것 같습니다.5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식(일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.

hong님 안녕하세요! 라이브 운영중인 테이블에 인덱스 추가시 고려할 사항이 궁금합니다! psotgresql이긴 하지만 금일 오전에 데이터 1800만건이 있는 테이블에 인덱스 추가를 했더니 cpu 100% 치솟는 장애 직겨탄을 맞았습니다.. (15분간 앱 사용 중단 ㅠㅠ)뒤늦게 찾아보니 락을 잡지 않는 옵션을 추가했어야 하더군요. 새벽에 작업, 일시적인 디비 스펙업 정도만 떠오르네요. 몇천만건 ~ N억건 데이터가 있는 테이블에 인덱스 생성시 고려할 사항이 무엇들이 있는지 궁금합니다!  

안녕하세요!기존 PostRepository를 사용하다가 JPA 도입으로 JpaPostRepository가 새로 생겼는데, JpaPostRepository 클래스에 재구현을 하기 위해 default 메서드를 추가했는데 그 방법이 아닌 PostRepositoryImpl 와 같은 구현체를 만들어서 구현해도 무방할까요? 실무에서는 어떤 방식이 더 자주 사용 되는지 궁금합니다.

안녕하세요. 강의 잘 보고 있습니다.여기서 페이지네이션 구현을 values 데이터값을 가져와서 Java단 코드내에서 stream을 사용하여 페이징 처리를 하고 있는데, 만약 데이터를 DB에서 가져온 데이터라면 쿼리에서 페이징 처리(limit, offset)를 하는게 더 효율적일까요?

안녕하세요! 좋은 강의 잘 듣고 있습니다.CompletableFuture.runAsync()에 커스텀 Executor를 따로 넘기는 코드를 보면서 궁금한 점이 생겼습니다.동기 방식은 어차피 요청 스레드에서 직접 처리되니까 별도 스레드풀 설정이 의미 없는 거라 비동기에서만 설정하는 건가요? 아니면 동기에서도 풀을 따로 구성하는 케이스가 있는지 궁금합니다.그리고 Java 21부터는 Executors.newVirtualThreadPerTaskExecutor()가 기존 플랫폼 스레드풀을 대체하는 권장 방식인지도 여쭤보고 싶습니다. Virtual Thread는 풀링 없이 매 작업마다 새로 생성하는 방식이라고 이해했는데, 실무에서 전환할 때 주의할 포인트가 있다면 함께 말씀해 주시면 감사하겠습니다!

수강기간 연장 안되나요ㅕ..?

다른 분들에게 도움이 될까 글을 작성합니다.  저는 윈도우 환경에서 InteliJ를 사용하고 CLI 화면이 편하기 때문에 WSL를 사용하여 도커를 사용했습니다. 해당 전에 문제 해결들은 자료가 없어서 해결 방안만 말씀드리겠습니다.cloud... gradle 문제 해당 프로젝트가 One Driver에 있기 때문에 클라우드 상에 있는 그레이들이 안되는 것으로 알고 있습니다. 만약 프로젝트가 One Driver에 있다면 One driver 밖으로 이동 시켜주세요WSL 도커를 실행해도 윈도우 환경에서는 컨테이너를 찾지 못하는 경우가 있기 때문에 Window 환경에서 도커를 실행 하세요 해당 예외들이 터진 후에 모든 테스트 로직에 대해 예외가 발생합니다.BackendportfolioApplicationTests > contextLoads() FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: java.lang.IllegalStateException at LoadingCache.java:75 Caused by: java.lang.ExceptionInInitializerError at Class.java:-2 Caused by: java.lang.IllegalStateException at DockerClientProviderStrategy.java:277원래 전에는 build와 테스트가 잘 진행되었는데 무슨 일인지 Test에서 도커를 만들지 못하는 문제가 생겼나 봅니다. 저는 테스트에서 사용되는 DB Config들을 사용하는 곳에 주석 처리하고 도커 컴포즈로 DB를 주석 처리하고 테스트에서 사용되는 DB들은 Docker compose에 사용되는 DB를 켜서 사용했습니다. Docker Compose에서 사용되는 DB로 사용되기 싫으시다면 Docker 컨테이너로 따로 만드시면 될 것 같아요 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @SpringBootTest //@Import({TestDatabaseConfig.class, TestRedisConfig.class}) public @interface IntegrationTest { } docker compose up db redis -d   build 관련 에러들은 어노테이션 설정, gradle 설정, 컴파일 설정 등 많은 이유가 있어 하루 종일 붙잡아도 문제 해결이 안되는 점이 많아 시간으 며칠 잡아 먹었네요 글을 깔끔하게 가독성 좋게 작성하지 못해 아쉽지만 다른 사람들이 똑같은 문제를 맞았을 때 해당 글이 도움이 되길 바랍니다.

마지막에 professor_name을 pk로 두고 그에 따라 1:1이기때문에 과목명을 그냥 컬럼으로 두셨는데 그러면 그 과목명이 만약에 바뀐다면 (데이터베이스 -> DB) 그렇다면 데이터베이스 수업을 하는 모든 교수님의 컬럼을 바꾸어야하니 갱신이상이 일어나는것 아닌가요?이런 경우는 어떤 정규형을 위반한건지 궁금합니다.

안녕하세요. kafka 관련해서 질문이 있습니다.MessageRelay > publishEvent 에서 outbox를 삭제했는데 consumer에서 에러가 발생하면 데이터가 유실되는게 아닌가요?

DataInitializer 자체가 이해가 안되는게 있습니다.Test 환경에서 @Autowired 가 가능한건지 궁금하네요

Orchestration SAGA 패턴 구현에 대해 고민하다가 질문이 생겨 남깁니다.보상을 요청하는 메서드가 명시적으로 나와있어 호출할 때(동기로 호출)만약 rollback을 요청하는 호출이 실패하게 된다면 이후의 순서대로 service에 보상 요청을 하는 동작을 멈춰야 할지 계속 진행하는 게 바람직할지 고민이 됩니다.예를 들어 서비스 1,2,3,4가 있고 center server가 orchestration 관리를 하고 1,2,3,4 순서대로 서비스 호출해서 관리를 진행한다고 했을 때 3에서 장애가 발생해서 2를 롤백하던 중 2 롤백에서 예외가 발생해서 롤백에 실패한 경우 orchestration에서 1에 대한 롤백을 진행해줘야 할지 아니면 일단 멈춰야 할지 고민입니다. 고민의 이유는 순서대로 롤백을 해주는 것은 앞에 작업이 뒤의 작업에 의존성이 있을 때만 그렇게 해주면 되나에 대한 고민이 있었습니다. 두 롤백 간에 데이터 의존성이 없다면 괜찮지 않을까 고민했습니다.다음으로 일단 1도 롤백을 한다면 어디서부터 어디까지 롤백이 진행됐는지 추적이 어려워지지 않을까 고민했습니다. 롤백을 어떤 것은 해주고 어떤 것은 안해준다면 어디까지 롤백했는지 추적이 힘들어지지 않을까 생각이 들었습니다.

안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다. 강사님의 조언대로 처음에는 '의미 있는 이름'을 우선적으로 부여하고자 했습니다. 하지만 실제 설계를 진행하다 보니 다음과 같은 딜레마를 겪고 있습니다. 1. 직관성 저하 및 매핑 테이블 식별의 어려움명확한 의미가 떠오르는 것만 의미형으로 짓고, 나머지는 연결 강조형(A_B)으로 설계했더니, 전체 ERD를 볼 때 어떤 테이블이 독립 엔티티인지, 어떤 테이블이 단순히 N:M 관계를 해소하기 위한 매핑 테이블인지 한눈에 파악하기가 어려워졌습니다. 규칙이 혼재되다 보니 오히려 일관성이 무너지는 느낌을 받았습니다. 2. 다중 다대다(N:M) 관계에서의 한계그렇다고 매핑 테이블의 일관성을 위해 모두 '연결 강조형(A_B)'으로 통일하자니, 두 엔티티 사이에 여러 개의 M:N 관계가 존재할 때 문제가 발생했습니다. 예를 들어, User와 Store 사이에 '찜하기', '방문 내역' 등 여러 맥락의 관계가 존재할 경우, 단순한 user_store라는 이름만으로는 이 관계들의 성격을 전혀 대변할 수 없었습니다. 보통 실무에서 이러한 상황일 때, 일관성(매핑 테이블임을 명확히 인지)과 의미(어떤 맥락의 관계인지 표현)를 모두 충족시키기 위해 주로 어떤 네이밍 패턴이나 타협점을 사용하시는지 실무 노하우가 궁금합니다!

안녕하세요. 히스토리 테이블 관련해서 질문이 있습니다. 원본테이블에 업데이트 이유를 트랙킹할 필요가 있으면 변경 사유 컬럼들을 추가하라고 말씀주셨는데  생성, 수정, 삭제시 모두 히스토리 테이블에 스냅샷형태로 저장한다면 변경 사유 컬럼들은 히스토리 테이블에만 있는게 좋지 않을까 싶어서 질문드립니다.

섹션 2 강의 4 5 6 전부 검은 화면으로 나옵니다. 나머지 강의들은 제대로 영상이 틀어지고요. Inflearn 에서 제공해주는 영상 FAQ의 조치를 다따라 해봤는데도 되지않습니다.

안녕하세요! 강사님.강의 정말 잘 듣고 있습니다.산학협력 연구를 통해 머신러닝 프로젝트를 경험해보았는데, 그때 사용했던 자료들이 외부 반출이 불가하여,포트폴리오에 전처리, 머신러닝 모델등을 표현할 시각화 자료가 부족한 상황입니다.이럴 때는 혹시 어떻게 포트폴리오를 써야하는지 궁금합니다!

대충 빨리 듣고 필요한것만 정리 하고 넘어가고 싶은데 어렵고 지루하고 졸리고

안녕하세요 강사님,  강사님 설명이 굉장히 상식적으로 자연스럽게 이해가 되다 보니 따로 이해가 어려운 부분 없이강의 후반부까지 잘 따라 왔는데, 어딘가 마음속에서 걸려있던 의문점 하나가 터졌습니다. 예를 들어 35강 19:46 즈음에 카테고리 테이블에 색깔 컬럼을 진짜중복/가짜중복 을 나누는데1. HOME의 색을 YELLOW 로 바꾸면 UNIVERSITY 도 YELLOW로 바뀌는가? -> NO2. HOME의 색인 RED를 '빨강'으로 바꾸면 UNIVERSITY 도 '빨강'으로 바뀌어야 하는가? -> YES이 두가지 해석이 가능할 것 같습니다.. 물론 결과론적으로 머리로는 colors 테이블을 따로 만들어 FK로 연결하는 것이 맞다는 생각이 들지만강사님의 6가지 원칙을 차례로 따라가는데 헷갈림이 있어 질문드립니다. 감사합니다.

authService를 주입받을때 get을 사용해서 eager로 가져오는 것으로 보이는데 by inject<>으로 lazy로 가져오는 것이랑 어떤 차이가 있는지 알고 싶습니다. 또 실무에서는 보통 어느 상황에서 eager혹은 lazy를 사용하는지 알고 싶습니다.

안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식 (일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.