Database

개념 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로 정렬하면 사실상 생성 시간순으로 정렬하는 효과를 냄 ...

배경 ‘테이블에 1억 건 데이터가 있으면 조회가 느리다’는 말은 항상 참이 아님. 성능 저하는 데이터 양 자체보다 ‘어떤 쿼리를 어떤 인덱스로 어떻게 읽는가’의 문제일 때가 많음. 이 글에서는 대용량 테이블에서 조회 성능이 저하되는 주된 원인을 진단하고, 각 상황에 맞는 해결 전략을 정리함. 느린 쿼리의 대표적인 원인 대용량 테이블에서 쿼리가 느리다면 대부분 아래 원인 중 하나에 해당함. Full Table Scan: WHERE나 ORDER BY 절이 인덱스를 효과적으로 사용하지 못해 테이블 전체를 스캔 낮은 인덱스 선택도: 인덱스를 사용하더라도, status='ACTIVE'처럼 대부분의 행이 해당하는 조건이라 읽어야 할 데이터가 너무 많음 메모리 외부 정렬/그룹화: 정렬이나 그룹화할 데이터가 메모리 용량을 초과해 디스크 I/O가 발생하는 경우 (External Sort, Hash Aggregate) 비효율적인 조인: 조인 순서가 잘못되었거나 조인 키에 인덱스가 없어 비효율적으로 동작 OFFSET 기반 페이지네이션: OFFSET 1000000처럼 앞부분의 데이터를 모두 읽고 버리는 비효율적인 방식 기타 운영 이슈: 특정 행에 대한 동시 접근으로 인한 핫스팟(Hotspot), 잠금(Lock) 경합, 디스크 IOPS 부족, 캐시 미스 등 결론적으로 1억 건 테이블이라도 쿼리가 인덱스를 통해 소수의 행만 접근(Index Seek)하고 짧은 범위만 스캔(Range Scan)한다면 응답 속도는 충분히 빠를 수 있음. ...

개념: Soft Delete와 Hard Delete Soft Delete는 데이터를 물리적으로 삭제하지 않고, 삭제된 것처럼 ‘표시’만 하는 전략입니다. DELETE 쿼리로 데이터를 완전히 제거하는 물리 삭제(Hard Delete)와 달리, Soft Delete는 UPDATE 쿼리를 사용해 특정 컬럼 값을 변경합니다. deleted_at - 데이터가 삭제된 시점을 타임스탬프로 기록 is_deleted - 삭제 여부를 나타내는 플래그(flag)를 true로 변경 요약하면 Soft Delete는 ‘삭제’를 데이터 파괴(Destroy)가 아닌 상태 변경(State Change)으로 다루는 접근법이며, Hard Delete는 데이터를 영구적으로 제거하는 것을 목적으로 합니다. Soft Delete의 장점과 목적 Soft Delete를 도입하면 다음과 같은 이점을 얻을 수 있습니다. ...

