카테고리 보관물: Sql

sql

블록 크기 이해 블록으로 작동합니다. 파일

내 질문은 Postgres를 대상으로하지만 모든 데이터베이스 배경에서 오는 대답은 충분할 수 있습니다.

내 가정이 맞습니까?

  • 디스크 크기가 고정되어 있습니까?
  • RAID 컨트롤러는 다른 블록 크기를 가질 수 있습니까? 하나의 RAID 블록이 여러 개의 실제 디스크 블록으로 분할됩니까?
  • 파일 시스템에는 RAID 블록 크기로 다시 분할되는 독립 블록 크기가 있습니까?
  • Postgres는 고정 8k 블록으로 작동합니다. 파일 시스템 블록 크기에 대한 매핑은 어떻게 이루어 집니까? Postgres 8k 블록이 파일 시스템에 의해 함께 배치됩니까?

시스템을 설정할 때 모든 블록을 8k로 유지하는 것이 가장 좋습니까? 아니면 설정이 중요하지 않습니까? 또한 충돌이 발생했을 때 일부 “잘못된”블록 크기 설정이 데이터 무결성을 위험에 빠뜨릴 수 있는지 궁금합니다. Postgres 8k 블록을 여러 디스크 블록으로 분할해야하는 경우가 있습니까?

또는 일괄 처리되는 것이 없으므로 정의 된 블록 크기 사이의 모든 불일치로 디스크 공간이 느슨해 집니까?



답변

디스크 섹터

디스크는 일부 최신 디스크에서 고정 섹터 크기 (일반적으로 512 바이트 또는 4096 바이트)를 갖습니다. 이 디스크에는 512 바이트 섹터를 에뮬레이트하는 모드도 있습니다. 디스크에는 다양한 섹터의 트랙이 있습니다. 디스크 외부에 더 가까운 트랙은 주어진 비트 밀도를위한 더 많은 공간을 갖기 때문에 더 많은 섹터를가집니다. 이를 통해 디스크 공간을보다 효율적으로 사용할 수 있습니다. 일반적으로 트랙에는 최신 디스크에 1,000 512 바이트 섹터가 있습니다.

일부 포맷팅 구조는 또한 520 또는 528 바이트 섹터로 로우 레벨 포맷 된 디스크에서 나타나는 시토 터의 에러 정정 정보를 포함 할 수있다. 이 경우 섹터에는 여전히 512 바이트의 사용자 데이터가 있습니다. i5OS (IBM iSeries) 및 다양한 SAN 컨트롤러가이를 수행하지만 Windows 나 Linux는이를 직접 지원하지 않습니다.

일반적으로 섹터 / 헤드 / 트랙은 논리 블록 주소로 변환됩니다. 이전 버전과의 호환성 문제로 인해 운영 체제 (특히 IDE 및 SATA 디스크)에서 볼 수있는 지오메트리 (헤드 x 섹터 x 트랙)는 일반적으로 물리적 구조와 거의 관련이 없습니다.

RAID 스트라이프 크기

RAID 컨트롤러는 스트라이핑 (예 : RAID-5 또는 RAID-10)을 사용하여 어레이의 스트라이프 크기를 가질 수 있습니다. 어레이에 128k 스트라이프가있는 경우 (예를 들어) 각 디스크에는 128k의 연속 데이터가 있으며 다음 데이터 세트는 다음 디스크에 있습니다. 일반적으로 디스크 회 전당 약 1 개의 스트라이프를 얻을 수 있으므로 스트라이프 크기가 ​​특정 워크로드의 성능에 영향을 줄 수 있습니다.

파티션 정렬

디스크 파티션은 RAID 스트라이프와 정확하게 정렬되거나 정렬되지 않을 수 있으며, 정렬되지 않은 경우 분할 읽기로 인해 성능이 저하 될 수 있습니다. 일부 시스템 (예 : Windows 2008 서버)은 디스크 볼륨 스트라이프 크기에 맞게 파티션을 자동으로 구성합니다. 일부 (예 : Windows 2003 서버)는 그렇지 않으므로 스트라이프 정렬을 지원하는 파티션 유틸리티를 사용해야합니다.

파일 시스템 블록 크기

파일 시스템은 특정 크기의 청크로 저장소 블록을 할당합니다. 일반적으로 이것은 구성 가능합니다. 예를 들어 NTFS는 (IIRC) 4K에서 64K의 할당 단위를 지원합니다. 파티션과 파일 시스템 블록을 RAID 스트라이프로 잘못 정렬하면 파일 시스템 블록이 RAID 스트라이프와 올바르게 정렬 된 경우 단일 파일 시스템 블록 읽기로 여러 디스크 액세스가 생성 될 수 있습니다.

데이터베이스 블록 크기

데이터베이스는 주어진 블록 크기로 테이블이나 인덱스에 공간을 할당합니다. SQL Server의 경우 이는 8K이며 많은 시스템에서 기본값은 8K입니다. Oracle과 같은 일부 시스템에서는이 기능을 구성 할 수 있으며 PostgreSQL에서는 빌드 타임 옵션입니다. 대부분의 시스템에서 테이블에 대한 공간 할당은 일반적으로 해당 청크 내에 블록이 할당 된 더 큰 청크로 수행됩니다.

파일 시스템과 데이터 할당 블록이 잘못 정렬되면 단일 블록 쓰기에 대해 여러 개의 I / O가 생성되어 성능이 저하 될 수 있습니다.

I / O 청킹

일반적으로 DBMS는 실제로 하나 이상의 블록 청크로 I / O를 수행합니다. 예를 들어, SQL Server에서 모든 I / O는 8 개의 블록 청크 (총 64k)로 수행됩니다. Oracle에서는이를 구성 할 수 있습니다. PostgreSQL 문서에 대한 일상적인 검사는 PostgreSQL이이를 수행하는지 여부에 대한 구체적인 설명을 나타내지 않으므로이 플랫폼에서 어떻게 작동하는지 잘 모르겠습니다.

I / O 청크가 파일 시스템 블록 크기보다 크거나 RAID 스트라이프 경계와 잘못 정렬되면 DB의 디스크 쓰기로 인해 여러 디스크 쓰기가 발생하여 성능이 저하 될 수 있습니다.

디스크 공간 사용량

디스크 공간이 낭비되지 않습니다. 데이터베이스 I / O는 디스크에서 하나 이상의 물리적 I / O 작업을 사용하여 완료하지만 잘못 조정 된 I / O로 인해 비 효율성이 발생하여 데이터베이스 속도가 느려질 수 있습니다. 정렬해야 할 주요 사항은 다음과 같습니다.

  • RAID 스트라이프 및 파티션-파티션은 RAID 스트라이프 경계에서 시작해야합니다.

  • 파일 시스템 I / O 할당 및 RAID 스트라이프 / 파티션 경계-RAID 스트라이프 경계는 파일 시스템 할당 단위와 일치해야하며 파일 시스템 할당 단위 크기의 배수 여야합니다.

  • 디스크 쓰기 크기 및 파일 시스템 할당 단위 크기 데이터베이스 I / O 작업과 파일 시스템 I / O 작업 간에는 1 : 1 관계가 있어야합니다.

오정렬은 다른 것보다 더 큰 데이터 무결성 문제를 일으키지 않습니다. 데이터베이스와 파일 시스템에는 파일 시스템 기능이 원 자성을 갖도록하는 메커니즘이 있습니다. 일반적으로 디스크 충돌은 데이터 손실을 초래하지만 데이터 무결성 문제는 발생하지 않습니다.


답변