안녕하세요. 강의 마지막에 카테고리별 조회수가 가장 높은 3개 기사를 추출 하는 쿼리 소개해 주셨는데요. 관련해서 질문 있습니다. Q1) 만약 categories 테이블에 id가 1,2,3인 데이터가 있다면 SELECT FROM WHERE category_id = 1 ORDER BY LIMIT 3SELECT FROM WHERE category_id = 2 ORDER BY LIMIT 3SELECT FROM WHERE category_id = 3 ORDER BY LIMIT 3이렇게 3번의 서브쿼리가 실행되고 각 결과를 전부 Union해서 최종 결과를 반환하게 되는건가요?Q2) LIMIT 3을 제거했을 때 내림차순 정렬이 안된 상태로 데이터가 반환되는데요. 그 이유가 뭔지 알 수 있을까요? 

게시글과 게시글 카테고리가 존재해야만 댓글을 작성할 수 있는 구조에서, 다음과 같은 시나리오를 테스트하고자 합니다.사용자가 댓글을 10개 작성하면 뱃지가 발급되는 시나리오를 테스트하려고 합니다.댓글을 작성하려면 게시글과 게시글 카테고리가 먼저 저장되어 있어야 하며, 댓글에는 post_id가, 게시글에는 post_category_id가 각각 존재합니다.이 상황에서 다음 질문이 있습니다: 댓글에 있는 post_id와 게시글에 있는 post_category_id를 nullable 하게 설정해도 괜찮을까요? 

5강 2분50초쯤에 '사용자의 수를 가져오는 함수'를 예시로 설명해 주셨는데요.- 이 Stored Function이 실행되는 순간에도 사용자의 가입은 계속된다.- 그로 인해 이 Stored Function은 호출할 때마다 결과값이 달라질 수도 있다.- 하지만 이러한 사용자 테이블의 레코드가 달라지는 것도 입력이 달라지는 것이라고 생각하기 때문에 MySQL서버에서 SELECT를 포함해서 하나의 Statement는 반드시 시작 시점의 스냅샷을 보도록 구현되어 있다.- 그래서 MySQL서버에서 실행되는 쿼리 문장 하나는 동일한 데이터 상태를 보게 된다.- 따라서 하나의 문장 내에서는 Stored Function이 여러번 호출되더라도 테이블의 데이터는 해당 시점의 스냅샷을 보기 때문에 함수의 인자만 동일하다면 입력이 달라지지 않는 것으로 본다.Q) DETERMINISTIC으로 정의된 함수에 대해서 스냅샷을 바라보도록 설정돼 있고, 이로 인해 함수가 참조하는 데이터(인자)가 변경돼도 그 외 나머지 입력값이 동일하다면 동일한 결과값을 반환하게 된다는 내용이 맞을까요?

안녕하세요deterministic 관련해서 궁금증이 있어 질문드립니다. 그럼 mysql stroed function을 생성할때 무조건 deterministic 으로 생성을 해야하는지요??예를들면, 함수 내에는 파라미터값을 받아서 select 결과값을 도출하는 가령, id값등등 있다고 가정하겠습니다. 그럼 select * from test where 함수('value') 등으로 넣어서 값을 도출받아 where 조건에 걸수있다고 가정해보면non deterministic 일 경우 fullscan을 탈거같은데요. 결론적으로 , 모든 함수를 전부 deterministic 으로 명시를 해줄경우 단점이 무엇인가요?? 감사합니다.

안녕하세요. 우선 이렇게 좋은 강의 해주셔서 감사합니다. 강의를 듣다가 궁금한 부분이 있어 질문드립니다.Q1) 10:00분 경에 "CHAR여도 utf8mb4같은 가변길이 캐릭터 셋을 사용하면 때로는 예약된 빈 공간이 없을 수 있다"라고 말씀해 주셨는데요. 제가 강의를 듣고 이해하기로는 '1~4byte값을 가질 수 있다는 가변길이 캐릭터 셋' 성질 때문이 아니라 '문자 하나당 크기가 1byte를 초과했기 때문에' 예약된 빈 공간이 없어지는 걸로 생각했습니다. 즉, 가변길이 캐릭터 셋인 utf8mb4가 아닌 하나당 크기가 3byte인 어떤 고정길이 캐릭터 셋을 이용하더라도 동일하게 예약된 빈 공간이 없을꺼 같은데 혹시 제가 이해한게 맞을까요?Q2) 마지막 내용 정리하시는 부분에서 "인덱스된 컬럼이라면 CHAR가 효율적일 가능성이 더 높다"고 말씀해 주셨는데 어떤 이유로 인덱스된 컬럼에 CHAR가 더 좋을 가능성이 높은건지 알려주실 수 있으실까요? 

