1. MVCC => DEAD_TUPLE => BLOAT postgreSQL은 MVCC(다중버전 동시성 제어)의 이점을 위해 'UPDATE'와 'DELETE' 수행 후 이전 데이터를 즉시 제거하지 않는다. 즉시 제거하지 않은 이전 데이터를 'Dead Tuple'이라고 말한다. 그로 인해, Table Bloat(테이블 팽창), Btree Index Bloat(인덱스 팽창)가 발생할 수 있다. 이는 불필요한 I/O의 증가와 부적절한 인덱싱을 초래한다. 1-1. 어떻게 확인하는가? 🔎 팽창(BLOAT) 확인 : Githup 오픈소스[⭐1.1k] (https://github.com/pgexperts/pgx_scripts/tree/master/bloat) 튜플 확인 SELECT relname, n_dead_tup,..
목적 DISK IO 를 최소화함으로써 IO 성능을 향상시킵니다. 1) 매우 큰 (수십, 수백 GB) 버퍼를 빠르게 액세스해야 합니다. 2) 많은 사용자가 동시에 접근할 때 경합을 최소화해야 합니다. 3) 자주 사용되는 블록은 최대한 오랫동안 버퍼 내에 있어야 합니다. 권장하는 값 공식문서의 내용을 의역해보았습니다. PostgreSQL 서버의 권장 shared_buffers 값은 시스템 메모리의 25%입니다. PostgreSQL 서버는 운영 체제 캐시에 의존합니다. 그래서 RAM의 40% 이상 할당하지 않는 것이 좋습니다. 토픽1. shared_buffers DB 파라미터 기본값이 Aurora PostgreSQL > RDS PostgreSQL인 이유는 무엇입니까? 위 [권장하는 값] 내용을 바탕으로 RDS..
내가 직접 만든 테이블은 아니지만 postgreSQL에 내장되어있는 테이블이 존재한다. 실제로 잘 활용하는 쿼리를 사례와 함께 적어보려고 한다. 테이블 인덱스 확인 실행계획을 볼 때 인덱스를 아예 타고 있지 않거나 잘못된 인덱스를 타고 있음을 확인할 수 있다. 이 떄 보통 테이블에 어떤 인덱스가 있는지를 보고 의도하는 인덱스를 탈 수 있게 쿼리를 튜닝해준다. SELECT * FROM pg_indexes WHERE tablename = '소문자 테이블 명'; 현재 테이블별 전체 카운트 확인 테이블 별로 전체 카운트를 수시로 확인하면 얼마나 데이터 성장세가 가파른지, 어떻게 인프라를 대비해야하는지, 어떻게 데이터를 관리하는게 더 효율적인지 고민해볼 수 있다. 테이블별로 count 쿼리를 직접 때려도 되지만 ..
둘 다 사용경험은 있는데, 사용 경험상으로는 큰 차이가 있다고 보기는 어려웠다. 구글링을 통해 차이를 찾아보면 좋지않을까 하여 이곳 저곳 뒤져보았고, 같은 관계형 데이터베이스(RDBMS)로서 어떤 차이가 있는 것인지 정리해보려 한다! 👨💻 0. 소프트웨어는 버전이 몇 인지가 중요하다. 항상 느끼지만 소프트웨어는 계속 발전하고, 부족한 부분들이 보완 업그레이드되는 방향으로 흘러간다. 그래서 이전에는 단점이었던 부분들이 업그레이드를 통해서 좋아지는 경우가 많다. MySQL의 경우에는 2020년 8.0 버전업을 하면서 이전에는 단점이라 꼽던 많은 부분들이 개선이 되었다. (그만큼 하위 호환이 안 되는게 많다고 한다.) 그 부분들은 고려해서 차이를 찾아볼 필요가 있다. 다른 블로그들의 비교 글들이 이 부분을 ..
2페이징 스크롤이 잦은 기능의 경우, 써보면 좋을 법한 아이디어가 있어 공유해보려 한다. 보통 스크롤 페이징을 구현해놓더라도 1페이징에 머무는 기능이 대부분이다. 예를 들어, 채팅 메시지 목록을 1페이징으로 조회한다고 했을 때, 메시지를 스크롤로 올려 이전 메시지를 확인하는 경우보다 1페이징에서 머물다 바로 메시지를 보내는 경우가 많다. (아니라고 하더라도 가정해보자) 하지만, 페이스북의 뉴스피드 타임라인의 경우 첫 페이징에 머물기보다는 2페이징, 3페이징 스크롤하여 나아갈 가능성이 많다. 이러한 경우 물론, OFFSET 페이징보다 커서 페이징이 이점이겠지만, 때에 따라 커서 페이징이 불가능한 경우가 있을 수도 있고, 커서가 2개 이상 존재하여 OFFSET 보다 속도가 나지 않는 경우가 있다. 이럴 때,..
1. 카운트 쿼리에 사용되는 데이터가 null 일 경우 건수에 포함되지 않는다. 이 점을 활용하여 (case when ~ then 1 else null end) 활용 필터링이 가능하다. count(1), count(*), count(column) 모두 실행계획과 실행시간이 동일하니, column 쓸 때만 null로 개수 빠지는지 확인만 하면 된다. --null 상관없이 전체 건수를 셈 SELECT count(*) FROM board; SELECT count(1) FROM board; --contents 중 null 인 데이터를 빼고 셈 SELECT count(title) FROM board; --contents 중 null 인 데이터를 빼고 중복 제거하여 셈 SELECT count(distinct tit..
재귀쿼리를 쓸 경우가 종종 있는데 나같은 경우에는 조직도 트리와 폴더 트리에 사용해본 적이 있다. 간단하게 사용법을 설명하고 실제 케이스에서 엄청난 오류?를 만들어냈던 경험을 공유해보려고 한다. 0. 재귀쿼리를 테스트해보기 위한 사전 작업 조직도가 제일 무난할 것 같아 심플한 데이터를 준비해보았다. CREATE TABLE division ( division_code character varying(20) NOT NULL PRIMARY KEY, division_name character varying(20) NOT NULL, upper_division_code character varying(20) NOT NULL ); INSERT INTO division VALUES ('develop_division',..
카디널리티(Cardinality)란 흔히 나와있는 설명을 참고하면 컬럼의 중복된 수치를 말한다. 중복된 수치가 높으면 카디널리티가 높은 것 같지만 반대로 해석해야 해서 조금 헷갈리는데 그래서 난 카디널리티를 분포도로 이해하고 있다. 얼마나 데이터가 분포하였는가에 따라 넓게 분포되었다면 카디널리티가 높고, 아니라면 낮다. 예를 들어, 성별은 남성과 여성이라는 2개의 데이터 분포를 가질 수 있고, 주민등록번호는 대한민국 국민이 모두 고유하게 하나씩 가지고 있기 때문에 약 5천만 개의 데이터 분포를 가진다. 이 둘을 비교할 때 상대적으로 주민등록번호의 카디널리티가 높다. 위와 같이 직관적으로 컬럼의 카디널리티를 따져볼 수 있지만 실제 테이블의 컬럼들은 다양하게 구성되어있기 때문에 직접 구해보는 것이 좋다. 카..
