최대 속도의 SQL Server 데이터 형식 선택

Question

최대 속도에 맞게 최적화해야하는 데이터베이스를 설계하고 있습니다.

모든 데이터베이스 데이터는 입력 데이터베이스 (내가 편집중인 데이터, 주로 일부 폴리 라인, 마커 등)를 Google지도에서 호출하는 것으로부터 한 번 생성됩니다.

데이터베이스는 편집 대상이 아니지만 결과를 사용자에게 신속하게 표시 할 수있는 최대한 많은 데이터 (도시, 사용자 지정 폴리 라인 등의 경로)를 유지해야합니다.

질문 : 작은 데이터 형식을 int와 같은 smallint와 같이 선택하면 성능이 향상되거나 영향을 미칩니 까? 일부 빠른 계산 후에 공간은 문제가되지 않지만 데이터베이스는 200MB를 초과하지 않으며 100,000 개가 넘는 행이있는 테이블은 없습니다 (평균은 약 5.000).

인터넷에서 기사를 읽었으며 일부 데이터 유형이 성능을 향상 시키므로 다른 사람들이 그것이 추가 처리가 수행되어야하기 때문에 영향을 준다는 말 때문에 일부 질문을하고 있습니다. 더 작은 데이터베이스의 경우 결과가 눈에 띄지 않을 수 있지만, 많은 요청을 기대하기 때문에 모든 비트에 관심이 많다는 사실을 알고 있습니다.

호스팅 환경은 SQL Server 2008 R2가 설치된 Windows Server 2008 R2가 될 것입니다.

편집 1 : 그냥 나는 아직 적절한 테이블 구조가 없기 때문에 당신에게 예를 제공 : 을 나는 (곳 (200)의 주위에) 대중 교통 라인을 보유 할 테이블이거야, 식별 실제 생활에서 고유 한 숫자이며 모든 종류의 테이블에서 참조 될 것이며 모든 종류의 조작이 이루어질 것입니다. 이러한 참조 테이블은 가장 많은 양의 데이터를 보유합니다. 라인 고유 번호를 가지고 있기 때문에

가, 내가 디자인의 3 명 예의 생각 다음 PK는 데이터 형식의 행 번호입니다

을 smallint로 :

1. 약동학은 데이터 형식의 행 번호는 다음과 같습니다 int

2. PK는 다른 것으로 (예 : ID) 행 번호가 다른 필드에 저장됩니다.

3. 최적화의 대상이 아닌 '입력 데이터베이스'에서 사용 했으므로 PK는 GUID (16 바이트)입니다. 만약 당신이 좋아하면 정말

는 그래서 PK가 최소 15 개 테이블 중 일부에서 참조 될 것입니다 것을 명심 경우, 당신이 다른 사람과 비교하는 방법 나쁜 비교를 할 수 있습니다 50.000 개가 넘는 행 (나머지는 위에서 말했듯이 평균 5.000 개가됩니다)은 일정한 질의와 조작을 할 것이고, 나는 얻을 수있는 모든 속도에 관심이 있습니다.

필요한 경우 자세히 설명해 드릴 수 있습니다.감사합니다

편집 2 : 내가 네이티브 SQL 쿼리를 사용하는 경우

내가이 특정 시나리오에의 모든 성능 개선을 표시됩니다 그리고이 관련된 또 다른 문제는이 토론에 맞는 생각, 내 마음에 와서 내부에서 내 .NET 응용 프로그램 대신 LINQ를 사용하여 SQL? 나는 LINQ가 강력하게 최적화되어 있으며 성능 측면에서 좋은 쿼리를 생성하지만 여전히 가치가 있다고 생각합니다. 다시 한번 감사드립니다.

Answer 1

더 작은 데이터 유형 = 더 많은 처리를 가리키는 기사를 가리킬 수 있습니까? SSD를 사용하더라도 현재 대부분의 작업 부하는 CPU 바운드가 아닌 I/O 바운드 (또는 메모리 바운드)입니다.

특히 PK가 많은 테이블에서 참조되는 경우 가능한 가장 작은 데이터 유형을 사용하는 것이 좋습니다. 이 경우 그 경우 SMALLINT이면 그게 내가 사용하는 것입니다. (약 200 개의 값이 있기 때문에 이론적으로는 절반 크기이고 0-255를 지원하는 TINYINT을 사용할 수 있습니다). 신중을 기해야 할 곳은 항상 ~ 200 값이 100 % 확실하지 않다는 것입니다. 일단 256이 필요하다면, 영향을받는 모든 테이블에서 데이터 유형을 변경해야하는데, 이것은 고통 스러울 것입니다. 때때로 미래 성장을 수용하고 오늘날 가장 절대적인 성과를 쥐어 짜는 것 사이에 절충이 이루어 지기도합니다. 255 또는 32,000 값을 초과하지 않을 것이라는 확신이 없다면 아마 INT 일 것입니다. 20 억 개의 값을 초과하지 않는다는 것을 모르는 경우가 아니면 BIGINT을 사용합니다.

차이점은 INT/SMALLINT/입니다. 이는 성능보다 디스크 공간에서 더 두드러 질 것입니다. (기업에서 사용하는 경우 디스크 압축과 성능의 차이는 데이터 압축을 사용하여 상당 부분 상쇄 될 수 있습니다. 특히 INT 값이 SMALLINT/TINYINT 사이에 모두 들어가는 반면, 후자의 경우 실제로 무시할 수 있습니다. 값은 고유합니다.) 한편, 이들 중 하나와 GUID 사이의 차이점은 성능 및 디스크 공간 모두에서 훨씬 더 두드러 질 것입니다. Marc은 Kimberly로부터 훌륭한 링크를 제공했습니다. I wrote this article은 2003 년과 약간 날짜가 있지만 오늘날에도 여전히 중요한 부분이 대부분 포함되어 있습니다.

가끔은 고려해야 할 또 다른 절충안 (특정 경우는 아니지만)은 값이 여러 시스템에서 고유해야하는지 여부입니다. 비즈니스 요구 사항을 충족시키기 위해 일부 성능을 희생해야 할 수도 있습니다. 많은 경우 사람들은 쉬운 길을 택하고 자신을 GUID으로 퇴직시킵니다. 그러나 신원 범위, 중앙 맞춤 시퀀스 생성기 및 SQL Server 2012의 새로운 SEQUENCE 개체와 같은 다른 솔루션도 있습니다. I wrote about SEQUENCE 2010 년 SQL Server 2012의 첫 번째 공개 베타가 출시되었을 때 다시 돌아 왔습니다.

Answer 2

테이블 구조와 이에 대해 실행될 샘플 쿼리에 대한 자세한 내용을 제공해야한다고 생각합니다. 당신이 제공 한 정보를 기반으로 나는 더 작은 데이터 유형을 선택했을 때의 영향이 단지 몇 퍼센트가 될 것이라고 믿습니다. 나는 당신이 가질 지수에 더 많은 관심을 기울일 것을 제안합니다. SQL Server는 쿼리에 대한 실행 계획을 제공하고 어드바이저 도구를 튜닝함으로써 어떤 인덱스를 만들지 제안하는 데 좋은 역할을합니다.

Answer 3

내가 가진 한 가지 제안은 필드 조합을 사용하는 대신 10 진수 데이터 유형을 통합하는 것입니다. 예를 들어 Date (YYYYMMDD), Store (SSSS) 및 Item (IIII)이있는 테이블 대신 YYYYMMDD.SSSSIIII를 권합니다.특히 동일한 키 조합으로 여러 테이블을 쿼리 할 때 처리 시간이 크게 향상됩니다.