Hong

안녕하세요 에어님!! 질문 주셔서 감사합니다.&nbsp;네 들으시는데에 있어서 도움이 되실꺼 같아요. SQL의 기본적인 문법이나 핵심적인 문법 그리고 DDL 설계 및 트랜잭션이나 ACID같은 개념들이 사실상 RDBMS의 공통적인 항목이라서 그대로 적용이 가능합니다.&nbsp;물론 온전하게 문법이 같지는 않아요. 예를들어 이런 부분들은 따로 학습하시면 좋습니다.<pre><code>LIMIT → ROWNUM 또는 FETCH FIRST n ROWS ONLY

AUTO_INCREMENT → SEQUENCE

IFNULL → NVL</code></pre>그래서 기본기를 MySQL로 다지고, Oracle 문법 차이점만 추가로 정리하시면 실무 적응에 큰 문제 없으실겁니다.!&nbsp;

오라클

강의에서도 한번 언급드렸떤거 같은데, 간단합니다. 정말 간단한 메시지 큐가 필요한 경우에 사용하시면 됩니다.<ul><li>Kafka나 RabbitMQ를 새로 띄우기가 좀 부담스러운 경우가 되겠죠.&nbsp;</li></ul>

Redis 큐

음.. 어떤 관점으로 보냐에 따라서 다를꺼같습니다.&nbsp;일단 당연하게도 일반적인 상황에서는 String을 주로 사용하니깐 그냥 그대로 사용하셔도 됩니다. 하지만 음... 기준을 좀 잡아보자면 이런 조건에서는 Hash가 유리할꺼같아요.<ul><li>객체 필드 일부만 업데이트할 때 (<code>HSET user:1 age 26</code>)</li><li>필드가 많고 부분 조회가 잦을 때</li><li>메모리 절약이 중요할 때 (ziplist 인코딩 덕분에 작은 Hash는 매우 효율적)</li></ul>&nbsp;그래서 사실상 트래픽이 낮을 떄를 기준으로 한다면 둘은 차이가 거의 없어요. 일반적으로 이런 서비스의 병목은 사용하시는 Redis의 타입보다는 네트워크 왕복횟수나 들어가는 키의 설계에서 옵니다.&nbsp;그래서 뭐 기본적으로 String + Json을 사용한다고 잘못되었다고 말하는거 자체가 잘못된겁니다. 그렇게 사용하셔도 무방하고 앞서 제가 기준을 잡았던 기준들에 대해서 저런 상황이 발생한다면, 그떄 한번 사용해보시는것을 고려해보시는게 어떨까싶습니다.

Redis Hash

안녕하세요 쵸잉님 질문 주셔서 감사합니다.&nbsp;말씀해주신부분처럼 굳이 인터페이스를 사용하지 않아도 됩니다. 이건 개인적인 스타일에 가까운거 같아요. 그래서 제 코드가 옳다고 말씀드리기에는 좀 조심스러운 부분이 있습니다.&nbsp;근데 분리하게 되었을 떄 가질 수 있는 장점은 몇개 있습니다. 대표적으로 CGLIB 같은 문제로 인해서 생성자 제약을 피할 수도 있고, DIP 원칙의 관점에서 구현체가 바뀐다는 부분도 가정했을 떄 변경하기도 편하죠.&nbsp;뭐 굳이 따지자면 이런 이유들이 다양하게 있는데, 우리가 현실적으로 코드 작성할 떄 막 이런 케이스까지 고려하지는 않습니다. 그래서 쵸잉님이 원하시는 스타일로 작성하셔도 큰 문제는 없을꺼같네요.&nbsp;어디까지나 개발은 각자만의 스타일이 있으니깐요 ㅎㅎ 이정도면 이해가 되셨을까요??감사합니다!&nbsp;

service 를 interface 로 두는 이유

안녕하세요. 강의 초기에 소스코드 챕터가 있는데 거기에서 다운로드 하시면 됩니다!! 감사합니다!!

강의에서 작성한 코드 제공 문의

