Performance

개념 UUID v7은 시간순으로 정렬 가능한(time-sortable) UUID임. 전체 128비트 길이와 표준 36자 형식(8-4-4-4-12)은 다른 버전과 동일하지만, 식별자 앞부분에 타임스탬프를 포함하는 것이 핵심적인 차이점임 UUID v7의 구조 UUID의 13번째 문자는 버전을 나타냄 UUID v4: 버전을 제외한 모든 비트가 무작위 값으로 채워짐 UUID v7: 앞 48비트가 Unix epoch 타임스탬프(밀리초 단위)로 구성되며, 그 뒤로 버전(7)과 나머지 랜덤 비트가 이어짐 구조를 분해하면 다음과 같음 0192f0c1-2345-7abc-89de-1234567890ab 0192f0c12345: 48비트 타임스탬프 7: 버전 7 abc: 랜덤 비트 8: Variant (RFC 4122 호환) 9de-1234567890ab: 나머지 랜덤 비트 이 구조 덕분에 UUID v7은 생성 순서와 정렬 순서가 거의 일치함. 나중에 생성된 ID가 사전순(lexicographical)으로 더 크므로, ID로 정렬하면 사실상 생성 시간순으로 정렬하는 효과를 냄 ...

배경 T-SQL에서 동적 쿼리를 실행하는 방법은 크게 두 가지가 있음 EXEC(@sql)로 문자열 그대로 실행 sp_executesql로 파라미터화된 쿼리 실행 핵심 차이는 실행 계획 재사용성과 파라미터 처리 방식에 있음 sp_executesql 기본 @stmt는 NVARCHAR 계열 입력 요구, N 접두 사용 권장 긴 문장은 nvarchar(max) 사용 권장, nvarchar(4000) 사용 시 4000자 제한 발생 VARCHAR로도 암시적 변환은 되지만 유니코드 손실 및 길이 이슈 가능, N’’ 사용 권장 예시 DECLARE @sql nvarchar(max) = N'SELECT 1' EXEC sp_executesql @sql파라미터 바인딩 예시 ...

개요 Django의 미들웨어는 요청과 응답을 전역적으로 가로채어 공통 로직을 삽입하는 경량 플러그인 시스템임. 입력 또는 출력의 전역 수정이 필요할 때 사용함 미들웨어 시스템과 순서 settings.py의 MIDDLEWARE 리스트에 등록된 항목을 기준으로 동작함. 요청 단계는 위에서 아래 순서로 통과, 응답 단계는 아래에서 위 순서로 역순 통과. 순서가 기능적 의존성과 직결되므로 중요함. 예시로 AuthenticationMiddleware는 세션을 읽기 때문에 SessionMiddleware 이후 배치 필요 커스텀 미들웨어 만들기 미들웨어는 함수 기반 또는 클래스 기반 중 하나로 작성. get_response를 호출하면 다음 미들웨어 혹은 최종 view로 제어가 넘어가며, 반환 이후 구간이 응답 후 처리 지점이 됨 ...

개요 C#에서 키와 값으로 데이터를 저장하는 대표 컬렉션은 Hashtable과 Dictionary 두 가지가 있음 표면적인 사용법은 비슷하지만 제네릭 지원 여부와 타입 처리 방식이 달라 성능과 안정성에서 차이 발생 핵심 차이와 간단 예시, 선택 기준 정리 핵심 차이 Hashtable 비제네릭 컬렉션, Key와 Value가 object로 저장됨 값 형식 저장 시 박싱 발생, 꺼낼 때 언박싱 또는 캐스팅 비용 발생 컴파일 타임 타입 체크 부재, 런타임 캐스팅 오류 위험 높음 레거시 코드와의 호환성은 높으나 일반적으로 권장되지 않음 Dictionary<TKey, TValue> ...

window load는 js css 이미지 등 모든 리소스 로드 완료 시점 발생 document DOMContentLoaded는 초기 DOM 파싱 완료 시점 발생, 외부 리소스 비대기 UI 바인딩 초기화는 DOMContentLoaded 이미지 크기 등 전체 리소스 필요 계산은 load body onload window.onload에 매핑됨 마지막 할당만 유효 덮어쓰기 방지용 addEventListener 권장 참고자료 https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload

개요 동일한 문제를 TypeORM의 JOIN으로 해결할 수도 있고, 각 테이블을 개별 조회한 뒤 코드에서 매핑할 수도 있음 어떤 접근이 더 효율적인지는 데이터 크기, 관계 복잡도, 인덱스 상태, 네트워크 제약, 성능 요구사항에 따라 달라짐 핵심 장단점과 선택 기준을 정리함 TypeORM에서 JOIN 사용하는 경우 장점 단일 쿼리로 필요한 데이터 수집 가능, 왕복 횟수 감소로 지연시간 이점 DB가 JOIN과 실행계획을 최적화하는 경우 비용 최소화 기대 1:N, N:M 같은 관계 질의를 쿼리로 명시적으로 표현 가능 필터링, 정렬, 그룹화 등 집계성 처리에서 DB 연산 활용 용이 페이지네이션과 함께 일관된 결과를 만들기 수월함 단점 ...

