DewStream

※ RDBMS: FOREIGN KEY. 안녕하세요. 듀스트림입니다. 저는 이직하고 계속 야근과 주말 작업이 너무 많아서 지쳐가는 중입니다.. (조금 편한 자리로 갈 걸 그랬나 싶기도 해요..) 오늘 포스팅은 RDBMS를 사용한다면 꼭 알아야 하는 외래키(FOREIGN KEY)에 대한 내용입니다. 외래키는 그냥 FK 한 줄 추가하는 기능이 아니라,데이터 모델의 품질과 애플리케이션 안정성, 운영상의 성능과 락 구조까지 모두 연결되는 핵심 요소입니다. 1. RDBMS에서 왜 외래키가 중요할까요?관계형 DB에서 관계(relation)를 실제로 강제하는 장치가 외래키(FOREIGN KEY, FK) 입니다.부모(Parent) 테이블: 기준(참조 대상)이 되는 테이블 (보통 PK/UK를 가진 쪽)자식(Child) 테..

※ SQL: Window Function Syntax Structure. 안녕하세요. 듀스트림입니다. 또다시 월요일입니다. 오늘 포스팅은 SQL을 다룬다면, 필수적으로 이해하고 있어야 하는 윈도우 함수의 문법 구조에 대해 알아보겠습니다.1. 윈도우 함수의 기본 문법 구조Window-function ( [expression] ) OVER ( [PARTITION BY ...] [ORDER BY ...] [ROWS | RANGE ...]) 한 줄로 표현하면 아래와 같은 구조로 되어있습니다.윈도우 함수 = 함수 + OVER(윈도우 정의)윈도우 함수 자체: SUM(), AVG(), ROW_NUMBER(), LAG(), LEAD() 등OVER() 안의 윈도우 정의: 어떤 범위(window..

※ PostgreSQL: Analysis of SELECT Efficiency. 안녕하세요. 듀스트림입니다. 대부분의 서비스에서는 SELECT(Read) 비율이 압도적으로 많습니다. 그렇다면 여기서 의문이 생기겠죠.인덱스를 타긴 타는데, 정말 효율적으로 동작하고 있을까?어떤 테이블과 어떤 쿼리가 Heap 접근을 많이 유발 중일까?Visibility Map, Index-only Scan, 통계 뷰 지표들은 서로 어떻게 연결되는 거지? 오늘 포스팅에서는 로그와 모니터링에 의존하지 않고 시스템 뷰와 통계 지표만으로 SELECT 효율을 해석하는 방법을 알려드리겠습니다.1. SELECT 효율?서비스 쿼리는 기본적으로 응답 시간이 빨라야합니다. SELECT 효율 분석은 여기서 한 뎁스 더 들어가서 다음 내용을 정량..

※ PostgreSQL: DISTINCT ON. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL 고유 확장 기능인 DISTINCT ON에 대한 내용입니다. 알아두면 꽤 편합니다.DISTINCT ON은 표준 ANSI SQL에 속하지 않으며, PostgreSQL 고유 확장 기능입니다.표준 방식은 ROW_NUMBER()를 사용합니다.표준 방식SELECT user_id, event_time, statusFROM ( SELECT user_id, event_time, status, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) AS rn FROM user_events) tWHERE rn = 1; DISTI..

※ SQL: Row Stream. 안녕하세요. 듀스트림입니다. 오늘은 SQL 엔진에서 하는 행 스트림 처리가 무엇인지에 대해 알아보겠습니다.카테고리를 DBMS에 넣을지 SQL에 넣을지 고민했지만, 그냥 SQL에 넣기로 했습니다.글을 작성하다 보면 내용보다는 의외로 이런 부분에서 로딩이 더 걸리는 것 같습니다. SQL 엔진에서 "행 스트림(row stream)" 이란 표현은 테이블의 모든 데이터를 한꺼번에 메모리에 올려놓지 않고, 한 행(row)씩(또는 일정한 묶음 단위로) 순차적으로 읽고 전달하는 처리 방식을 말합니다.즉, LATERAL이나 Nested Loop 같은 연산이 "행 스트림 기반(row stream based)"으로 동작한다는 건 아래처럼 이해하시면 됩니다.1. 행 스트림 처리?SQL의 실행..