안녕하세요 제우님 질문 남겨주셔서 감사합니다. 하나하나 나눠서 설명드려보도록 할게요.&nbsp;<ol><li>근본적인 아키텍처에 어떤 문제점이 생기는지, 잘 모르겠습니다.</li></ol>이거는 비지니스 요구사항에 따라 스키마 변경이 야기하는 다양한 문제입니다. 즉 테이블 구조 변경이 요구사항을 모두 처리하지 못하는 상황이 예시가 될 꺼 같아요.&nbsp;예를 들어 <code>is_vip</code>, <code>is_blocked</code>, <code>is_verified</code>, <code>is_dormant</code> ... 이런 식으로 컬럼이 계속 추가되면 테이블이 비즈니스 로직의 변화에 종속되고, 나중에 "이 컬럼이 왜 있지?"를 추적하기 어려워집니다. 즉 확장성과 유지보수성 에 집중한 문제로 이해하시면 됩니다.&nbsp;<ol start="2"><li>ALTER로 스키마를 변경하는 것으로 문제가 야기되는 부분이 정확히 어떤 부분이라고 생각하시는지 궁금합니다. 이미 많은 레코드가 있는 테이블의 스키마를 변경함으로써 생겨나는 I/O 부하를 생각하시는 걸까요?</li></ol>&nbsp;맞게 이해하신겁니다. Lock을 유발하는게 문제인거에요. MySQL InnoDB 기준으로 컬럼 추가 시 Online DDL이 지원되긴 하지만, 상황에 따라 테이블 전체를 리빌드 할 수 있죠. 그러면 수천만 건 테이블이면 이 작업 자체가 수십 분이고, 그 동안 쓰기가 블로킹되거나 서비스에 영향을 주는 부분을 피해갈 수가 없어요. 이게 Boolean 컬럼이 추가될 때마다 이 비용이 반복되면 문제가 되겠죠.&nbsp;<ol start="3"><li>I/O 비용의 증가가 발생한다는 부분은 2번에서의 비용 증가를 말씀해주신 걸까요? SELECT 비용 증가라면 사실 저장해야 하는 정보가 늘어나면서 자연스러운게 아닌가 싶은데 어떤 관점에서의 문제를 짚어주신 건지 궁금합니다.</li></ol>&nbsp;뭐 부하는 어떻게든 발생 가능한 구조로 이해하시면 됩니다. SELECT 부분에 대해서도 페이지 단위로 인한 부하가 있을 수 있고, 저장하는 정보가 많아지니깐 사실상 매우 자연스러운 행동이죠 다만 Boolean 컬럼의 특성상 대부분 <code>NULL</code> 또는 <code>false</code>인 경우가 많아서 실제로 의미 있는 데이터 밀도가 낮은데 row 크기만 커지는 비효율이 생길 수 있다는 부분도 같이 얻어가보시면 좋지 안흥ㄹ까 싶어요.&nbsp;<ol start="4"><li>논리 모델 vs 물리 모델, 그리고 세 가지 기법</li></ol>&nbsp;네 이해하신 방향이 틀리지 않습니다. 다시 정리해보죠.&nbsp;논리 모델은 "어떤 데이터를 저장할 것인가"이고, 물리 모델은 "실제 DB에 어떻게 저장할 것인가"로 생각을 하시면 됩니다. 이 상황에서 Boolean 속성이 많아지는 문제를 논리 모델 레벨에서 "이 엔티티는 여러 속성을 가진다"로 정의 할 수 있고, 물리 모델 레벨에서 그걸 어떻게 테이블로 구현할지를 선택하는 단계를 거치는 거죠.&nbsp;이 떄 구현 방법은 3가지가 있을겁니다.<ul><li>One Table per Anchor: 기본 테이블 하나에 핵심 속성만 두는 방식</li><li>Side Table: Boolean이나 부가 속성을 별도 테이블로 분리 (ex. <code>user_flags</code> 테이블)</li><li>EAV (Entity-Attribute-Value): <code>user_id | attribute_name | value</code> 형태로 속성 자체를 행으로 저장</li></ul>&nbsp;그래서 제가 말씀드리고 싶은 부분은 무작정 Boolean을 추가하는건 논리 모델을 그대로 물리 모델로 박아버리는 행위라고 말씀드리고 싶었어요. 뭐 상황에 따라서 나쁜 선택은 아닐 수 있다고는 생각합니다. 하지만 과연 이 방식이 가장 좋은 방식인가?? 이건 제가 판단하기에는 어려운 부분일꺼 같네요.&nbsp;질문에 답이 좀 되셨을까요?? 혹시 추가적인 질문이 있다면 남겨주세요!! 좋은 하루보내세요~~

