질문이 있습니다 강의를 듣다보니 UUID를 써야겠다면 PK를 오토 인크리먼트 UNIQUE 를 UUID로 사용하라고 했는데 , 그리고 보안적인 측면으로 이야기하면서 오토인크리먼트는 유추 될수 있다 라고 하시면서 그러면 보안을 더 잘하는게 맞지 않냐는 말씀을 하셨습니다. 저도 말씀하신 생각과 같은데요 그런데 만약에 UUID와 오토 인크리먼트를 같이 쓰게되면 PK 값을 안보여주는 것도 이야기를 하셨는데 그러면 SELECT할때 WHERE 조건으로 UUID 즉 유니크 키를 사용하면 PK를 사용할때에 비해 이점이 줄지않나요? 그리고 문서 건수가 많아질수록 유니크 키 인덱스 부분도 쌓여서 비용이 쌓일거같은데 이부분이 궁금합니다.
build.gradle.kts id("com.google.cloud.tools.jib") version "3.4.5" 기존 3.4.4에서 3.4.5로 변경한 후 빌드가 정상적으로 완료되었습니다. Jib 3.4.5 변경 사항 Fixed fix: address windows deadlock issue when determining docker environment info #4267
안녕하세요 질문이 있습니다. b+트리 강의를 들으면서 문득 생각이 나서 질문드립니다.웹개발을 하는 회사원인데요 저희 회사에서는 pk를 랜덤 UUID를 사용해서 pk를 사용하고 있는데 프로젝트를 하면 마이그레이션을 하거나 할떄 꽤 많은 양을 합니다 수십만건 또는 수백만건 정도를 하는데 이 pk를 auto increment로만 바꿔도 성능이 많이 개선이 되나요?
안녕하세요, 강사님 강의 잘 듣고있습니다. 들으면서 궁금한 점이 한가지 있는데요, Redis 연산의 경우 이것도 I/O 작업일텐데 트랜잭션 내부에서 사용해도 되는것인지 궁금합니다. (ex HTTP Client 와 같이 I/O 작업의 경우에는 트랜잭션 내부에서 호출하는걸 지양하는것처럼..)
INSERT INTO users (name, email, age, city) SELECT '새 사용자', 'test메일', 25, 'seoul' WHERE NOT EXISTS ( SELECT 1 FROM users WHERE email = 'test메일' ); 이 쿼리를 처음에 설명해 주실 때 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 할 때 경쟁상태가 발생할 수 있다라고 하셨다가 뒤에 이 방식은 사실상 경쟁상태에 무관하다고 정정해주셨는데 그럼 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 했을때 무관하다는 의미인가요?? 왜 무관한지 잘 모르겠습니다.
eXPLAIN ANALYZE SELECT m.member_name, o.total _price FROM orders o JOIN member m ON m.member_id = o.member_id; 위쿼리를 시작했는데 거의 수분 5분이 넘어도 결과가 나오는데 너무 오래 걸립니다. Nested loop inner join (cost=5.85e+6 rows=4.86e+6) (actual time=2.89..446250 rows=5e+6 loops=1) -> Table scan on o (cost=503796 rows=4.86e+6) (actual time=0.77..3714 rows=5e+6 loops=1) -> Single-row index lookup on m using PRIMARY (member_id=o.member_id) (cost=1 rows=1) (actual time=0.0882..0.0882 rows=1 loops=5e+6) 위는 실행 계획으로 약7분 26초가 걸렸습니다. 그리고 데이터 넣을떄도 orders부분도 한 한시간 넘게 걸렷던거 같습니다. 강의를 듣고싶은데 이부분은 그냥 오래걸리면 넘어가도 될까요? 컴퓨터 사양도 그렇게 나쁘지않습니다 32gb램을쓰고 있는데 뭔가 강의를 계속해서 듣고 싶은데 이런거 하나하나 막힐때마다 너무 오래걸려서 어떻게 해야될지를 모르겠습니다.
문제를 풀면서 66. 인덱스 설계 가이드 라인 에서 카디널리티 이야기가 나왔던게 생각이 났습니다. is_active는 값이 TRUE/FALSE 2개이므로 카디널리티가 낮을거라(중복도 높음) 생각했습니다. 그리하여 문제에서 주어진 쿼리를 보고 중간에서 is_active에서 풀 스캔 VS is_active 컬럼도 인덱스에 추가할지 고민이 되었습니다. 정답처럼 인덱스에 추가해주는게 더 나은 선택인걸까요? 음... 때에 따라 다른거 같기도 합니다! TRUE/FALSE의 비율 같은게 추가 조건으로 나왔더라면 선택하기 더 좋았을 거 같네요. 예를 들어, TRUE의 비율이 95% 다 이러면 인덱스를 달아주는 것과 풀 스캔이 별 차이가 없었을 거 같다는 생각이 드네요!
안녕하십니까! 덕분에 수업 잘 듣고 있습니다! 쿼리를 쉽고 가독성 좋게 설계하면서 추가 비용이 드는 형태가 많이 보이는데 제가 실제 실무를 겪어보진 않았지만 직감적으로 느끼는 부분이 있습니다! LLM이 발전하면서 쿼리에 대한 작성 난이도가 낮아졌을거라고 예상하고 시간이 지날수록 이런 부분이 더 빠르게 발전될 것이라고 생각합니다! 그럼 쿼리 작성에 대한 비용이 낮아지면서 0에 가까워질 거 같은데 그럼에도 기존 소프트웨어 개발 실무에서 적용된 "쉬운 쿼리, 조금의 추가 비용"의 형태가 유지될까요?! 아니면 실제로 이러한 부분이 현업에서도 반영이 되고 있나요? 비즈니스 의도, 집단 환경에 따라 다르겠지만 영한님의 시선으로도 의견이 궁금해서 질문드립니다!
궁금한게 key_length 를 이용해서 어떻게 사용하는지에 대해서가 22강에서 안나왔는데 그 이후로 나오나요? key_len 이 기대한것보다 적으면 인덱스가 잘 사용되고 있지 않다고만 설명을 하고 지나가셨는데 이후에 key_len 값을가지고 개선 하는방법이 나오는지 알고싶습니다.
457 장표의 사진이 이해가 잘 안갑니다. 우선 트랜잭션을 열고 트랜잭션1에서 update를 하는 순간 lock 을 획득, 그 후 실제 version을 하나 올린 후 동일 트랜잭션이 commit하기 전까지 락을 잡고 있는걸로 알고 있습니다. 근데 이미지 순서로 따지자면 트랜잭션 2에서 트랜잭션1의 commit 전단계에서 update를 수행하게 되는데 이러면 격리수준에 따라 달라지겠지만 READ COMMITTED에서는 여전히 version=1로 존재하기때문에 정상적으로 update 처리 되는거 아닌가요? 실제로는 트랜잭션 1에서 lock을 계속 가지고 있어서 트랜잭션 2에서 update에 진입도 못하겠지만 이미지가 잘 이해가 안되네요 특히 왜 갱신실패응답으로 떨어지는지도 이해가 안갑니다.
무한 depth 댓글의 path 생성 방식에 대해 궁금한 점이 있습니다. 강의에서는 각 depth마다 00000 , 00001 같은 별도의 순차값을 부여해서 예를 들면 댓글1 → 00000 댓글2 → 00000 00000 댓글6 → 00000 00000 00000 댓글4 → 00000 00001 처럼 path를 구성하는 것으로 이해했습니다. 그런데 기존의 comment_id 가 이미 댓글 생성 순서를 보장한다면, 굳이 각 depth마다 새로운 순차값을 다시 부여하지 않고 comment_id 를 고정 길이 문자열로 변환해서 댓글1(id=1) → 00001 댓글2(id=2) → 00001 00002 댓글6(id=6) → 00001 00002 00006 댓글4(id=4) → 00001 00004 처럼 path를 만들어도 ORDER BY path ASC 시 동일하게 트리 순서가 보장될 것 같은데, 강의에서 별도의 순차값을 사용하는 이유가 있을까요?
안녕하세요 강의 잘 듣고있습니다. Service쪽 코드에 movablePageCount는 10L로 상수를 넣고 pageSize는 변수로 넣었는데 서비스적으로 볼때는 이 2개 전부 상수로 봐야하는거 아닌가 해서 질문 남깁니다. 페이지 하나당 몇개의 게시글을 보여줄 것인지, 현재 한 묶음당 몇개의 페이지씩 노출시킬건지는 모두 기획 단계에서 정해지므로 상수값으로 생각되어지는데 둘다 상수 혹은 둘 다 변수로 두지 않고 movablePageCount는 상수로 , pageSize는 변수로 파라미터에게 넘겨주는 이유가 궁금합니다
안녕하세요 강의 잘 듣고 있습니다. 취준생이라 실무 경험이 없어 좀 붕뜬 질문 인점 양해 부탁드립니다. 우선 쿼리를 통해 최적화 해야된다면 JPA에서 자동으로 만들어주는 쿼리는 최적화가 안되어있기에 이런식으로 네이티브 쿼리를 날리는거 자체는 이해했습니다. 하지만 결국 이렇게 JPA 안에서 네이티브 쿼리를 날리면 단순 mybatis 쓰는거랑 뭐가 다른가 하는 의문이 들더라구요. 이럴때는 이런 최적화 부분 말고 이외의 부분은 충분히 JPA에서 만들어주는 기본 쿼리로 가능하기때문에 부분적으로만 최적화된 네이티브 쿼리를 직접 날림으로서 보일러플레이트를 대신할 수 있다 뭐 이런식으로 이해하면 될까요?
안녕하세요, 해당 내용을 보다가 의문이 있어 질문남깁니다. SELECT SUM(stock_quantity) AS total_stock FROM product WHERE '2026-01-13 23:59:59' >= valid_from AND '2026-01-13 23:59:59' < valid_to; 해당 쿼리에서 valid_to가 13일 이면 13일 기준 데이터에서 위 쿼리에서는 제외되는데 그렇다면 AND '2026-01-13 00:00:00' < valid_to 조건은 틀린건가요?