※ Linux: Script. 안녕하세요. 듀스트림입니다. 여러분을 스스로를 믿으십니까?좋습니다. 그럼 이제 진짜 믿을만한지 기록을 한번 해보도록 하겠습니다.script는 터미널에서 일어난 모든 출력(필요 시 입력까지)을 파일로 기록합니다.기록은 세션 종료 시에 완성되며,기록 시 타이밍 정보를 추가하면 scriptreplay로 원래 리듬 그대로 재생할 수 있습니다. • 대부분의 배포판에 기본으로 제공합니다.(util-linux 패키지)• man script, man scriptreplay로 매뉴얼을 확인하시면 됩니다.사용 방법cd /tmp# 기록 시작script -q -f -t 2> timing.log session.log# 명령 실행echo "[LAB1] start"datefor i in 1 2 3; ..

※ PostgreSQL: Streaming-replication Lag. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL에서 스트리밍 복제 지연 발생 시 분석 방법에 대한 내용입니다. 결론부터 말씀드리면 주로 발생하는 지연 원인은 경험상 아래 정도가 있는 것 같습니다.대부분 비동기 복제 정책 문제 (95% 이상)배치, Autovacuum, 인덱스 재작성 등 피크 타임에 WAL 폭증너무 잦은 체크포인트Primary와 Standby의 스토리지 차이(NVME, SSD, HDD)네트워크 지터1. 어디에서 느린건지 구분▸ 복제 동작은 크게 아래 3단계로 볼 수 있습니다:WAL 생성 → 전송/수신 → 재생(리플레이)→ 이 중 어디가 느린지에 따라 원인이 갈립니다. 1.1 Primary에서 확인-- 세..

※ PostgreSQL: never executed. 안녕하세요. 듀스트림입니다. PostgreSQL 실행계획을 보면 어떤 노드 옆에 "never executed"라는 문구가 표시될 때가 있습니다.이건 꽤 중요한 의미를 가지는 지표라서 오늘 포스팅에서 한번 설명드리겠습니다.1. never executed의 의미never executed는 해당 실행 계획 노드(Plan Node)가 실제 실행 중 단 한 번도 수행되지 않았음을 의미합니다.즉, 실행 계획 상으로는 존재하지만, 런타임 시 조건문이나 상위 노드의 제어 흐름 때문에 해당 노드가 호출되지 않은 것입니다. 예를 들어:EXPLAIN (ANALYZE, BUFFERS)SELECT *FROM orders oWHERE o.id IN ( SELECT id FR..

※ PostgreSQL: ctid. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 지난 포스팅과 연계되는 내용으로 시스템 컬럼인 ctid에 대해 알아보겠습니다. 5.6. System Columns5.6. System Columns # Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot …www.postgresql.org1. ctid?ctid는 PostgreSQL의 각 행(Row) 에 대해 자동으로 부여되는 물리적 위치 식별자입니다.ctid는 해당 튜플이 테이블 파일 내에서 어느 블록의 몇 번째에 저장되어 있는지를 나타내는 시스템 컬럼으로, 다음과 같은 형식을 ..

※ PostgreSQL: Heap Table Structure. 안녕하세요. 듀스트림입니다. 오늘은 또 슥 한 번 읽어두면 좋은 내용인 PostgreSQL의 기본 저장 구조인 힙 테이블에 대한 내용입니다. PostgreSQL의 힙(Heap) 테이블은 PostgreSQL의 기본 저장 구조입니다.힙 테이블은 인덱스 없이 순서 없이 데이터를 저장하며,PostgreSQL의 MVCC 구현에 매우 밀접하게 관련되어 있습니다.1. 힙 테이블의 계층 구조대충 이렇게 생겼습니다.Table (Relation)└── Data File (heap) └── Page (Block, 8KB) └── Line Pointer (Item Identifier) └── Tuple (Row)2. Data..