21강에서 이해하기 어려운 부분들이 있습니다!

안녕하세요!! 현재 준비중에 있습니다 ㅠㅠ 아무래도 다른분들도 바쁘다보니... 생각보다 빠르게 진행이되지 않네요 ㅠㅠ 최대한 빠른시일에 준비하여 새소식을 통해 공유드리도록 하겠습니다.&nbsp;감사합니다!

혹시 오픈카톡 링크는 어디서 볼수 있을까요?

안녕하세요 SJ님 질문 주셔서 감사합니다. 새해 복 많이 받으세요 ㅎㅎ&nbsp;일단 무엇이 틀렸다 맞다라는 논쟁은 아닌거 같고 개인적인 취향과 가독성 측면에서 차이가 있을거같습니다.저는 어느정도 JOIN을 하는데에 있어서 의미가 더 명확한거 같아서 다음과 같이 수행한 바도 있어요. 예를들어서<pre><code>SELECT *
FROM Posts p
JOIN Users u ON p.user_id = u.user_id;</code></pre>이런 쿼리만 봐도 어떤 테이블의 키인지 명확하고 다중 조인하는 상황이 발생해도 가독성이 좋다고 생각합니다.&nbsp;근데 만약 pk를 id로 둔다면<pre><code>JOIN Users u ON p.user_id = u.id</code></pre>이런 형태인건데, 이게 틀린건 절대 아니에요. 근데 테이블이 많아진다면 가독성이 안좋아질꺼 같아요. 예를들면 이렇게 되는거죠<pre><code>u.id
p.id
t.id
c.id</code></pre>저는 개인적으로 가독성이 중요한 성격이라서 이 쿼리만을 보고 어떤 쿼리인지 의미가 명확하게 와닿지 않을꺼 같습니다.&nbsp;자기참조 측에서를 고려해 볼까요?? 예를들어서 User가 이런 구조라고 해보죠<pre><code>parent_user_id INT
FOREIGN KEY (parent_user_id) REFERENCES Users(user_id)</code></pre>여기서도 사실 크게 다를바가 없습니다. 근데 만약 PK가 id라면??<pre><code>FOREIGN KEY (parent_user_id) REFERENCES Users(id)</code></pre>사용하는데에는 문제는 없지만 앞서 제가 말씀드린 저의 곤점에서의 모델링 문서나 ERD 작성 측면에서 명확성이 더 떨어지는거 같아요.&nbsp;&nbsp;하지만 어디까지나 이건 제 취향일뿐 원하시는대로 해도 무방합니다. 사용하는데에 무방하고 취향적인 부분이 들어간 주제라고 생각해서 이걸 제가 맞다 틀리다라고 하고 싶지는 않아요.&nbsp;질문 감사합니다!

칼럼명

안녕하세요 SJ님 질문 주셔서 감사합니다. 새해 복 많이 받으세요 ㅎㅎ&nbsp;일단 프로시저를 저는 권장하는 성격은 아닙니다. 단순히 코드수준을 넘어서서 쿼리 수준에서 디버깅하는것과 기능을 추가하는 작업이 더 어렵기 떄문이에요.&nbsp;그래서 저는 코드단에서 사용하시는 것을 추천드립니다. <ul><li>제가 강의에서도 언급한거 같은데, 상황에 따라 프로시저가 유용한겁니다. 이 구조를 추천드리지는 않아요.<ul><li>예를들면 다른 팀의 DB에 접근해서 데이터를 가져와야하는데, DB의 데이터가 유출되는것을 방지하기 위해 프로시저 권한만을 사용해 데이터를 가져와야 한다던지 등등</li><li>보안적인 측면에서의 고려사항이 아니라면 일반 플랫폼에서 프로시저를 사용하는걸 전 비추천드릴꺼 같아요.</li></ul></li></ul>&nbsp;질문 감사합니다!

