DewStream

※ SQL: ROLLUP. 안녕하세요. 듀스트림입니다. 오늘은 제가 애용하는 함수인 ROLLUP에 대한 내용입니다. 주로 수행 이력 건 수 체크, 오브젝트 집계, 유저 상태별 집계 등에 사용 중입니다.ROLLUP은 GROUP BY의 확장 기능으로, 계층적으로 집계 결과를 한 번에 구할 때 사용합니다.1. 기본 구문SELECT 컬럼1, 컬럼2, 집계함수FROM 테이블GROUP BY ROLLUP(컬럼1, 컬럼2); 먼저 컬럼1, 컬럼2 별 집계를 하고,그 다음 컬럼1 별 집계,마지막으로 전체 합계를 출력합니다.2. 매출 집계SELECT region, product, SUM(sales) AS total_salesFROM salesGROUP BY ROLLUP(region, product)ORDER BY regi..

※ SQL: Inline view. 안녕하세요. 듀스트림입니다. 기본기도 중요하죠.그래서 하나씩 작성해보려고 합니다. 오늘 주제는 인라인뷰입니다.인라인뷰(inline view)는 FROM 절 안에 작성된 서브쿼리를 의미합니다.1. 기본 예시SELECT emp.emp_id, emp.emp_name, dept.dept_nameFROM ( SELECT employee_id AS emp_id, employee_name AS emp_name, department_id FROM employees WHERE salary > 5000) empJOIN departments dept ON emp.department_id = dept.department_id;employees 테이블에서 급여가 5000 이..

※ SQL: Slow Query Patterns. 안녕하세요. 듀스트림입니다. 요즘 그냥 순간순간이 퀘스트의 연속입니다.정보보호 심사 시즌도 시작해서 하루에 n개씩 처리해도 퀘스트가 계속 쌓이고 있습니다.그래도 일할 때는 바쁜 게 재밌습니다. (물론 휴식도 매우 중요합니다.) 오늘 포스팅에서는 어렵지 않지만, 꼭 알아야 하는 슬로우 쿼리 패턴에 대해 정리해 보겠습니다.1. 데이터 접근 패턴 관련풀 테이블 스캔 (Full Table Scan)인덱스를 활용하지 못하고 전체 데이터를 읽는 경우.(예: WHERE 조건에 함수 적용, 타입 불일치, 와일드카드 %값)비효율적인 조인 (Join)큰 테이블끼리의 Nested Loop Join조인 조건에 인덱스가 없어 Hash Join → Disk Spill 발생.다대다..