개요 목표 이벤트 루프, 스레드풀, 커널이 실제 CPU 코어와 어떻게 상호작용하는지 CPU 관점에서 명확히 이해하기 Node.js가 어디서 CPU를 쓰고 어디서 기다리는지 구분해야 병목을 제대로 잡을 수 있음 CPU 코어와 OS 스레드의 물리적 의미 하드웨어와 OS 레벨 정의를 먼저 정리 CPU 코어 1개 ≈ 특정 시점에 물리적으로 실행 가능한 OS 스레드 1개 스레드 OS 스케줄러가 CPU를 할당하는 최소 단위 동시성 vs 병렬성 코어 1개면 수백 스레드도 시분할로 번갈아 실행되는 동시성 코어 여러 개일 때만 실제 병렬 실행 가능 CPU 관점의 핵심 비용 ...

개요 좋은 시스템 설계는 복잡해 보이지 않고 긴 시간 동안 별문제 없이 돌아가는 상태를 말함 핵심은 상태를 최소화하고, 검증된 단순한 컴포넌트를 필요할 때만 조합하는 방향 과설계나 과도한 신기술 도입은 문제를 감추거나 유지보수 비용을 키우는 경향 최소 기능의 단순 구조에서 시작 후 관측 기반으로 점진 개선 권장 시스템 설계의 정의와 접근 소프트웨어 설계가 코드 조립이라면 시스템 설계는 서비스를 조합하는 일이라는 관점 주요 구성 요소 팔레트 앱 서버 데이터베이스 캐시 큐와 잡 러너 이벤트 버스 프록시와 게이트웨이 좋은 설계의 징후 ...

개념/배경 백프레셔 Backpressure는 소비자가 생산자의 처리 속도를 따라가지 못할 때, 소비자가 생산자의 속도를 조절하도록 피드백을 주는 흐름 제어 메커니즘을 의미함 직관적 비유로 좁은 깔때기 소비자에 높은 수압 생산자를 연결했을 때, 깔때기 내부에 물이 차며 더 유입되지 않도록 압력이 올라가거나 수도를 잠그라는 신호를 보내는 상황과 동일함 왜 중요한가 처리 속도 불균형이 누적되면 메모리 초과와 지연 폭증으로 이어짐 생산자 1000 req/s, 소비자 100 req/s 가정 매초 900개가 버퍼에 쌓여 메모리 증가, 결국 OOM 위험 큐 대기열이 길어져 tail-latency 증가, 사실상 영구 대기 상태 발생 가능 백프레셔는 이런 누적을 초기에 억제해 시스템 안정성 확보와 자원 보호에 기여함 핵심 개념과 정의 Producer: 데이터를 생성·전송하는 주체 Consumer: 데이터를 수신·처리하는 주체 Backpressure: 소비자가 처리 가능한 속도로 생산자에 역방향 피드백을 전달해 유량을 제어하는 행위 전략 축: 조절 Control, 버퍼링 Buffering, 드롭 Dropping 동작 원리/전략 A. 조절 Control/Throttling ...

개요 객체는 만능처럼 보이지만 모든 키-값 저장에 적합한 도구는 아님 키를 자주 추가·삭제하고 임의 키로 조회하는 해시맵 유사 패턴에서는 Map이 더 안전하고 일관된 성능을 제공함 중복 없는 집합 연산에는 Set이 자연스러운 선택지 언제 객체 대신 Map을 고려할까 키를 자주 추가·삭제하는 동적 해시맵 패턴 안전한 반복과 구조 분해가 필요한 경우 키의 삽입 순서 유지가 중요한 경우 비문자열 키가 필요한 경우 // 객체 기반 임의 키-값 해시맵 패턴은 delete에서 성능 불리할 수 있음 const mapOfThingsObj = {}; mapOfThingsObj[thing.id] = thing; delete mapOfThingsObj[thing.id]; // Map은 동적 추가·삭제에 최적화 const mapOfThings = new Map(); mapOfThings.set(thing.id, thing); mapOfThings.delete(thing.id);성능 배경 객체는 VM이 숨은 클래스/셰이프를 가정해 최적화하는 경향이 있어 구조가 변동하면 디옵티마이즈 유발 가능성 존재 Map은 해시맵 사용에 맞춰 키 추가·삭제가 빈번한 경우를 목표로 설계됨 마이크로벤치마크는 한계가 있으므로 실제 워크로드에서 측정 권장, 다만 Map이 해당 패턴에 맞춰 설계된 점은 문서로 확인 가능 ...