172만명의 커뮤니티!! 함께 토론해봐요.
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
이진 트리도 하나의 16KB 페이지에 여러 노드를 저장할 수 있는 것 아닌가요? 그렇다면 ‘이진 트리는 16KB 페이지를 읽어도 데이터 1개만 사용하고 나머지는 버린다’는 설명이 잘 이해되지 않습니다. 이 부분이 어떤 의미인지 설명해주실 수 있을까요?
미해결
김영한의 실전 데이터베이스 - 기본편
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 강의안 제목은 외부 조인이지만 앞에서 내부 조인 얘기를 함께 하기도 하고 명령어도 단순히 JOIN(내부)로 사용하셔서 부모가 자식과 조인을 할 때 행 개수는 유지되거나 증가할 수 있다는 얘기를 이해하기 힘들었습니다. 내부 조인의 경우에는 행이 감소할 수도 있으니까요 강의안 '조인의 특징' 섹션 내 코드의 JOIN 명령어들을 LEFT JOIN으로 변경 또는 외부 조인의 특징이라고 명시해주시면 더 정확할 거 같아요. 섹션 제목이나 본문에 어디에도 '조인'이라고만 나와있어서..ㅠㅠ 당연한 얘기인데도 많이 헷갈렸어요 심지어 내부 조인 명령어를 썼는데도 행 개수가 감소하지가 않는 예시들이어서요
해결됨
채널톡 면접관이 직접 알려주는 CS 면접 대비 - 데이터베이스 편
안녕하세요 강의 잘 보고 있습니다. 해당 강의에서 비관적 락과 낙관적에서 '임계 영역'의 길이가 해당 락을 선택하는 기준이 될 수 있다고 말씀하셨습니다. 근데 여기서 말씀하시는 임계 영역이라는게 잘 이해가 안되는데, 설명좀 부탁드립니다.
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
안녕하세요~ 강의 수강중 통계정보 갱신에 대해 여쭤보고싶은게 있습니다. 운영중에 간혹가다 옵티마이저가 실행계획을 잘못 선택해서 쿼리를 실행해서 슬로우 쿼리가 발생되는 경우가 종종있었습니다. 이때 use index 를 사용해서 주로 해결했었는데 이번 강의에서는 문제가 되는 테이블의 통계정보를 갱신하면 이런 문제들이 해결된다고 하시던데 운영중인 db 에 통계정보 갱신을 했을때 트레이드 오프같은게 없을까요? 실무에서 보통 어떻게 하셨는지 궁금하네요.
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
안녕하세요! PK 설계와 관련하여 궁금한 점이 있어 질문드립니다. 강의에서는 AUTO_INCREMENT 를 사용하면 PK가 순차적으로 증가하기 때문에 랜덤한 위치에 데이터가 삽입되는 것을 줄이고, 페이지 분할을 최소화할 수 있어 사용을 권장한다고 이해했습니다. 그런데 한편으로는 MSA 환경에서 PK로 UUID를 많이 사용한다는 이야기를 들었습니다. UUID를 사용하면 각 서비스에서 ID를 독립적으로 생성할 수 있다는 장점이 있다고 하는데, 서비스별로 데이터베이스와 테이블이 분리되어 있다면 각 테이블의 PK는 해당 테이블 내에서만 유일하면 되기 때문에 AUTO_INCREMENT 를 사용해도 문제가 없지 않을까 생각했습니다. 그래서 다음 내용이 궁금합니다. 실제 MSA 환경에서는 일반적으로 PK로 UUID를 많이 사용하는지 UUID 사용으로 인한 인덱스 크기 증가와 페이지 분할 등의 단점보다 UUID의 장점이 더 커지는 판단 기준은 무엇인지 찾아보니까 시간 순서 특성이 있는 UUID v7 라는 것도 있는데 이를 사용하는 건지 이런 궁금증이 생기는데 시원하게 해결이 되지 않아서 질문으로 남깁니다. 항상 좋은 강의 올려주셔서 감사합니다. 다음 강의에 해당 내용에 대한 설명이 다 있는 것을 확인하였습니다. 감사합니다!
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
커버링 인덱스가 아니라고 가정한다면 클러스터링 인덱스까지 2번의 B+Tree 탐색을 하지만 커버링 인덱스라면 이런 탐색을 한번 줄여 발생하는 IO 작업을 최적화 하는것으로 이해 했습니다 커버링 인덱스 말고도, 자주 사용되는 페이지의 위치를 자동으로 InnoDB에서 어댑티브 해시 인덱스라는 공간에 저장 하는것으로 알고 있는데 이 방식도 IO 작업을 최적화 하는 것인지 궁금 합니다
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
컬럼의 크기가 평균 1MB 정도 된다고 했을 때DB 버퍼 풀에 전부 올라오고 나서 서비스 서버로 올라가게 되는지 궁금 합니다 ! 서비스 서버 단에서 스트림으로 처리 한다고 해서 DB 메모리 공간도 같이 효율적으로 사용 되는지도 궁금 합니다 !
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
member와 product 데이터는 각각 4분, 5분 걸렸는데 orders는 2시간이 지나도 계속 돌고 있네요. 갤럭시북2 사용중인데 다른분들도 오래 걸릴까요??
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
쿼리 파서 기능에서 구분 분석을 통해 토큰 형식으로 분리하고, 어휘 분석을 통해서 문법 검증 및 파스 트리를 만든다고 알고 있었는데 구문 분석 부분에서 한번에 일어나는 작업인지 궁금 합니다
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다. is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데, 그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요? 만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요? 이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다. 실제 사례를 예시로 들어보자면 UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다. 이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다. 작은 조언이라도 해주시면 감사하겠습니다! -- 에이전트 인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.
미해결
김영한의 실전 데이터베이스 - 성능 최적화, 실행 계획과 인덱스 완전 정복
안녕하세요 영한님! 강의 재밌게 잘 듣고있습니다. 아직 섹션3까지 들었는데 MySQL 아키텍처 설명을 너무 잘해주셔서 너무 재밌게 들었습니다! 개인적으로 실무에서 PostgreSQL을 사용하고 있는데 혹시 PostgreSQL 아키텍처 강의도 업데이트 예정이 있으신지 궁금합니다!
미해결
김영한의 실전 데이터베이스 - 기본편
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 오류인 부분이라 신고합니다. 76강 2분 33초 부분에서 transaction 설명을 위해 계좌에서 이체되는 부분 말씀 하실 때 A고객이 1만원 이체하여 잔금이 줄어 4만원인 부분을 작성하시고 연이어 B고객 부분을 말씀하실 때 이체를 받았으니 1만원이 되어야 한다고 하며 10000원으로 적으셨습니다. 하지만 내용 상 30000원이 되어야 하는 부분으로 보입니다.
해결됨
10,000++억의 데이터를 다루는 카카오 면접관의 MySQL
강사님 안녕하세요 강의를 듣다보니 인덱스를 어느정도 아는 사람이 들어야 이해도가 많이 높아질거 같아 문의 드립니다 혹시 강사님 강의 중 인덱스나 좀 더 기본기 모델링을 배울 수 있는 강의가 있을까요? (ex: Hash Table과 Tree 자료구조,인덱스) 또, 혹시 행 기반 dbms가 아닌 duck db , 빅쿼리등 열 기반 dbms 강의도 론칭 예정이 있으신지 궁금합니다 현재 빅쿼리를 사용중인 신입 데이터 엔지니어인데 인덱스 개념은 안쓰고 파티셔닝, 클러스터링 밖에 없더라구요..
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
member 테이블에서 회원의 가입일은 비즈니스 시간이라고 생각했는데, 이 컬럼은 왜 created_at 으로 시스템의 시간만을 의미하도록 되어 있는지 궁금합니다. ordered_at, paid_at 과 같이 가입일 컬럼이 따로 존재해야 하는게 아닌지 궁금합니다! 강의자료에 예시로 적어주신 것처럼 비즈니스 시간이 데이터베이스 수준에서 마이그레이션을 해야한다면 회원가입일을 보존할 수 없지 않을까요?
미해결
김영한의 실전 데이터베이스 - 기본편
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] CASE문 단원 중 위의 '전체 GROUP BY'에서 '전체'라는 말이 오타인것 같아요~ CASE문 단원의 연습문제 4번 제시문 중 사용자 이름, 총 주문 건수, ` '전자기기' 주문 건수, '도서' 주문 건수를 각각 ~ 에서 '패션' 주문 건수라는 말이 누락되어 있는 것 같습니다. 영한님 강의 너무 잘듣고 있습니다!! 완강까지 힘내보겠습니다. 양질의 강의 진심으로 감사드립니다.
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 Substack 1년 제공에 대해 google form 신청완료했는데 확인 부탁드려요.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요 재민님! 좀 오래되긴 했지만, 2년 전쯤에 발표하신 (유튜브에도 자주 언급하신 ㅎㅎ) 개념과 격벽을 통해서 지속 성장 가능한 설계를 만드는 방법에 대해 여쭤보고 싶은 부분이 있어서 질문드립니다! Q1) 발표에서 개념을 코드로 느끼면서 잡아간다고 하셨는데, 이게 개인의 사고에 많이 의존하는 것 같아서요. 실제 팀에서는 한 사람이 발견한 개념(예: 대출 사례의 '연체' 분리 같은)을 팀원들과 어떻게 합의하고 공유하시나요? 코드 리뷰에서 자연스럽게 되는 건지, 별도의 논의 과정이 있는지 궁금합니다. 팀과 협업하는 관점에서는 설계가 결국 합의의 과정이기도 하다 보니, 이 방식이 팀 규모에서는 어떻게 작동하는지가 특히 궁금했습니다 ㅎㅎ Q2) 개발을 하다 보면 "설계"라는 과정을 많이 겪게 되는 것 같습니다. API 설계, ERD 설계, 시스템 아키텍처 설계 등등 참 많네요. 발표에서는 분석·설계 없이 바로 구현하면서 개념과 격벽을 잡아가라고 하셨는데, 실제로 새 기능이나 서비스를 시작하실 때 무엇부터 손대시는지 궁금합니다. 개념(도메인 클래스)부터 코드로 잡고 API나 DB 스키마는 나중에 따라오게 하시는 건지, 아니면 이런 것들 중 일부는 최소한으로 먼저 정해두고 시작하시는지, 재민님의 실제 작업 순서가 궁금합니다. 물론 절대적인 정답은 없고 케바케일 것 같긴 합니다. 예를 들면 프론트엔드나 타 팀이 의존하는지 등등에 따라 달라지겠지만요. 재민님만의 어떤 기준 같은게 있는지 궁금합니다. Q3) AI가 코드를 대신 짜주는 시대가 되다 보니, 회사에서도 코드를 잘 짜는 것 자체의 가치가 점점 낮아지는 분위기인데요. (물론 회사 KPI마다 다르겠지만 ㅎㅎ) 이런 시대에 개념과 격벽을 세우는 역량은 오히려 개발자의 마지막 차별점이 된다고 보시는지, 아니면 이 피드백 루프(구현하며 느끼고 개선하는)마저 AI가 돌게 될 거라고 보시는지, AI 시대에 이 방법론이 가지는 의미를 어떻게 보시는지 궁금합니다.
해결됨
채널톡 면접관이 직접 알려주는 CS 면접 대비 - 데이터베이스 편
강의를 듣다가 궁금한 부분이 있어 질문드립니다! Secondary Index를 사용하면 Primary(Clustering) Index Lookup 과정에서 랜덤 I/O가 발생할 수 있다고 이해하고 있습니다 다만 이는 Cardinality가 낮은 Boolean 컬럼에만 국한된 문제라기보다는, Secondary Index의 정렬 순서와 PK 순서가 일치하지 않는 경우 일반적으로 발생할 수 있는 문제라고 생각합니다 또한 MySQL에서는 MRR을 통해 조회 대상 PK를 정렬한 뒤 접근함으로써 랜덤 I/O를 줄일 수도 있는 것으로 알고 있습니다 강의에서는 Boolean 컬럼의 경우 특정 값이 전체 데이터의 상당 부분을 차지할 가능성이 높기 때문에, MRR을 통한 정렬 및 테이블 Lookup보다 Full Table Scan이 더 효율적일 수 있다는 취지로 설명해주신 것으로 이해했습니다 그렇다면 인덱스의 효율은 Cardinality 자체만으로 결정된다기보다, 실제 값의 분포와 선택도, 예상 조회 행 수, Covering Index 여부, MRR 적용 여부 등의 요인을 함께 고려해 판단한다고 이해해도 될까요?
해결됨
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 Substack 1년 제공에 대해 google form 신청완료했는데 아직 처리가 안된건지 확인차 문의드려요
해결됨
제미니의 개발실무 - 커머스 백엔드 레거시와 AI 활용편
GET /v1/shared-carts API 부분의 구현을 보니 CartReader.getCartAccessList 부분이 있는데 cartAccessRepository.findByUserIdAndStatus 메서드를 사용하여 조회하더라구요. 이렇게 되면 내가 만든 내가 소유자인 카트만 조회될 것 같고, 공유 장바구니 참여자 수 만큼 같은 공유카트가 여러개 조회 될 것 같습니다. 결국 소유자 조차도 access 데이터에 추가된다면 cartAccessRepository.findByAccessUserIdAndStatus 를 사용하여 범용으로 사용하는 것은 불가능할까요? 그리고 CartHandler.createCharedCart 부분에는 도구 레이어임에도 불구하고 하나의 트랜잭션으로 두지 않으셨는데요, 카트 생성 이후 나의 접근 권한이 추가 되지 않는다면 카트 리스트에서 볼 수 없을 것 같은데 이 점에 대해서도 의도하신 바가 있는지 궁금합니다! 또한 access 부분에서 DB 유니크를 걸어두었지만 사전 존재 확인이나 멱등처리가 없는 것 같습니다. 개념적인 예외를 사용하지 않고 DB 무결성 예외를 노출시키신 이유가 궁금합니다.
