개요 동일한 문제를 TypeORM의 JOIN으로 해결할 수도 있고, 각 테이블을 개별 조회한 뒤 코드에서 매핑할 수도 있음 어떤 접근이 더 효율적인지는 데이터 크기, 관계 복잡도, 인덱스 상태, 네트워크 제약, 성능 요구사항에 따라 달라짐 핵심 장단점과 선택 기준을 정리함 TypeORM에서 JOIN 사용하는 경우 장점 단일 쿼리로 필요한 데이터 수집 가능, 왕복 횟수 감소로 지연시간 이점 DB가 JOIN과 실행계획을 최적화하는 경우 비용 최소화 기대 1:N, N:M 같은 관계 질의를 쿼리로 명시적으로 표현 가능 필터링, 정렬, 그룹화 등 집계성 처리에서 DB 연산 활용 용이 페이지네이션과 함께 일관된 결과를 만들기 수월함 단점 ...
개요 좋은 시스템 설계는 복잡해 보이지 않고 긴 시간 동안 별문제 없이 돌아가는 상태를 말함 핵심은 상태를 최소화하고, 검증된 단순한 컴포넌트를 필요할 때만 조합하는 방향 과설계나 과도한 신기술 도입은 문제를 감추거나 유지보수 비용을 키우는 경향 최소 기능의 단순 구조에서 시작 후 관측 기반으로 점진 개선 권장 시스템 설계의 정의와 접근 소프트웨어 설계가 코드 조립이라면 시스템 설계는 서비스를 조합하는 일이라는 관점 주요 구성 요소 팔레트 앱 서버 데이터베이스 캐시 큐와 잡 러너 이벤트 버스 프록시와 게이트웨이 좋은 설계의 징후 ...
개요 InnoDB 버퍼 풀은 데이터와 인덱스 페이지를 메모리에 캐싱하는 영역임 디스크 I/O를 획기적으로 줄여 지연 시간을 낮추는 게 목적임 InnoDB 스토리지 엔진(트랜잭션, MVCC, 행 단위 락 지원) 성능의 심장부라 할 수 있음 쉽게 말해, 자주 쓰는 데이터와 인덱스를 디스크 대신 메모리에 올려두고 처리하는 구조임 버퍼 풀 구성 요소 버퍼 풀에는 주로 이런 페이지(기본 16KB)가 올라옴 데이터 페이지: 실제 테이블 로우(Row)가 저장된 페이지 인덱스 페이지: B-Tree 인덱스 노드 페이지 (PK 및 세컨더리 인덱스 포함) 기타 관리 페이지: UNDO 페이지, 트랜잭션/MVCC 관리에 필요한 메타데이터 등 핵심 개념 페이지 캐싱 InnoDB는 디스크 데이터를 페이지 단위로 다룸 클라이언트가 특정 로우를 읽고 싶어 하면, 그 로우가 속한 페이지 전체를 버퍼 풀로 가져옴 이후 같은 페이지에 있는 다른 로우를 읽을 때는 디스크를 다시 보지 않고 버퍼 풀(메모리)에서 바로 조회함 ...