데이터 레이아웃 및 액세스 패턴 모범 사례

데이터베이스 부하를 가중시키는 데이터 액세스 및 업데이트 패턴을 설명하고, 이를 피하기 위한 대안적 권장 사항을 설명합니다.

특정 데이터 액세스 패턴, 특히 데이터 업데이트 패턴은 데이터베이스에 가해지는 부하를 악화시킬 수 있습니다. 가능하면 이러한 패턴을 피하세요. 이 문서는 피해야 할 패턴과 그에 대한 대안 권장 사항을 나열합니다. 고빈도 업데이트, 특히 동일한 행에 대한 업데이트 # 많은 트랜잭션이 동시에 업데이트하는 단일 데이터베이스 행을 피하세요. 많은 프로세스가 동일한 행을 동시에 업데이트하려고 하면, 각 트랜잭션이 쓰기를 위해 행을 잠그기 때문에 대기열이 생성됩니다. 이로 인해 트랜잭션 처리 시간이 크게 증가할 수 있으며, Rails 연결 풀이 포화 상태가 되어 애플리케이션 전체 다운타임이 발생할 수 있습니다. 각 행 업데이트마다 PostgreSQL은 새 행 버전을 삽입하고 이전 버전을 삭제합니다. 트래픽이 많은 시나리오에서 이 방식은 vacuum과 WAL(write-ahead log) 압박을 유발하여 데이터베이스 성능을 저하시킬 수 있습니다. 이 패턴은 각 요청마다 집계(aggregate)를 계산하는 비용이 너무 클 때, 데이터베이스에 누적 합계를 유지하는 형태로 자주 발생합니다. 이러한 집계가 필요한 경우, 단일 행에 누적 합계를 유지하고 최근에 추가된 데이터(예: 개별 증분값)의 소규모 작업 집합을 함께 유지하는 방식을 고려하세요: 새 데이터를 도입할 때 작업 집합에 추가하세요. 이 삽입 작업은 잠금 경합을 유발하지 않습니다. 집계를 계산할 때 누적 합계와 작업 집합의 실시간 집계를 결합하여 최신 결과를 제공합니다. 작업 집합을 누적 합계에 통합하고 트랜잭션 내에서 지우는 주기적인 job을 추가하여, 읽기 작업에 필요한 작업량을 제한하세요. 넓은 테이블 # PostgreSQL은 행을 8 KB 페이지로 구성하고 한 번에 한 페이지씩 처리합니다. 테이블에서 행의 폭을 최소화하면 다음과 같은 측면을 개선할 수 있습니다: 순차 스캔 및 비트맵 인덱스 스캔 성능: 각 페이지에 더 많은 행이 들어갈수록 스캔해야 할 페이지 수가 줄어듭니다. Vacuum 성능: vacuum이 각 페이지에서 더 많은 행을 처리할 수 있습니다. 업데이트 성능: (HOT가 아닌) 업데이트 중에는 각 행 업데이트마다 모든 인덱스를 업데이트해야 합니다. 넓은 테이블 완화는 데이터베이스 팀의 100 GB 테이블 이니셔티브 의 일환입니다. 테이블이 넓을수록 100 GB에 맞출 수 있는 행 수가 줄어들기 때문입니다. 테이블에 칼럼을 추가할 때, 새 칼럼의 데이터를 테이블의 다른 칼럼과 일대일 관계로 독립적으로 액세스할 의도가 있는지 고려하세요. 그렇다면 새 칼럼은 새 테이블로 분리하기에 좋은 후보가 될 수 있습니다. 여러 테이블이 이미 이런 방식으로 분리되었습니다. 예를 들면: search_data 는 issues 에서 분리되었습니다. project_pages_metadata 는 projects 에서 분리되었습니다. merge_request_diff_details 는 merge_request_diffs 에서 분리되었습니다. 데이터 모델 트레이드오프 # users , namespaces