안녕하세요 조영호님, 강의 복습하며 설계의 깊이를 더해가고 있는 수강생입니다. 8~9장을 통해 상/하위 모듈의 패키지 배치 원리를 배우며 실무 적용에 대해 고민이 생겨 질문 남깁니다. 그동안 실무에서 레이어드 아키텍처를 주로 사용하며 서비스와 도메인 로직을 구분해 왔는데, 복습하다보니 그간 해왔던 물리적인 패키지 분리(인터페이스와 구현의 분리 등)를 엄격하게 적용하는 것이 자칫 오버 엔지니어링이 아니었을까 하는 생각이 들었습니다. # 프로젝트 패키지 구조 예시 Project - ServiceInterface - ServiceImplement - RepositoryInterface - RepositoryImplement - Controller - Model 최근에는 의식해서 도메인 모델을 만들어 보는데, 기존 레이어드 아키텍처의 패키지 구조 내에서는 '도메인의 응집도'와 '레이어의 규칙'이 충돌하는 지점 이 생겨 배치가 모호해지곤 합니다. 이에 두 가지 질문을 드리고 싶습니다. 1. 단순히 레이어드 아키텍처로 감당하기 힘들어지는, 즉 '도메인 중심의 패키지 구조'로 변화해야 하는 구체적인 징후나 시점 이 있을까요? 2. 모든 모듈에 엄격한 패키지 분리를 적용하기에는 비용이 부담된다고 생각되는데, 마치 절차지향과 객체지향 중 하나를 선택하듯, 패키지 수준의 격리를 우선적으로 적용하기 좋은 도메인 특성 이 있을까요? (예: 정책 복잡도가 높아 사이드 이펙트가 빈번한 곳, 혹은 외부 인프라 변경에 민감한 핵심 도메인 등) 최근에는 조영호님의 도서/강의 통해 배운 내용을 의식하면서 실무에 적용해보는데, 예전보다 일 하는게 즐거워진거 같습니다. 미리 답변 감사드립니다. 좋은 하루 되세요. 🙇🏻
안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다. 강사님의 조언대로 처음에는 '의미 있는 이름'을 우선적으로 부여하고자 했습니다. 하지만 실제 설계를 진행하다 보니 다음과 같은 딜레마를 겪고 있습니다. 1. 직관성 저하 및 매핑 테이블 식별의 어려움 명확한 의미가 떠오르는 것만 의미형으로 짓고, 나머지는 연결 강조형(A_B)으로 설계했더니, 전체 ERD를 볼 때 어떤 테이블이 독립 엔티티인지, 어떤 테이블이 단순히 N:M 관계를 해소하기 위한 매핑 테이블인지 한눈에 파악하기가 어려워졌습니다. 규칙이 혼재되다 보니 오히려 일관성이 무너지는 느낌을 받았습니다. 2. 다중 다대다(N:M) 관계에서의 한계 그렇다고 매핑 테이블의 일관성을 위해 모두 '연결 강조형(A_B)'으로 통일하자니, 두 엔티티 사이에 여러 개의 M:N 관계가 존재할 때 문제가 발생했습니다. 예를 들어, User와 Store 사이에 '찜하기', '방문 내역' 등 여러 맥락의 관계가 존재할 경우, 단순한 user_store 라는 이름만으로는 이 관계들의 성격을 전혀 대변할 수 없었습니다. 보통 실무에서 이러한 상황일 때, 일관성(매핑 테이블임을 명확히 인지)과 의미(어떤 맥락의 관계인지 표현)를 모두 충족시키기 위해 주로 어떤 네이밍 패턴이나 타협점을 사용하시는지 실무 노하우가 궁금합니다!
안녕하세요, 선생님! 6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다. 데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지 저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지 일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다. 제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.
안녕하세요. 히스토리 테이블 관련해서 질문이 있습니다. 원본테이블에 업데이트 이유를 트랙킹할 필요가 있으면 변경 사유 컬럼들을 추가하라고 말씀주셨는데 생성, 수정, 삭제시 모두 히스토리 테이블에 스냅샷형태로 저장한다면 변경 사유 컬럼들은 히스토리 테이블에만 있는게 좋지 않을까 싶어서 질문드립니다.
안녕하세요, 요즘 이직 준비하면서 CS 인사이드나 좀 얻고자 해당 강의를 무료로 수강 중인데요. 우선 영상 만드시는데 수고하신 것 같습니다만 이해가 안되는 부분들(다형성)이 있어서 문의드립니다. 2강 '객체지향은 어떻게 동작하는가?' 6:08 해당 주제명과 코드는 추상화 라고 해야 적합할 듯한데요. OCP는 추상화에 관련 있기도 하고요 6:26 다형성의 핵심은 부모타입으로 다루는 것(구현이 아닌 추상에 의존한다) 이 말씀이 무슨 말씀인지 이해가 잘 안되는데, 공부하셨던 자료 출처가 있을까요? 결론적으로 문의를 요약하면 다형성 개념을 오버로딩/오버라이딩 개념보단 추상화 개념으로 보는 것 같은 데 다형성과 추상화과 어떤 관련이 있는 지 궁금하며 공부하신 자료 출처를 남겨 놔주시면 다른 이들도 함께 공부하는 기회가 될 것 같습니다 :))
안녕하세요, 좋은 강의 만들어주셔서 정말 감사합니다!! 이번에 신규 기능을 추가하면서 통계 데이터도 필요한 상황인데 통계 데이터에 사용되는 원본 데이터가 수정되는 케이스는 어떻게 설계하는게 좋을지 조언을 구하고자 질문드립니다. 통계 데이터는 유저가 조회하고, 데이터 조회 기간은 최근 7일/최근 한달/과거 한달(사용자 조정 가능)로 조정이 가능하고, 한 화면에 4가지 유형의 통계 데이터를 제공해야 해서 이를 위해 일별 통계 테이블을 사용하려고 했는데요. 그런데 원본 데이터가 언제든 수정되거나 추가될 수 있는 상황입니다. 그래서 수정한 사용자와 수정 일자를 따로 모아 배치를 돌리는 방향이 생각났는데 이렇게 설계해본 경험이 없어, 우선은 실시간 증분 업데이트를 진행하고 데이터 정확성이 필요해지는 상황이 필요하다면 그때 위와 같은 배치를 돌리는게 나을지 또는 다른 방향이 있을지 궁금하여 질문드립니다. 정산 데이터는 아니기 때문에 멱등성이 깨질 수 있는 상황은 감안하고, 기획 요구사항인 실시간성을 반영하는게 좋을지도 고민이 되어 질문드립니다!
2NF를 충족하기 위한 조건은 다음과 같은 것으로 알고 있습니다. 제1 정규형을 만족하고, 모든 컬럼이 후보 키 전체에 완전 함수 종속되어야 한다. 예를 들어 수강 테이블의 컬럼이 다음과 같다고 할 때, id: PK [대리 키] student_id: UK1 [자연 키] course_id: UK1 [자연 키] student_name [일반 컬럼] 후보 키: id [기본 키 - 단일 후보 키] (student_id, course_id) [대체 키 - 복합 후보 키] (student_id, course_id)는 복합 후보 키이고, student_id -> student_name (부분 함수 종속)이므로 2NF에 위배되지 않나요? 따라서 대리 키만 써도 2NF에 위배되는 일이 발생할 수 있다고 생각합니다. 아니면, 실무에서는 2NF의 정의를 기본 키 에만 한정하여 2NF를 만족하는 것으로 보나요?
Redis Pub/Sub 구독을 통해 Redis 갱신 시 Sub로 구독 중인 각 서버에 캐시 무효화 및 강제 갱신 시키는 구조는 잘 안쓰이나요? 이 방법도 네트워크 순단 시 fire and forget, 구현 복잡도가 높음 등의 문제가 있긴한데 실무에서는 Pub/Sub을 잘 안쓰는지 궁금합니다.
안녕하세요 단건데이터(ex: 로그) 처리의 경우에는 크게 고민하지 않고 MERGE를 사용하여 처리하고 있습니다. 하지만 10~20건 이상의 데이터셋이 들어오는 경우에는 어떤 방식으로 처리하는 것이 더 적절한지 고민이 되어 질문드립니다. 데이터 DELETE -> INSERT 2번의 쿼리 수행(또는 BEGIN으로 1번에 수행) 데이터 STATE (I, U, D 등)를 활용하는 방식 화면에서 데이터에 INSERT / UPDATE / DELETE 상태값을 기반으로 서버에서 DELETE 1회, INSERT 1회, UPDATE N회를 수행 실무에서는 작업 공수 문제로 1번 방식(DELETE -> INSERT)을 선택하는 경우가 많았습니다. 다만 이 방법을 사용하면서 DELETE로 인해 발생하는 DB 블록 낭비 기존 데이터의 CREATE_DATE가 유지되지 않아 UPDATE_DATE와 의미 차이가 사라지는 문제 데이터 관리, 유지보수, 성능 측면에서 어떤 방식이 더 바람직한 선택인지 궁금합니다.
안녕하세요 영한님! "8. 상속 관계 설계" 강의에서, 상품 테이블 을 예시로 들어, 슈퍼타입-서브타입 모델링을 설명해주셨는데요! 만약에 서브타입이 다른 테이블과 관계를 맺게 된다면, 이 케이스에도 슈퍼타입-서브타입 모델링을 적용하는게 괜찮을지 궁금하여 질문을 드립니다! 예를 들어, 신고 내역을 저장하는 테이블을 모델링하는 상황에서, 회원 신고/게시글 신고/댓글 신고/그룹 신고 이렇게 나뉜다면 슈퍼타입-서브타입 상속 전략을 사용해도 괜찮은지 궁금합니다.
안녕하세요! 강의를 듣다보니 TTL 캐싱을 사용할 때에도 오류가능성이 존재하지 않나 싶어 질문 남깁니다. TTL을 1분이라 가정했을 때 TTL이 지나기 전에 DB의 값이 바뀌고, 그 이후 TTL이 지나기 전에 캐싱된 값을 사용하게 된다면 DB에 있는 값과 캐싱되어있는 값에는 차이가 존재하지 않나요? 이에 대해선 어떻게 구현되어있는지 궁금합니다
안녕하세요. 공통 코드를 가져와 사용하는 테이블 스키마를 정의할 때 궁금한 점이 있습니다. 영상 11분 05초를 보면 주문 테이블 과 결제 테이블 을 정의합니다. 이때 , order_status , payment_method , payment_status 와 같은 컬럼을 varchar로 정의하셨습니다. type-safe하게 정의한다면, 해당 컬럼들을 enum으로 정의하거나 공통 코드 상세 테이블과 relation을 설정해서 외래키를 사용할 거 같은데, 이와 같은 방식은 유지보수를 더 어렵게 만드는 구조인걸까요? type-safe하게 만들고 싶다면 애플리케이션 레벨(서버측 코드)에서 정의해주는게 좋은 방법인걸까요? ---------------------- 참고로 저는 nodejs 기반의 백엔드 개발자이며, 김영한님의 강의는 네트워크+DB만 수강하고 있습니다. (java+springboot+jpa 등의 지식과 경험은 전무합니다.)
안녕하세요 영한님!! 항상 좋은 강의 만들어주셔서 감사합니다! 함수 기반 인덱스 생성에서 질문이 있어서 글을 남깁니다! 강의를 들으면서 함수 기반 인덱스를 생성하면 가상 컬럼이 없고, 인덱스만 만들어진다고 이해했습니다. 그래서 product_json 테이블에 만들어진 가상 컬럼과 idx_v_storage 인덱스를 drop한 다음 각각 두가지 방식으로 테스트를 해보았는데요 CREATE INDEX idx_func_storage ON product_json (( CAST(attributes->'$.storage' AS UNSIGNED))); EXPLAIN SELECT * FROM product_json WHERE attributes->'$.storage' = 256; 이렇게 할 경우엔idx_func_storage 인덱스를 잘 타는 걸로 나왔지만, CREATE INDEX idx_func_storage ON product_json ((JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED))); EXPLAIN SELECT * FROM product_json WHERE attributes->'$.storage' = 256; 이 경우에는 FULL TABLE SCAN 이 되고, 인덱스도 NULL로 나왔습니다. 두 방식 모두 각각 idx_func_storage 인덱스는 잘 생성이 되었는데도 JSON_VALUE() 방식에서는 인덱스를 사용하지않았습니다 그래서 AI에게 물어보니 MySQL functional index는 WHERE절의 표현식이 인덱스 정의와 문자 수준으로 동일해야 한다. 이유는 가상 컬럼 방식에서는 MySQL이 내부적으로 expression rewrite 과 virtual column substitution를 더 적극 수행하지만 functional index는 표현식 exact match 요구가 훨씬 엄격하기 때문이다. CREATE INDEX idx_func_storage ON product_json ((CAST(attributes->'$.storage' AS UNSIGNED))); 이렇게 인덱스를 생성했다면 EXPLAIN SELECT *FROM product_json WHERE CAST(attributes->'$.storage' AS UNSIGNED) = 256; 이렇게 WHERE 절을 작성해야 하고 CREATE INDEX idx_func_storage ON product_json ((JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED))); 이렇게 인덱스를 생성했다면 EXPLAIN SELECT * FROM product_json WHERE JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED) = 256 이렇게 WHERE 절을 작성해야 한다고 답변해주었는데요! 이렇게 각각 테스트 해보면, 인덱스를 잘 타는 것으로 나옵니다..! 또한 CAST()로 인덱스를 생성한 경우 WHERE절에 JSON_VALUE()를 사용한 쿼리는 Index를 사용하지않고, FULL TABLE SCAN을 했으며, JSON_VALUE()로 인덱스를 생성한 경우 WHERE절에 JSON_VALUE()를 사용했을 경우에만 Index를 사용했습니다. 제 테스트에서는 CAST() 기반 인덱스는 WHERE절 축약 표현식에서도 인덱스를 사용하였고, WHERE절 JSON_VALUE()는 인덱스를 사용하지 않았습니다. JSON_VALUE() 기반 인덱스에서는 WHERE절에 동일한 JSON_VALUE() 표현식을 사용했을 경우에만 인덱스를 사용하는 것으로 보였습니다 이게 맞는 걸까요? 아니면 제가 잘못 확인한 걸까요?, 또한 functional index 매칭 규칙 실제 범위가 어디까지 인지? AI가 답변해준 동작 방식이 맞는 건지도 여쭤보고 싶습니다! (제 MySQL버전이 8.0.41이네요,,) 영상을 다시 잘 보니, 2:18 분에 idx_func_storage 인덱스를 CAST() 구문으로 생성하시고, 2:25분에 확인하실 때, EXPLAIN의 결과에서 idx_v_storage인덱스가 나오긴 합니다!
안녕하세요. 식별 vs 비셕별에 대한 db 설계 관련 내용 중에 영한님께서 일대다의 경우인 board 테이블(one)과 comment(many)에서 board 테이블의 id가 식별관계로 사용되는 경우 comment의 id는 채번을 따서 사용해야하고 시퀀스나 auto increment를 사용할 수 없다고 하셨는데 그 이유가 궁금합니다. 어쨋든 board 테이블의 id값은 row마다 존재하기에 각 comment row의 데이터가 어떤 board에 속하는지 그리고 순서도 asc 순으로 보장된다고 생각하는데요.. 꼭 채번을 사용해서 만들어야한다고 설명해주신 이유가 무엇인지 궁금합니다. 더구나 max+1 같은 경우 comment의 id값이 중복될 여지도 있다고 생각하는데요.. 설명해주시면 감사하겠습니다.