동시성 제어를 optimistic 방식으로 구현을 하시고 retry 를 직접 구현하셨느데요-  혹시 직접 구현하지 않고스프링 @Retryable 을 이용안하신 이유가 있으실까요? @Retryable을 하면 더 간단하게 재처리가 가능할것 같아서요~!   

@Injectable() export class AuthService { constructor( private readonly jwrService: JwtService, private readonly userService: UsersService, private readonly configService: ConfigService, ) {}  class에서 constructor로 주입받은 의존성을 가져올때 key, value 형식이 아닌 순서대로 가져오는데 어떻게 첫번째에 무슨 의존성이 오는지 확신할 수 있게 되는건가요?단연한듯이 타입을 지정하고 내가 원하는 서비스를 꺼내오거나 레포지토리를 꺼내오는데 그 아래 어떤 바탕이 있는지 궁금합니다.

안녕하십니까 여정민 강사님! 강의 도중 궁금한 점이 있어 질문 드리고자 합니다. 질문은 12:32 초의 코드를 보면package com.example.paymentservice3.payment.application.service import com.example.paymentservice3.payment.application.port.`in`.PaymentConfirmCommand import com.example.paymentservice3.payment.application.port.`in`.PaymentRecoveryUseCase import com.example.paymentservice3.payment.application.port.out.* import org.springframework.scheduling.annotation.Scheduled import reactor.core.scheduler.Schedulers import java.util.concurrent.TimeUnit class PaymentRecoveryService ( private val loadPendingPaymentPort: LoadPendingPaymentPort, //결제 처리가 완료되지 않은 상태의 결제를 조회 하기 위해 private val paymentValidationPort: PaymentValidationPort, //결제 유효성 검사 private val paymentExecutorPort: PaymentExecutorPort, //결제 승인 요청 private val paymentStatusUpdatePort: PaymentStatusUpdatePort //결제 상태 업데이트 ) : PaymentRecoveryUseCase { @Scheduled(fixedDelay = 180, timeUnit = TimeUnit.SECONDS) override fun recovery() { loadPendingPaymentPort.getPendingPayments() .map { PaymentConfirmCommand( paymentKey = it.paymentKey, orderId = it.orderId, amount = it.totalAmount() ) } .parallel(2) .runOn(Schedulers.parallel()) .flatMap { paymentValidationPort.isValid(it.orderId, it.paymentKey).thenReturn(it) } .flatMap { paymentExecutorPort.execute(it) } .flatMap { paymentStatusUpdatePort.updatePaymentStatus(PaymentStatusUpdateCommand()) } } }위와 같이 작성되어있는데 여기서결제 유효성 검사결제 승인 요청결제 상태 업데이트위 3가지 기능 수행을 병렬로 처리한 이유가 궁금합니다.강의에서 언급된 이유로는 "각 작업 간의 수행 순서가 중요하지 않은 작업들은 병렬로 처리하여 전체 처리 시간을 단축" 이라고 말씀하셨습니다. 제가 생각했을 때는 유효성 검사에 성공하면 결제 승인을 요청하고 결제 승인 요청에 대한 결과를 바탕으로 결제 상태 업데이트가 수행이 되어야 한다고 생각되어 병렬처리를 하는 부분에 있어 타당함을 잘 모르겠습니다. 제 짧은 견해로는 결제 유효성 검사결제 승인 요청결제 상태 업데이트위 순서를 지켜 수행되어야 한다고 판단하였습니다. 이 부분에 대해서 강사님의 생각이 궁금합니다. p.s. 좋은 강의를 제공해주셔서 감사합니다. 여태 수강한 강의 내용들이 모두 새로워 덕분에 공부할 부분을 많이 찾게 되어 감사드립니다. 앞으로도 좋은 강의를 만들어주시면 많은 도움이 될 것 같습니다 화이팅!

좋은 강의 제공해주셔서 감사합니다!강의를 듣다보니 의문점이 하나 생겼는데요. 에피소드 14의 시퀸셜하지 않은 UUID사용시 범위 검색의 조회 효율성 문제를 언급해주셨는데요 데이터 삽입시 인덱스가 리밸런싱되거나 리프노드의 실제 데이터 위치가 이동하는 문제가 발생할수도 있을까요?  

현재 듣고 있는 강의 부분은 Guard chapter에서 basic, bearer guard를 적용하는 부분입니다. @Injectable() export class BearerTokenGuard implements CanActivate { constructor( private readonly authService: AuthService, private readonly usersService: UsersService, ) {} async canActivate(context: ExecutionContext): Promise<boolean> { const req = context.switchToHttp().getRequest(); const rawToken = req.headers['authorization']; if (!rawToken) { throw new UnauthorizedException('토큰이 없음'); } const token = this.authService.extractTokenFromHeader(rawToken, true); const result = await this.authService.verifyToken(token); // payload 반환 /** * req 객체에 넣을 정보 * 1) 사용자 정보 - user 객체 자체 * 2) token - token * 3) tokenType - access | refresh */ const user = await this.usersService.getUserByEmail(result.email); req.user = user; req.token = token; req.tokenType = result.type; return true; } } 제 개인적인 생각으로는 적어도 제목에 적힌 두 엔드포인트에 대해서는 현재의 BearerTokenGuard를 적용하는 것이 굳이 라는 생각이 듭니다. refreshToken을 이용하여 새로운 토큰을 발급받는 역할을 하는 두 엔드포인트에 대해 다른 줄은 다 문제가 크게 없다고 생각하지만 req.user = user;로 굳이 요청에 user 객체를 붙이는 것은 굳이라는 생각이 듭니다. 제 낮은 식견으로는 위 두 엔드포인트에 대한 guard는 또 따로 만들어야 한다고 생각이 드는데 강사님 생각이 궁금합니다.

먼저 강의 내용이 아닌 책내용을 질문하게 되서 죄송합니다. 하지만 여기 말고 질문할 곳이 마땅치 않아 부득이하게 이곳에 적게 되었습니다. 부디 사정을 봐주시길 부탁드립니다. Real MySQL 1권의 10.2 실행 계획 확인(415pg)에서는 EXPLAIN ANALYZE 실행 시 나타나는 결과에서는 다음과 같은 규칙이 적용된다고 설명되어 있습니다. 들여쓰기가 같은 레벨에서는 상단에 위치한 라인이 먼저 실행들여쓰기가 다른 레벨에서는 가장 안쪽에 위치한 라인이 먼저 실행 이 말대로라면 아래 그림에서의 실행순서는 F, D, E, C, B, A 가 됩니다. 하지만 책에서는 실행순서가 D, F, E, C, B, A 로 된다고 적혀있습니다. 들여쓰기가 다른 레벨에서는 가장 안쪽에 위치한 라인이 먼저 실행된다고 하여 F 가 가장 먼저 실행될 줄 알았는데 D 부터 시작된다고 적혀있어서 혼동이 왔습니다. 혹시 왜 D 부터 시작하는지 설명을 부탁드릴 수 있을까요?감사합니다.  

안녕하세요, 좋은 강의 감사합니다. 제공해 주신 코드를 분석해 보고있는데요,구현한 헥사고날 아키텍쳐에 대한 다이어그램이나 설명이 있으면 이해하기 쉬울것 같은데 혹시 작성하신 게 있으실까요? 예를들어서, 이런 부분의 코드는 어디서 메시지를 가져오는지 intellij 로 검색해봐도 나오질 않아서요.package com.example.paymentservice2.payment.adapter.`in`.stream @Configuration @StreamAdapter class LedgerEventMessageHandler ( private val paymentCompleteUseCase: PaymentCompleteUseCase ) { @Bean fun ledger(): Function<Flux<Message<LedgerEventMessage>>, Mono<Void>> { return Function { flux -> flux.flatMap { message -> paymentCompleteUseCase.completePayment(message.payload) .then(Mono.defer { message.headers.get(KafkaHeaders.ACKNOWLEDGMENT, ReceiverOffset::class.java)!!.commit() }) }.then() } } } 그리고, adapter 내부의 in, out 폴더와 application 내부의 in, out 폴더의 차이점은 뭔가요?? P.S 수준 높은 코드라서 매우 좋습니다. 다른 강의도 이정도 수준이면 수강할 것 같습니다. 타강사님들의 강의는 쉬운것들이 많아서 경쟁력이 있으신것 같아요.

하나의 사람이 하나의 사람에게 팔로우할때 본인 스스로 팔로우 금지A 라는 사람이 B 한테 팔로우 increment 가능A 라는 사람이 B 한테 한번더 팔로우 요청 보내게 된다면 decrement 가 됨으로 메서드 하나로 코드를 구성하는것은 어떤가요 ??

강의 2:30 쯤에서@ManyToMany(() => UserModels, (user) => user.followees) @JoinTable() followers: UserModel[]; @ManyToMany(() => UsersModel, (user) => user.followers) followees: UserModel[]; 위처럼 되어있는데요 .혹시 @ManyToMany(() => UserModels, (user) => user.followers) @JoinTable() followers: UserModel[]; @ManyToMany(() => UsersModel, (user) => user.followees) followees: UserModel[];이렇게가 아닌가요 ??

안녕하세요 거의 강의 다 들어가는데요 ~ 추천해주셔서 아마 패스트캠퍼스에서도 뵙게 될것 같은데결제에 대해서도 다뤄주시면 안될까요 ??

이커머스를 기반으로 가정하고 사용자의 결제가 진행되는 과정을 정리했을 때 다음과 같이 고려해볼 수 있을 것 같습니다. 단일 구매 혹은 장바구니를 통해 결제 페이지로 이동결제 페이지에서 사용자가 필요한 데이터를 작성한 후 결제하기 버튼을 클릭백엔드 서버는 해당 결제 요청으로부터 PSP에게 결제 진행을 요구하기 위해서 요청을 보내고 토큰과 같은 형태로 받아옴토큰을 사용자에게 반환한 후 사용자가 결제를 진행결제가 성공적으로 진행되었을 경우 백엔드 서버는 결제 승인 요청을 PSP로 전송결제 승인 응답이 돌아오면 결제 완료이커머스는 상품의 유효성 검증은 2번과 3번 모두 검증한다고 해도 재고 감소와 같은 로직 및 주문 번호를 생성하는 로직은 어느 시점에 두어야 될 지 고민이 됩니다.재고 수량의 감소를 3번에서 진행하는 것으로 고려하고 있는데 이와 같은 경우 결제 페이지로 사용자가 결제에 필요한 데이터를 입력하고 재고가 부족하다는 입력을 받을 수 있어서 사용자 경험 측면에서 안좋을 수 있다고 생각이 되긴 합니다. 하지만 2번에서 진행할 경우 재고를 결제 페이지로 이동할 때 감소시켜야 하기 때문에 실제로 결제가 이루어지지 않을 수 있는 많은 상황이 있을 수 있기 때문에 이 또한 고려해야 되는 부분이라고 생각합니다. 어떤 시점에 재고를 감소시키는 것이 좋을지 의견을 듣고 싶습니다. 추가적인 질문으로 현재 강의에서 진행하고 있는 결제 이벤트를 DB에 반영하는 시점이 정확히 어떤 시점인지 헷갈립니다. NOT_STARTED 상태로 저장되는 시점이 결제 페이지로 이동하는 시점인지 아니면 결제 구매 버튼을 누른 시점인지 알려주시면 감사하겠습니다!

현재 주문 번호를 생성하는 방식은 결제 페이지로부터 들어오는 데이터들을 이용해서 그것을 String 형태로 변형해줌으로써 모든 요청들이 같은 형태의 String Key값을 가지게 되고 그것을 주문 번호로 사용하는 것으로 이해했습니다!주문 번호의 경우 쿠팡이나 다른 이커머스사들을 확인해보면 숫자 혹은 거기에 문자정도로 생성되어 있고 결제 완료시 주문 번호를 확인해볼 수 있습니다.이와 같은 방식으로 주문 번호를 생성하려면 위와 같은 방식이 아닌 별도의 로직을 통해서 주문 번호를 생성해야되며, 요청이 1번만 처리되기 위해서 Unique한 값으로 생성되어야 됩니다.현재 제가 진행하고 있는 프로젝트에서는 결제 페이지로 사용자가 진입했을 때 주문 번호를 특정 로직을 통해 Unique한 값으로 생성해주고 DB를 확인하고 Redis에 기록하는 절차를 진행하여 멱등성을 보장하고 있습니다. 이와 같이 진행하다 보니 주문 번호를 생성하기 위해서 DB에 쿼리를 1회 이상 날리는 상황이 발생하게 되는데 이와 같이 진행하는 것은 안좋은 형태일까요?

안녕하세요. 현재 JPA를 사용하고있는데 말씀해주신대로 varchar(255)를 기본 string 값으로 잡고있더라고요 이부분을 필요한만큼 테이블수정을 기하는것이 좋은 설계인것인가요? 아니면 jpa 기본권장스펙대로 가는게좋은건가요?

안녕하세요. 강의를 잘 듣고 있는 수강생입니다.강의를 듣다가 좀 다른 결일 수도 있는 궁금증이 있습니다.범위기반 데이터 조회에 아래 예시에서 order by finished_at, id 부분에서 finished_at이 범위검색 쿼리로 들어가는데 이런 경우 뒤에 있는 id는 인덱스를 타지 않는 것으로 알고 있습니다. 그럼 id로 범위 검색하려고 하면 finished_at으로 검색된 범위 안 전체 데이터를 전부 스캔하게 되나요?select * from payments where finished_at ≥ ‘시작날짜’ and finished_at < ‘종료날짜’ and id > 8 order by finished_at, id limit 30

백엔드를 이 강의로 처음 알아가고 있는데 .Horizontal Scaling 가 정확히 뭔지모르겠어요 설명해주시는 것중에서 Redis , in-memory 등 서버들이 같은정보를 바라보고서 사용자 정보를 우리가 판단 한다.. 이게 무슨말인지 아예 와닿질않아요 설명 해주실 수 있을까요