※ SQL: CTE Optimization from the Standard SQL Perspective. 안녕하세요. 듀스트림입니다. 튜닝 대상을 식별하다 보면 CTE(Common Table Expression)가 많은 쿼리가 항상 존재합니다. 이유는 간단합니다. CTE가 많으면 최적화가 제대로 이루어지지 않는 경우가 많기 때문입니다.그래서 CTE를 단계적으로 하나씩 살펴봐야 하며, 특히 다음과 같은 패턴에서 성능 저하가 자주 발생합니다.정렬과 집계가 많은 경우 CTE 내부에서 ORDER BY나 SUM, COUNT 등의 집계 연산이 반복되면, 불필요한 임시 테이블 생성과 디스크 I/O가 증가합니다.타입 캐스트나 복잡한 표현식 사용 CAST나 함수 기반 연산은 기존 인덱스를 활용하지 못해 풀 스캔(seq ..

※ PostgreSQL: Skip Locked. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 동시성이 필요한 환경에서 Row Lock 회피로 사용하는 Skip Locked에 대한 내용입니다. 이 포스팅을 왜 하냐면 티켓팅 실패해서 합니다..1. SKIP LOCKED?SKIP LOCKED는 ANSI SQL 표준은 아니며 PostgreSQL, Oracle, MySQL 등에서 확장 기능으로 지원합니다. PostgreSQL에서 SELECT ... FOR UPDATE로 특정 행을 잠그면, 다른 세션은 그 행이 풀릴 때까지 기다립니다.하지만 SKIP LOCKED 옵션을 붙이면 이미 잠긴 행은 건너뛰고 바로 다음 후보 행을 반환합니다.즉 대기/충돌 없이 안전하게 다른 데이터를 처리할 수 있습니다. (이미 다른 트랜잭션..

※ PostgreSQL: Connection Pool. 안녕하세요. 듀스트림입니다. 제가 운영 중인 OLTP 시스템은 초당 5,000건 이상의 트랜잭션을 처리하고 있습니다. 이런 환경에서 클라이언트가 매번 DBMS에 직접 연결을 맺는다면, 쿼리 실행 이전에 커넥션 생성/해제 비용만으로도 막대한 리소스가 낭비될 수 있습니다.오늘 포스팅에서는 커넥션 풀이 필요한 이유와 실제로 어떤 비용이 줄어드는지를 간단히 정리해 보겠습니다.커넥션 풀이란?커넥션을 미리 만들어 두고 필요할 때 재사용하는 기술입니다.쉽게 말하면 상담 창구를 상시 열어두고, 고객이 왔을 때 열려 있는 빈 상담 창구에서 바로 상담을 시작하는 것과 같습니다.1. 커넥션을 맺는 비용PostgreSQL에서 클라이언트가 새로운 커넥션을 만들면 내부적으로..

※ SQL: Index. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 DBMS 옵티마이저는 '어떤 SQL에 인덱스가 필요하다고 판단하는지'와 '인덱스 최적화가 무엇인지'에 대해 정리한 이론적인 내용입니다. 한 번쯤 읽어두시면 도움이 될 거라고 확신합니다. (예시는 PostgreSQL이 대부분입니다.)1. 왜 인덱스는 빠를까요? - 비용모형 관점대부분의 RDBMS는 비용 기반 옵티마이저(CBO) 로 실행계획을 고릅니다.비용은 대략 “디스크 페이지 읽기 + CPU 비교·연산 + 정렬/조인”의 합산으로 추정합니다.PostgreSQL은 seq_page_cost·random_page_cost 등 상수에 기반해 페이지 접근 비용을 모델링하고, MySQL은 server_cost/engine_cost 테이블로 조정 가능..

※ IT: DBA? 안녕하세요. 듀스트림입니다. 이직하고 3주가 지났습니다. 현재 저는 규모가 꽤 크고 운영 복잡도가 매우 높은 시스템의 DBA로 근무하고 있습니다. 이직 당시 선택지는 세 곳 정도 있었는데,하나는 포지션이 제게 맞지 않았고,또 하나는 안정적인 시스템 + 업무 대부분을 하청에 맡기고 관리만 하는 구조였습니다.그리고 마지막 선택지가 지금 회사였습니다. 제가 이 회사를 선택한 가장 큰 이유는 인터뷰 당시 개선해야 할 것들이 정말 많이 보였고, 이러한 난제를 풀어보고 싶다는 도전 의식 때문이었습니다. (물론, 그 외에도 여러 가지 이유가 있었습니다.) 막상 현업에 들어와 보니 문제는 예상보다 훨씬 더 복잡하고 난해했습니다. 그래서 이번 포스팅에서는 DBA의 역할과 직무 그리고 업무 우선순위를 ..

※ PostgreSQL: LIKE vs ILIKE. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL에만 있는 문법인 ILIKE에 대한 내용입니다.1. ILIKE?ILIKE는 ANSI SQL 표준에는 존재하지 않는 PostgreSQL 확장 기능입니다.ILIKE는 LIKE와 동일한 패턴 매칭 문법을 사용하지만, 대소문자를 구분하지 않습니다(case-insenstive).간단하죠? 그냥 리눅스에서 grep 옵션 중 -i와 같은 기능입니다.2. 테스트▸ 테스트용 DDL, DML-- 테스트 테이블 생성CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT);-- 테스트 데이터 삽입INSERT INTO users (name) VALUES('John'..

※ Operator Class for Indexes in PostgreSQL. 안녕하세요. 듀스트림입니다. 운영 환경에서는 복잡한 비즈니스 로직이 들어간 SQL을 즉시 최적화해서 반영하기 어려울 때가 많습니다.그다음으로 효과적인 방법은 인덱스를 통한 데이터 액세스 최적화입니다. 그래서 우리는 인덱스에 대해 잘 알아야합니다. 오늘 포스팅은 PostgreSQL의 Index Operator Class에 대한 내용입니다. 여담으로 MySQL과 비교해 보자면, MySQL에는 PostgreSQL의 연산자 클래스와 같은 개념이 없습니다.대신 인덱스 생성 시 데이터 타입 + 인덱스 종류 + Collation 조합으로 동작 방식을 결정하며, 별도의 연산자 집합을 따로 정의하는 구조가 아닙니다. + 메커니즘 비교표구분Po..