SSD의 SQL Server 데이터베이스-모든 테이블에 대해 별도의 파일이 있습니까?


19

나는 약 30 개의 테이블이있는 데이터베이스를 만들고 있는데, 각 테이블에는 수천만 개의 행이 있고 각 테이블에는 하나의 중요한 열과 기본 / 외래 키 열이 포함되어있어 무거운 상황에서 쿼리 효율을 극대화합니다. 업데이트 및 삽입 및 클러스터형 인덱스를 많이 사용합니다. 두 테이블은 가변 길이의 텍스트 데이터를 포함하고 그 중 하나는 수억 행을 포함하지만 나머지는 숫자 데이터 만 포함합니다.

사용 가능한 하드웨어 (약 64GB RAM, 매우 빠른 SSD 및 16 코어)에서 마지막으로 성능 저하를 없애고 싶을 때 각 테이블에 자체 파일이 있도록 허용하려고 생각했습니다. 2, 3, 4, 5 이상의 테이블에 합류하고 있습니다. 각 테이블은 항상 별도의 스레드를 사용하여 읽히고 각 파일의 구조는 테이블 내용과 밀접하게 정렬되므로 조각화를 최소화하고 더 빨리 만들 수 있습니다. SQL Server가 주어진 테이블의 내용에 추가 할 수 있습니다.

한 가지주의 할 점은 SQL Server 2008 R2 Web Edition 에 붙어 있습니다. 즉, 자동 수평 파티셔닝을 사용할 수 없으므로 성능이 향상됩니다.

테이블 당 하나의 파일을 사용하면 실제로 성능이 최대화됩니까, 아니면 중복되는 내장 SQL Server 엔진 특성을 간과합니까?

둘째, 테이블 당 하나의 파일을 사용하는 것이 유리하다면 왜 create table특정 논리 파일이 아닌 파일 그룹에 테이블을 할당하는 옵션 만 제공합니까? 이를 위해서는 시나리오의 모든 파일에 대해 별도의 파일 그룹을 만들어야합니다. 이는 SQL Server가 내가 제안한 작업을 수행 할 때 얻을 수있는 이점을 상상하지 못하고 있음을 나타냅니다.

답변:


18

2, 3, 4, 5 또는 그 이상의 테이블에서 조인하더라도 각 테이블은 항상 별도의 스레드를 사용하여 읽히고 각 파일의 구조는 다음과 같이됩니다. 테이블 내용과 밀접하게 정렬되므로 조각화를 최소화하고 SQL Server가 주어진 테이블의 내용에 더 빠르게 추가 할 수 있습니다.

도대체 무슨 소리 야? 어디에서 정보를 얻었는지 확실하지 않지만 해당 출처를 반드시 폐기해야합니다. 여기에서 가정 한 내용 중 실제로 올바른 것은 없습니다.

SQL Server의 SSD 성능에 대한 좋은 설명을 읽으려면 몇 가지 블로그 시리즈가 있습니다. 일반적으로 Paul Randal이 가장 많이 읽은 것입니다.

Brent는 SSD 에 대한 SQL : Hot and Crazy Love 주제에 대한 훌륭한 프레젠테이션을 제공합니다 .

이 모든 프레젠테이션을 살펴보면 SSD 성능이 그림에 나타나는 곳이기 때문에 쓰기에 중점을 둔다 것을 빨리 알 수 있습니다. 귀하의 게시물 문구는 거의 전적으로 읽기에 관한 것이며 이는 다른 주제입니다. 읽기가 어려움이라면 SSD가 아니라 RAM과 적절한 인덱싱 및 쿼리 전략에 대해 이야기해야합니다.


1
그러나 나는 어딘가에 잘못된 정보를 받았지만 Stuart의 답변에 대해 언급 한 것처럼 잘못된 정보에 대한 결정을 내리지 않았는지 확인하기 위해 질문했습니다. 링크 주셔서 감사합니다, 나는 그들을 확인합니다.

17

첫 제안은 두 구성에 대해 부하 테스트를 수행하지 않고 성능에 대한 가정을하지 않는 것입니다.

과거에 이러한 구성 (종이에 의미가 있음)을 보았을 때의 추측은 별도의 파일에 각 테이블을두면 성능에 긍정적 인 영향을 미치지 않으며 추가 복잡성으로 인해 성능 향상이 상쇄 될 것입니다. 그들이 측정 가능하더라도.

마지막으로, SQL Server에서 모든 성능 저하를 압박 할 때는 다음 차트 (Microsoft 제공)를 참조하십시오.

여기에 이미지 설명을 입력하십시오

응용 프로그램 관점에서 수행 할 수있는 모든 잠재적 인 최적화는 하드웨어 / 데이터베이스 구성 수준에서 가능한 모든 최적화를 쉽게 왜곡합니다. 따라서주의를 집중하십시오.


물론이야. 필자의 경우, 나는 가능한 한 전체 시스템을 최적화 해 왔으며 지금 당장 주요 병목 현상은 빈번한 업데이트, 삭제 및 삽입에 대한 쿼리 속도가 매우 빠릅니다. 이 문제를 해결하기 위해 SQL Server를 활용하면서 데이터에서 최대한 빠르게 작업 할 수있는 최고의 기회를 제공하고 싶습니다.

@NathanRidley Ok.
마이클 프레드릭 슨

4

다른 사람들이 지적했듯이, 테이블 당 하나의 파일에서 직접적인 이점은 없습니다. 다음은이 신화의 기원에 대한 Steve Jones의 훌륭한 개요입니다. http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

2008 Web Edition에서 지원한다고 생각되는 분할 된 뷰를 조사 할 수도 있습니다. 분할 된 뷰에 대한 코딩에는 몇 가지 트릭이 있지만 분할 된 테이블의 많은 기능을 비교적 쉽게 모방 할 수 있습니다.


2

각 테이블마다 별도의 파일이 있으면 성능상의 이점이 없습니다. 올바른 인덱스는 데이터베이스 서버에서 잠재적 인 성능 (디스크 읽기)을 유발할 수 있습니다.

SQL Server 2008 R2는 압축을 지원합니까? 그렇다면 켜십시오.

틀린 점 있으면 지적 해주세요.


성능상의 이점이없는 이유를 자세히 설명해 주시겠습니까? 최소한 별도의 파일을 사용하여 SQL Server가 여러 스레드를 사용하여 읽을 수있는 경우에 대해 설명하십시오.

모든 테이블을 자체 파일 그룹에 배치하지만 동일한 드라이브에 배치하면 분할 전에 성능이 동일 해집니다. 그러나 일부 테이블을 다른 빠른 디스크의 파일 그룹으로 분리하면 성능상의 이점이 있습니다. 연도에 따라 많은 데이터가있는 경우 연도별로 파티션을 나눌 수도 있습니다. 이 기술을 사용하면 가장 많이 사용하는 데이터를 기존 데이터보다 빠른 디스크에 유지할 수 있습니다. 인덱스를 분리 할 수도 있지만 새 물리 디스크에 넣으면 성능상의 이점이 있습니다.

병렬 스레드 (테이블 / 파일)에 대해서는 맞지만 물리적 디스크가 하나만있을 때까지 성능 향상은 작을 것이라고 생각합니다.

그리고 SSD가 곧 죽을 것이기 때문에 데이터베이스를위한 강력한 HDD RAID 어레이를 얻는 것이 좋습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.