데이터베이스 디자인 및 성능(SQL Server Compact Edition)

  • 아티클

SQL Server 데이터베이스 및 게시를 적절히 디자인하여 SQL Server 2005 Compact Edition(SQL Server Compact Edition) 응용 프로그램 성능을 크게 향상시킬 수 있습니다. 다음 섹션에서는 성능 향상을 위해 사용할 수 있는 기술에 대해 대략적으로 설명합니다.

데이터베이스 비정규화 사용

데이터베이스를 정규화하면 데이터의 기능적 종속 관계가 사라지므로 데이터베이스를 쉽고 효율적으로 업데이트할 수 있습니다. 그러나 데이터베이스를 쿼리하려면 정보를 결합하기 위해 많은 테이블 조인이 필요할 수 있습니다. 조인 테이블 수가 증가할수록 쿼리 실행 시간이 크게 늘어납니다. 따라서 데이터베이스를 정규화하는 것이 항상 최선의 방법이 아닐 수 있습니다. 데이터베이스를 적절히 비정규화하면 업데이트 프로세스가 크게 복잡해지지 않으면서도 조인해야 하는 테이블 수를 줄일 수 있습니다. 이 방법이 유용한 경우가 종종 있습니다.

[!참고] 일반적으로 쿼리 수가 많아 다섯 개 또는 여섯 개 이상의 테이블 조인이 필요할 경우 비정규화를 고려해야 합니다.

다른 종류의 데이터베이스 비정규화도 있습니다. 예를 들어 데이터베이스에 Orders와 Order Details의 두 테이블이 있는 경우를 가정해 볼 수 있습니다. Orders 테이블에는 고객 주문 정보가 들어 있습니다. 각 주문에 포함된 개별 제품에 대한 정보는 Order Details 테이블에 들어 있습니다. 각 주문의 총 달러 금액을 쿼리하려고 합니다. 먼저 각 제품의 달러 금액(개수 * 단가 - 적용 가능한 할인액)을 결정해야 합니다. 그런 후 이 금액을 주문별로 그룹화해야 합니다. 이 경우 쿼리는 다음과 같습니다.

SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))

AS Total FROM "Order Details"

GROUP BY "Order ID"

Order ID Total

----------------------------------------

10000 108

10001 1363.15000915527

10002 731.800003051758

10003 498.180023193359

10004 3194.19999694824

10005 173.400009155273

10006 87.2000007629395

10007 1405

10008 1171

10009 1530

10010 470

... ...

(1078 rows affected)

이 쿼리에 따른 계산은 간단하지 않습니다. 주문 집합이 많은 경우 쿼리 실행에 많은 시간이 소요될 수 있습니다. 주문 실행 시 주문의 달러 금액을 계산한 다음 이 금액을 Orders 테이블의 열에 저장하는 방법도 있습니다. 이 방법을 사용하는 경우 필요한 정보를 반환하려면 미리 계산한 열만 쿼리해야 합니다.

SELECT "Order ID", "Order Total" AS Total FROM Orders

미리 계산된 열을 만들면 쿼리 시간을 크게 단축할 수 있지만 테이블에 추가된 열을 유지 관리해야 합니다.

가변 길이 열 또는 고정 길이 열 선택

테이블을 디자인할 때 가변 길이 열과 고정 길이 열을 사용하는 데 따르는 장단점을 알면 도움이 됩니다. 가변 길이 열의 경우 실제 값을 저장하는 데 필요한 공간만 사용하므로 데이터베이스 크기가 줄어듭니다. 고정 길이 열은 실제 값이 비어 있는 경우에도 스키마에 정의된 최대 공간을 사용합니다. 가변 길이 열의 단점은 일부 연산이 고정 길이 열에서 수행하는 것만큼 효율적이지 못하다는 것입니다. 예를 들어 처음에는 작았던 가변 길이 열이 UPDATE로 인해 커진 경우 레코드를 다시 배치해야 할 수도 있습니다. 또한 업데이트를 자주 수행할 경우 시간이 경과함에 따라 데이터 페이지의 조각화가 심화됩니다. 따라서 데이터 길이에 큰 차이가 없고 업데이트를 자주 수행할 경우에는 고정 길이 열을 사용하는 것이 좋습니다.

행 길이 줄이기

한 페이지에 들어갈 수 있는 행의 수는 각 행이 얼마나 작은가에 따라 달라집니다. 행이 작을수록 한 페이지에 들어갈 수 있는 행 수가 늘어납니다. 따라서 작은 행을 포함하는 테이블에서 단일 디스크 연산을 수행할 경우 더 많은 행이 검색되어 연산의 효율성이 높아집니다. 또한 저장소 엔진 캐시에 들어가는 행 수가 늘어나 적중률이 향상될 수 있습니다. 행이 작으면 데이터 페이지의 공간 낭비도 줄일 수 있습니다. 이것은 행이 클 경우에는 흔히 나타나는 문제입니다.