들어가며 DynamoDB의 UpdateItem API는 카운터 증감이나 상태 변경 같은 ‘읽기-수정-쓰기’ 연산을 단 한 번의 호출로 실행합니다. 이때 여러 클라이언트가 동시에 같은 아이템을 수정하려 할 때, 어떻게 데이터의 정합성과 원자성(Atomicity)을 보장하는지 그 내부 동작 원리가 궁금할 수 있습니다. 결론부터 말하면, 특정 아이템이 속한 파티션의 모든 쓰기 요청을 단일 리더(Leader) 노드가 직렬화(Serialize)하여 순차 처리하기 때문입니다. 이 구조 덕분에 동시 쓰기 요청이 서로를 덮어쓰거나 유실되지 않고 안전하게 처리됩니다. 핵심 원리 요약 개념 설명 단일 파티션 리더 특정 파티션 키에 대한 모든 쓰기 요청은 하나의 리더 노드가 전담함 쓰기 요청 직렬화 리더는 수신한 쓰기 요청을 큐처럼 순서대로 하나씩 처리함 동기식 복제 리더는 변경 사항을 다수의 팔로워 노드에 복제하고, 확인 응답을 받아야 최종 커밋함 원자성 보장 이 세 가지 요소가 결합되어 UpdateItem 연산의 원자성을 보장함 원자성 보장 메커니즘 상세 1. 파티션 기반 분산과 리더 선정 DynamoDB 테이블 데이터는 파티션 키(Partition Key)를 기준으로 여러 파티션에 분산 저장됨 각 파티션은 3개의 복제본(Replica)으로 구성되며, 서로 다른 가용 영역(AZ)에 배치됨 복제본 중 하나는 리더(Leader)가 되고 나머지는 팔로워(Follower) 역할을 수행함 2. 단일 리더로의 쓰기 요청 라우팅 클라이언트의 UpdateItem 요청은 먼저 DynamoDB 요청 라우터(Request Router)에 도달함 요청 라우터는 아이템의 파티션 키를 해싱하여 데이터가 속한 파티션을 찾고, 해당 파티션의 단일 리더 노드로 요청을 전달함 따라서 같은 아이템에 대한 모든 쓰기 요청은 항상 동일한 리더 노드가 처리하게 됨 3. 리더 노드의 쓰기 요청 직렬화 원자성 보장의 핵심으로, 리더 노드는 동시에 도착한 여러 쓰기 요청을 병렬로 처리하지 않음 대신, 요청을 내부적으로 큐에 넣고 하나씩 순서대로(Serially) 처리함. 이는 아이템에 대한 비관적 락(Pessimistic Lock)과 유사한 효과를 가져옴 예를 들어, 두 요청이 동시에 SET counter = counter + 1을 호출하면, 리더는 첫 번째 요청의 ‘읽기-수정-쓰기’ 사이클을 완전히 마친 후에야 두 번째 요청을 시작함 이로 인해 두 번째 요청은 첫 번째 요청이 변경한 최신 값을 읽게 되어 데이터 정합성이 깨지지 않음 4. 동기 복제를 통한 내구성 확보 리더는 쓰기 연산을 완료한 후, 변경 사항을 팔로워 노드들에게 **동기적으로 복제(Synchronous Replication)**함 리더는 쿼럼(Quorum), 즉 과반수 이상의 복제본에 데이터가 성공적으로 기록되었음을 확인한 뒤에 클라이언트에게 성공(200 OK) 응답을 보냄 이 과정 덕분에 UpdateItem 연산은 ‘전부 성공’하거나 ‘전부 실패’하는 원자적 특성을 가지며, 리더 장애 시에도 데이터 유실을 방지함 동시 업데이트 처리 과정 예시 두 클라이언트(A, B)가 counter 값이 0인 아이템에 SET counter = counter + 1 요청을 동시에 보냈다고 가정해 보겠습니다. ...

배경 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파라미터 바인딩 예시 ...

개념/배경 운영 중 특정 데이터베이스에서 대기나 블로킹이 의심될 때, 현재 걸린 트랜잭션 락을 직접 확인하는 것이 우선임 SQL Server의 동적 관리 뷰 sys.dm_tran_locks는 활성 잠금 정보를 제공하며 데이터베이스 단위로 필터링 가능 사용법/예시 아래 쿼리로 대상 DB에 설정된 잠금 목록 조회 SELECT * FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID('MY_DB')요점 컬럼 참고 request_session_id: 잠금 보유 또는 대기 세션 ID resource_type, resource_associated_entity_id: 잠금 대상 리소스 식별 request_mode: 잠금 모드 (S, X 등) request_status: GRANT 또는 WAIT 상태 추가 확인 포인트 블로킹 체인 파악 필요 시 sys.dm_exec_requests, sys.dm_os_waiting_tasks와 조합하여 대기 중인 세션과 차단 세션 상관분석 권장 식별된 차단 세션은 영향 분석 후 종료 여부 판단 ...

개요 MERGE는 소스 테이블과 타깃 테이블을 조인한 결과를 기준으로 삽입·갱신·삭제를 한 번에 처리하는 집합 기반 연산 여러 개의 개별 DML을 하나로 합쳐 실행 횟수와 스캔 비용을 줄이는 것이 목적 테이블 간 차이를 기준으로 동기화가 필요한 배치나 증분 적재 시 유용 핵심 개념 타깃 대상과 소스 입력의 조인 조건 정의 WHEN MATCHED 조건에서 UPDATE 또는 DELETE 수행 WHEN NOT MATCHED BY TARGET 조건에서 타깃에 INSERT 수행 WHEN NOT MATCHED BY SOURCE 조건에서 소스에 없는 타깃 행을 DELETE 등으로 정리하는 패턴 지원 하나의 문장으로 트랜잭션 일관성 유지가 쉬움 기본 문법 필수 요소만 요약 ...