프로시저

안녕하세요 soap님 질문주셔서 감사합니다!! 먼저 새해가 지났지만 복 많이 받으시고 건강하시기를 바랄게요 ㅎㅎ 하나하나 개요를 나눠서 설명드릴게요.&nbsp;질문1 : 인덱스 분할/병합 관점에서 “걸어도 된다”는 결론에 도달하는 과정&nbsp;현실적으로 그런 케이스는 거의 없습니다. 저도 그렇게 사용해 본적이 없고 저와 함께 강의를 만드시는 분들도 그런 과정을 통해서 판단을 하지 않아요. &nbsp;왜냐하면 그건 트래픽의 유형에 따라서 너무나도 달라지는 값이기 떄문입니다. 그래서 무언가 기준을 잡고 이 기준을 넘어서면 설정한다. 이런식의 사고 과정이 아니라 그냥 읽기 트래픽에 집중한다. 이 부분만을 명심하시면 좋을꺼같아요.&nbsp;그래서 저는 보통 다음 순서로 판단합니다:<ol><li>실제 쿼리 패턴 확인 (슬로우 쿼리, 실행 계획)</li><li>풀스캔 비용 추정</li><li>해당 인덱스가 선택될 가능성 확인 (Cardinality, Selectivity)</li><li>쓰기 부하 패턴 분석 (INSERT/UPDATE 비율)</li></ol>&nbsp;그래서 핵심은 "이 인덱스가 없으면 실제로 서비스가 느려지는가?" 이 부분에 집중하시면 되는 겁니다. 읽기 쿼리가 문제가 없다면 굳이 쓰기 비용을 늘릴 필요는 없기 떄문이에요.&nbsp;질문2 : 인덱스 분할(split)이 실제로 문제가 되는 경우&nbsp;여러분들이 일반적으로 사용하는 MySQL은 InnoDB를 사용하고 있고, 이 InnoDB의 B-Tree 인덱스는 삽입하는 과정에서 페이지가 가득 차다면 분할이 발생하게 됩니다.&nbsp;이 과정에서는 여러가지 작업이 일어나죠<ul><li>페이지 복사</li><li>포인터 재정렬</li><li>redo log 증가</li><li>잠금 범위 확장 등등</li></ul>&nbsp;근데 여기서 중요한거는 이 많은 과정에서 우리는 이 두가지에 집중을 해야하는거에요.<ul><li>PK가 AUTO_INCREMENT라면 → 대부분 우측 삽입 → split 빈도 낮음</li><li>랜덤 키(UUID 등)라면 → 중간 삽입 → split 빈도 높음</li></ul>&nbsp;그래서 UUID를 PK로 사용했을 떄에는 인덱스를 조심하셔야 하고, 조회가 압도적으로 많다면 그냥 인덱스를 걸어버리는 과정으로 이해하시면 됩니다. <ul><li>무작위성만을 조심하면 될 꺼 같아요.</li></ul>&nbsp;질문3 : 라이브 환경에서의 OPTIMZE TABLE&nbsp;이건 이해하신것처럼 최후의 수단이 맞습니다. 왜냐하면 사실상 해당 과정을 진행하면 <ul><li>테이블 재생성</li><li>인덱스 재구성</li><li>데이터 재정렬</li><li>메타데이터 락 발생</li></ul>이런 문제들이 존재하기 떄문이에요.<ul><li>물론 8.0이상에서는 online DDL이 가능하죠. 그래서 가능은 하지만 갑작스럽게 리소스 사용량이 급증한다는 문제가 있습니다.</li></ul>&nbsp;그래서 OPTIMZE TABLE이 어떤 부분에서 위험한지 이해하시고 내가 이걸 이 상황에 적용해도 문제가 없는지 객관적인 부분들을 검토해보시면 좋지 않을까싶어요.&nbsp;질문 감사합니다!!

Hong

投稿