다음과 같은 극단적인 예를 고려해볼 수 있습니다. 레코드 크기가 데이터 페이지의 절반 크기보다 크면 각 데이터 페이지 공간의 절반이 낭비됩니다. 데이터베이스 디자이너들은 종종 테이블을 넓게 디자인하고 메인프레임 데이터베이스 스키마를 장치에 적용합니다. 이것은 효과적인 디자인이라고 볼 수 없습니다. 가장 중요한 테이블을 분리하는 것도 한 가지 방법입니다. 일부 열에는 매우 안정적인 값이 들어 있고 다른 열에는 자주 변경되는 값이 들어 있는 테이블을 가정해봅니다. 이 경우 테이블을 자주 참조되는 열을 포함하는 테이블과 안정된 열을 포함하는 테이블의 두 개로 나눌 수 있습니다. 두 개의 테이블로 만들면 작은 길이의 행을 사용할 때의 이점을 모두 얻을 수 있습니다. 단, 정보를 결합하기 위해 조인이 필요하다는 것이 한 가지 단점입니다.

작은 키 길이 사용

인덱스는 해당 인덱스가 만들어진 테이블의 정렬된 하위 집합입니다. 인덱스를 사용하면 빠른 범위 조회 및 정렬이 가능합니다. 인덱스 키가 작을수록 공간을 덜 차지하여 큰 키를 사용할 때보다 효과적입니다. 특히 기본 키는 다른 테이블에서 외래 키로 자주 참조되므로 작게 만들면 좋습니다. 원래부터 작은 길이의 기본 키가 없을 경우에는 정수로 구현된 ID 열을 대신 사용할 수 있습니다.

키 열이 하나이거나 소수인 인덱스를 좁은 인덱스라고 합니다. 키 열이 여러 개인 인덱스를 넓은 인덱스라고 합니다. 넓은 인덱스는 주로 키 길이가 넓습니다. 극단적인 예로 테이블 안에 모든 열을 포함된 인덱스를 들 수 있습니다. 이러한 인덱스를 만들면 원본 테이블을 효과적으로 중복할 수 있습니다. 그러나 이러한 인덱스는 데이터베이스 크기 및 쿼리 성능 면에서 비효율적입니다.

게시 아티클 유형 및 옵션

SQL Server 2000 에서 게시를 만드는 경우 표준 아티클을 사용하여 게시를 만듭니다. 이러한 아티클은 필터링될 때 일반 필터링을 사용합니다. 그러나 SQL Server 2005 에서 게시를 만드는 경우에는 게시의 아티클에 대해 두 가지 옵션을 추가로 선택할 수 있습니다. 필터링 및 게시자와 구독자 간의 데이터 흐름을 제어하는 이러한 옵션은 다음과 같습니다.

  • 다운로드 전용(읽기 전용)
    원하는 스마트 장치 관련 데이터가 조회 테이블에만 저장되어 있을 수 있습니다. 사용자로 하여금 스마트 장치에서 회사 디렉터리를 검색만 하고 정보를 편집하거나 변경하지 못하게 하는 경우가 이러한 예에 해당합니다. 다운로드 전용 아티클 유형은 이러한 용도에 적합합니다. 메타데이터가 장치에 저장되지 않으므로 아티클 크기가 작아 동기화 과정에서 네트워크 트래픽이 줄어듭니다.
  • 고급 분할
    SQL Server 2000 에서 파티션 그룹을 만들 수는 있지만 데이터를 업로드할 때마다 파티션 ID 매핑을 계산해야 하므로 데이터 업로드 중에는 성능이 저하됩니다. SQL Server 2005 에서 잘 분할된 아티클을 사용할 경우 업로드된 변경 내용이 단일 파티션 ID에만 매핑되어 속도는 빨라지지만 다음과 같은 제약이 있습니다.
    • 아티클의 각 행은 한 파티션 ID에만 속해야 합니다.
    • 각 아티클은 단일 게시에만 게시될 수 있습니다.
    • 구독자는 해당 파티션 ID에 속하지 않은 행을 삽입할 수 없습니다.
    • 잘 분할된 아티클을 사용해도 필터링에는 영향을 미칩니다. 필터링에는 다음과 같은 제약이 따릅니다.
    • 구독자는 필터링에 관련된 열을 업데이트할 수 없습니다.
    • 조인 필터 계층에서 일반 아티클은 잘 분할된 아티클의 부모가 될 수 없습니다.
    • 잘 분할된 아티클이 자식이 되는 조인 필터는 join_unique_key 값을 1로 설정해야 합니다.
    • 각 아티클은 하위 집합이나 조인 필터를 하나만 가질 수 있습니다. 아티클은 하위 필터를 가지면서 조인 필터의 부모가 될 수 있지만, 하위 필터를 가지면서 조인 필터의 자식이 될 수는 없습니다.

참고 항목

개념

쿼리 성능 튜닝(SQL Server Compact Edition)

관련 자료

성능 강화(SQL Server Compact Edition)

도움말 및 정보

SQL Server Compact Edition 지원 정보 보기