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 버전업을 하면서 이전에는 단점이라 꼽던 많은 부분들이 개선이 되었다. (그만큼 하위 호환이 안 되는게 많다고 한다.) 그 부분들은 고려해서 차이를 찾아볼 필요가 있다. 다른 블로그들의 비교 글들이 이 부분을 ..
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천만 개의 데이터 분포를 가진다. 이 둘을 비교할 때 상대적으로 주민등록번호의 카디널리티가 높다. 위와 같이 직관적으로 컬럼의 카디널리티를 따져볼 수 있지만 실제 테이블의 컬럼들은 다양하게 구성되어있기 때문에 직접 구해보는 것이 좋다. 카..
Postgresql 테스트를 위하여 충분한 운영 데이터가 있다면 좋겠지만 데이터가 많지 않을수도 있고 데이터 접근이 어려울 수도 있고 실제로 데이터 보안상 마음대로 가져다 테스트 해볼 수 없는 부분이기에 테스트는 테스트 데이터를 활용하여 하는 것이 맞다고 본다. 지극히 개인 경험으로 100만 건부터 1억건 이상의 테이블 모두 만나봤지만, 확실히 100만에서 1000만으로 뛸때, 1000만에서 1억으로 뛸때 확실히 성능상 이슈가 생긴다. 또, 1개의 테이블이 인덱스 튜닝으로 적절하게 유지되는 수준은 1000만 이내가 적정한 것으로 보인다. 더 데이터가 많아진다면 인덱스 튜닝 뿐만 아니라 좀 더 샤딩(Sharding), 파티셔닝(Partitioning)과 같은 고급 기술이 필요해보인다. 여튼, 최소 100만..