개념/배경 결론부터 말하면 가능함 Foreign Key 컬럼의 NULL 허용 여부는 해당 컬럼의 NULL 혹은 NOT NULL 제약으로 결정됨 FK 제약은 NULL이 아닌 값만 검증하므로 값이 NULL인 경우 참조 무결성 검사를 생략함 컬럼이 NOT NULL이면 NULL 저장 불가 컬럼이 NULL 허용이면 NULL 저장 가능 핵심 개념 FK 제약은 입력값이 존재할 때만 참조 대상 테이블에 키가 있는지 검사 NULL은 미지정 상태로 간주되어 검증 대상 아님 대부분의 RDBMS에서 기본은 NULL 허용 컬럼이며, 명시적으로 NOT NULL을 지정해야 함 동작 원리 INSERT 또는 UPDATE 시 FK 컬럼이 NULL이면 무결성 검사 스킵 값이 존재하면 참조 테이블의 대상 키 존재 여부 검사 복합 FK의 경우 참조 컬럼 중 하나라도 NULL이면 전체 FK 검사를 생략하는 동작이 일반적임 간단 예시 CREATE TABLE parent ( id INT PRIMARY KEY ); CREATE TABLE child ( parent_id INT, FOREIGN KEY (parent_id) REFERENCES parent(id) ); child.parent_id는 기본적으로 NULL 허용 상태 parent_id에 NULL을 넣어도 FK 위반 아님 parent_id에 NOT NULL을 추가하면 parent에 존재하는 id만 허용됨 주의 사항 ON DELETE SET NULL을 사용할 경우 FK 컬럼이 NULL 허용이어야 함 FK 컬럼 인덱스는 필수는 아니나 삭제·업데이트 시 성능과 잠금 범위 측면에서 권장 관계가 필수라면 애플리케이션 규칙이 아닌 스키마에서 NOT NULL로 모델링하는 편이 안전함 마무리 FK 컬럼은 NULL 허용 설정이면 NULL을 저장할 수 있으며, 이 경우 FK 검사는 수행되지 않음 NULL을 금지하고 참조 무결성을 강제하려면 NOT NULL을 함께 적용하면 됨 ...

개념/배경 CTE는 WITH로 정의하는 이름 있는 임시 결과셋 바로 다음 한 개 DML에서만 참조 가능하며 실행이 끝나면 범위 소멸 가독성 향상과 쿼리 구조 분리에 유용함 사용법 WITH cte_name (col1, col2) AS ( SELECT ... ) DML필요 시 컬럼 목록 생략 가능하나 명시를 권장 주의사항 일부 DBMS에서는 배치 내에서 CTE 앞에 오는 쿼리를 세미콜론으로 종료 필요 CTE 범위는 바로 뒤 한 개 DML로 한정됨 복잡한 쿼리에서 과도한 중첩 사용은 계획 복잡도 증가 가능 참고자료 https://s2choco.tistory.com/34 https://learn.microsoft.com/sql/t-sql/queries/with-common-table-expression-transact-sql

개요 nvarchar와 nchar를 사용할 때 n이 곧 문자 개수라고 가정하는 경우가 많음 하지만 SQL Server에서 nchar(n), nvarchar(n)의 n은 문자 개수가 아니라 2바이트 단위의 길이, 즉 바이트 페어(byte-pair) 개수로 정의됨 문자 집합 범위에 따라 한 문자가 1개 혹은 2개의 바이트 페어를 사용할 수 있어 저장 가능한 문자의 실제 개수는 달라짐 핵심 개념과 정의 nchar(n), nvarchar(n)의 n은 0~4000 바이트 페어 범위의 길이 의미 하나의 바이트 페어는 2바이트로, 내부적으로 UTF-16 코드 유닛 단위로 이해 가능 유니코드 BMP 범위(0~65,535) 문자는 보통 1 바이트 페어 사용 보조 평면 범위(65,536~1,114,111) 문자는 서러게이트 페어로 2 바이트 페어 사용 따라서 n이 문자의 최대 개수를 보장하지 않음 char(n), varchar(n)은 n이 바이트 수 의미라는 점에서 유사한 맥락이나, nvarchar/nchar는 바이트 페어 기준이라는 차이 존재 추가 기본값 규칙 ...