Logic in Code,
Freedom in Travel.

PostgreSQL 를 사용하다 보면 어느 순간 디스크가 기하급수적으로 늘어난다.DELETE / UPDATE 가 지속적으로 발생하면서 디스크는 크게 줄지 않고, 비용은 점점 올라간다.뿐만 아니라 쿼리 성능 저하, 인덱스 비대화의 문제로 데이터베이스의 성능이 점차 떨어진다.Auto vacuum이 안 돌면 생기는 성능 이슈1. 쿼리 성능 저하UPDATE, DELETE가 많아지면 dead tuples 이 쌓인다.PostgreSQL은 MVCC 방식이라, 삭제된 데이터도 실제로는 지워지지 않고 남아 있는데 이걸 지워주는 게 vacuum이다.vacuum 은 백그라운드에서 autovacuum 이 실행되며, 쿼리로 명령어를 작성할 수 도 있다.이것이 제대로 돌지 않으면 테이블이 점점 무거워진다. 이 과정으로 전체 테이..

Postgres에서 쿼리 실행 계획(Explain Query Plan)을 실행했을 때 Nested Loop 에 대해 알게 되었지만, 제대로 정리해본적은 없었기에 SQL의 3가지 JOIN 알고리즘을 정리해보려 한다. JOIN 알고리즘의 종류 Nested Loop Sort/Merge HashRDBMS 에 따른 알고리즘 지원 현황 Oracle : 3가지 모두 지원 MySQL : Nested Loop 만 지원 Postgres : 3가지 모두 지원 External Table 과 Internal TableSELECT * FROM table1 t1 INNER JOIN table2 t2 on t1.id = t2.id;External Table (Drive Table)JOIN할 때 기준이 되는 테이블이며, 위 SQ..

우리는 '무엇(What)'을 요구하고, DB는 '어떻게(How)'를 결정한다학교 다니던 시절부터 2년차가 되었던 시절에는 데이터베이스는 일종의 '블랙박스' 였다. SQL 문법에 맞춰 데이터를 달라고 요청하면, DB는 알아서 결과를 반환해줬다. 하지만 트래픽이 몰리고 데이터가 수천만 건을 넘어가는 시나리오를 만들어보니 직접 느끼게되었다. "같은 결과를 내는 SQL이라도, 어떻게 수행하느냐에 따라 성능은 매우 크게 차이가 난다."SQL은 비절차적 언어이다. "데이터를 줘"라고 말할 뿐, "어떤 인덱스를 타고, 어떤 순서로 조인해서 가져와"라고는 명시하지 않는다. '어떻게(How)'를 결정하는 것이 옵티마이저(Optimizer)이다. 시나리오를 만들고 테스트를 해가며 슬로우 쿼리와 싸우며 알게 된 옵티마이저의..

인덱스는 테이블이나 뷰에서 행의 검색 속도를 높일 수 있다. 클러스터드 인덱스클러스터형 인덱스는 해당 키 값을 기반으로 테이블이나 뷰의 데이터 로우를 정렬하고 저정한다.이러한 키 값은 인덱스 정의에 포함된 컬럼이다. 데이터 로우 자체는 한 가지 순서로만 저장될 수 있으므로 테이블당 클러스터형 인덱스는 하나만 존재할 수 있다. 때문에 일반적으로는 PK 또는 unique not null 을 사용한다.테이블의 데이터 로우가 정렬된 순서로 저장될 때만 테이블에 클러스터형 인덱스가 포함된다. 테이블에 클러스터형 인덱스가 있는 경우 테이블을 클러스터형 테이블이라고 한다. 테이블에 클러스터형 인덱스가 없는 경우 해당 데이터 로우는 힙이라는 순서가 지정되지 않은 구조에 저장된다.비클러스터형 인덱스비클러스터형 인덱스에는..

도서관에서 책을 찾는 두가지 방법인덱스라는 것을 이해할 때 "인덱스는 책 뒤에 있는 색인 같은 거야"라고 이해를 했다. 하지만 실무에서 대용량 트래픽을 처리하는 환경에서는 인덱스는 색인 그 이상이었다. 데이터베이스에서 데이터를 찾는 방법은 두가지가 있다. Full Table Scan: 책의 처음부터 끝까지 한 페이지씩 다 넘겨보며 찾기.Index Seek: 색인을 통해 몇 페이지에 있는지 확인하고 바로 펼치기.데이터가 수백만 건이라면 1번은 노답이다. 그래서 2번이 핵심 포인트인 클러스터드(Clustered), 세컨더리(Secondary), 그리고 튜닝의 끝판왕인 커버링(Covering) 인덱스에 대해 정리했다. 1. 클러스터드 인덱스 (Clustered Index)"책 그 자체의 정렬 순서"클러스터드 ..

서버를 운영하다 보면 어플리케이션, 네트워크, DB 등에서 장애가 발생할 수 있다. 이때 장애의 원인을 파악하기 위해서는 로그를 확인하는 것은 매우 중요하다.Laravel 을 개발했을 당시 Laravel 로그을 보는것도 문제 해결에 도움이 되었지만, Apache 로그도 무시할 수 없었다. 때문에 로그의 중요성을 알게 되었다.또한 Express 로 개발된 서비스에 장애가 발생했었는데 async/await 누락으로 Express 의 로그로는 트래킹을 할 수 없어 Postgres 로그를 확인하여 문제를 해결했었다. 아래는 MySQL 운영시 로그 정보를 저장하는 방법이다.MySQL 의 로그 종류에러 로그(Error Log)제너럴 로그(General Log - MySQL Command History Log)슬로우..