MS SQL Server에서 많은 수의 테이블을 관리하는 가장 좋은 방법은 무엇입니까?


4

이 문제는 서로 관련되어
Will having multiple filegroups help speed up my database?

우리가 개발하는 소프트웨어는 관계형 데이터를 저장하기 위해 MS SQL 서버 2005를 사용하는 분석 도구입니다. 초기 분석은 느려질 수 있지만 (수백만 또는 수십억 개의 데이터 행을 처리하기 때문에) 이전 분석을 신속하게 호출하는 성능 요구 사항이 있으므로 각 분석의 결과를 "저장"합니다.

우리의 현재 접근 방식은 분석 결과를 일련의 "실행 특정"테이블에 저장하는 것이고, 분석은 충분히 복잡하여 분석 당 최대 100 개의 테이블로 끝날 수 있습니다. 일반적으로이 테이블은 분석 당 수백 MB를 사용합니다 (이는 수백 GB 또는 때때로 여러 TB의 소스 데이터에 비해 작습니다). 그러나 전반적으로 디스크 공간은 우리에게 문제가되지 않습니다. 각 테이블 세트는 하나의 분석에만 적용되며 많은 경우에 소스 데이터를 다시 참조하는 것보다 성능이 크게 향상되었습니다.

접근 방식은 우리가 충분한 저장 분석 결과를 축적하면 분해하기 시작 - 우리가보다 강력한 보관/정리 기능을 추가하기 전에, 우리의 테스트 데이터베이스는000000 여러 테이블에 올랐다. 그러나 생산 단계에서도 10 만 개 이상의 테이블을 사용할 수 있습니다. Microsoft는 sysobjects (~ 20 억)의 크기에 대해 이론적으로 엄청난 제한을두고 있지만 데이터베이스가 100,000 개가 넘으면 CREATE TABLE 및 DROP TABLE과 같은 간단한 쿼리가 크게 느려질 수 있습니다.

우리는 우리의 접근법에 대해 토론 할 여지가 있지만 더 많은 내용이 없으면 어려울 수도 있습니다. 그래서 나는 더 많은 질문을하고 싶습니다 : 우리가 너무 많은 테이블을 만들어야한다면, 그들을 관리하는 가장 좋은 방법은 무엇입니까? 여러 파일 그룹? 여러 스키마/소유자? 여러 데이터베이스?

다른 메모 : 단순히 "문제가 발생한 하드웨어를 버리는"생각 (즉, RAM, CPU 전원, 디스크 속도 추가)에 대해 기쁘게 생각하지 않습니다. 그러나 특히 RAM을 추가하거나 여러 파일 그룹을 사용하면 큰 시스템 카탈로그를 관리 할 때 어떤 영향을 미칠지 명확하게 알릴 수있는 경우 특히 그렇습니다.

  0

WOW. 그 많은 테이블로, Management Studio는 목록을로드 할 때 무엇을합니까? 그것은 고통 스러울 것입니다. 23 sep. 082008-09-23 23:38:19

  0

우리는 Management Studio가 테이블 목록을 가져 오도록하지 않습니다. 실수로 누군가가 실수로 프로세스를 종료해야하거나 충돌합니다. 그러나 그것은 우리의 가장 큰 문제와 거리가 멀다. 30 dec. 082008-12-30 14:49:17

  0

나는 이것이 어떻게 당신에게 나타 났는지 궁금합니다. 이것은 거의 아무도 그것을하는 방법에 대한 확실한 정보를 가지고 있지 않으며 모든 이론입니다. 그래서 어떤 대답이라도 알아두면 좋을 것입니다. 16 aug. 112011-08-16 06:58:58

0

우리 데이터베이스가 여러 개의 데이터베이스로 나뉘게되었습니다. 따라서 주 데이터베이스에는 하나 이상의 "실행"데이터베이스를 참조하는 "데이터베이스"테이블이 포함되어 있습니다. 각 테이블에는 서로 다른 분석 결과 세트가 들어 있습니다. 그런 다음 기본 "실행"테이블에는 데이터베이스 ID가 포함되며 저장된 결과를 검색하는 코드에는 모든 쿼리의 관련 데이터베이스 접두사가 포함됩니다.

이 방법을 사용하면 각 데이터베이스의 시스템 카탈로그를보다 합리적으로 만들 수 있으며 코어/영구 테이블과 동적/실행 테이블을 더 잘 분리 할 수 ​​있으며 백업 및 아카이빙을보다 관리하기 쉽게 만듭니다. 또한 여러 파일 그룹을 사용했을 경우에도 여러 실제 디스크에 데이터를 분할 할 수 있습니다. 전반적으로 우리의 현재 요구 사항을 고려할 때 현재 잘 작동하고 있으며 기대되는 성장을 기반으로 우리는 우리에게도 잘 확장 될 것으로 생각합니다.

SQL 2008은 SQL 2000 및 SQL 2005보다 큰 시스템 카탈로그를 처리하는 경향이 있습니다. (우리는이 질문을 올렸을 때 2008 년으로 업그레이드하지 않았습니다.)


0

이것은 매우 흥미로운 문제/당신이 작업하고있는 응용 프로그램 인 것 같습니다. 나는 이런 식으로 일하는 것을 좋아할 것입니다. :)

표면적이 매우 커서 문제가 발생하기 쉽지 않습니다. 게시물에 분명하지 않은 몇 가지 솔루션 매개 변수가 있습니다. 예를 들어, 실행 분석 테이블을 얼마나 오래 보관할 계획입니까? 다른 질문이 필요합니다.

심각한 데이터웨어 하우징과 데이터/테이블 파티셔닝이 필요합니다. 보관 및 보관할 데이터 양에 따라 테이블의 비정형 화 및 병합을 시작해야 할 수 있습니다.

Microsoft에 직접 문의하면 상호 이익이 될 수있는 좋은 사례입니다. Microsoft는 다른 고객에게 좋은 사례를 보여주고 공급 업체로부터 직접 도움을받습니다.


1

테이블이 모두 다른 구조입니까? 구조가 같으면 하나의 분할 된 테이블을 사용할 수 있습니다.

다른 구조이지만 동일한 차원 열 집합의 하위 집합 인 경우 적용 할 수없는 열에 null이있는 동일한 테이블의 파티션에 해당 테이블을 저장할 수 있습니다.

이것이 분석적인 경우 (파생 가격 결정 계산은 아마도?) 계산 실행 결과를 플랫 파일로 덤프하고 플랫 파일에서로드하여 계산을 재사용 할 수 있습니다.


2

처음에는 전체 시스템을 보지 않고도 키의 일부로 RunID를 사용하여 결합 된 테이블에 히스토리 런을 저장하는 것이 가장 좋습니다. 차원 모델도 여기서 관련이 있습니다. 이 테이블은 성능 향상을 위해 파티션을 분할 할 수 있으므로 테이블을 다른 파일 그룹에 분산시킬 수 있습니다.

는 TABLE과 DROP 표 아마 제대로 수행하는 CREATE 필요에 따라 단지를 부착, 그들을 분리 (읽기 전용 형태로)

다음 자신의 데이터베이스에 각 실행을 넣고 또 다른 가능성 때문에 마스터 또는 모델 데이터베이스는 이러한 종류의 동작에 최적화되어 있지 않습니다.

데이터베이스 디자인 선택에 대해 Microsoft와 이야기하는 것이 좋습니다.