클러스터 된 열 저장소 인덱스 및 외래 키

인덱스를 사용하여 데이터웨어 하우스를 성능 조정 중입니다. SQL Server 2014를 처음 접했을 때 다음과 같이 설명합니다.

"클러스터형 columnstore 인덱스는 대규모 데이터웨어 하우징 팩트 테이블을 저장하기위한 표준으로 간주하며 대부분의 데이터웨어 하우징 시나리오에서 사용될 것으로 예상됩니다. 클러스터형 columnstore 인덱스는 업데이트 가능하므로 워크로드는 많은 수의 삽입, 업데이트, 작업을 삭제하십시오. " http://msdn.microsoft.com/en-us/library/gg492088.aspx

그러나 설명서를 자세히 읽으면 다음과 같은 제한 사항이 있습니다.

"고유 제한 조건, 기본 키 제한 조건 또는 외래 키 제한 조건을 가질 수 없습니다."

이것은 나를 많이 혼란스럽게한다! 다양한 이유로 데이터웨어 하우스에 외래 키를 두는 것이 좋습니다 (필수 아님) (데이터 무결성, 의미 계층에 대한 관계 표시 등).

따라서 Microsoft는 데이터웨어 하우스 시나리오에 대한 클러스터형 열 저장소 인덱스를 옹호합니다. 그러나 외래 키 관계를 처리 할 수 ​​없습니까?!

내가 맞습니까? 다른 접근 방법은 무엇입니까? 과거에는 데이터웨어 하우스 시나리오에서 데이터로드에 대한 삭제 및 재 구축과 함께 비 클러스터형 columnstore 인덱스를 사용했습니다. 그러나 SQL Server 2014는 데이터웨어 하우스에 새로운 가치를 더하지 않습니다 ??

여기에 많은 질문이 있습니다.

Q : (외래 키가 없기 때문에) 많이 혼동됩니다! DWH에서 Fk를 여러 가지 이유로 (데이터 무결성, 의미 계층에 대한 관계 등) 갖는 것이 좋습니다 (필수 아님).

A : 맞습니다. 일반적으로 데이터웨어 하우스에 외래 키를 두는 것이 좋습니다. 그러나 클러스터형 columnstore 인덱스는 아직이를 지원하지 않습니다.

Q : MS는 DWH 시나리오에 대한 클러스터형 열 저장소 인덱스를 옹호하지만 FK 관계를 처리 할 수 ​​없습니까?!

A : Microsoft는 도구를 제공합니다. 이러한 도구를 사용하는 방법은 사용자에게 달려 있습니다.

가장 큰 문제는 데이터웨어 하우스의 데이터 무결성이 부족한 경우 외래 키가있는 기존 테이블입니다.

가장 큰 과제는 쿼리 성능이고로드 프로세스의 일부로 자체 데이터 무결성을 기꺼이 확인하려는 경우 원하는 도구는 열 저장소 인덱스를 클러스터링하는 것입니다.

Q : 그러나 SQL 2014는 DWH에 새로운 가치를 더하지 않습니다 ??

A : 다행히도 클러스터 된 columnstore는 SQL Server 2014의 유일한 새로운 기능은 아닙니다. 예를 들어, 새로운 카디널리티 추정기를 확인하십시오 .

Q : 내가 가장 좋아하는 기능이 구현 된 방식에 대해 왜 그렇게 화를 내고 괴로워합니까?

A : 당신은 저를 붙 잡았습니다 – 당신은 정말로 그 질문을하지 않았습니다 – 그러나 나는 그것에 대답 할 것입니다. 정확한 사양에 따라 모든 것이 구축되지 않은 타사 소프트웨어의 세계에 오신 것을 환영합니다. Microsoft 제품에서보고 싶은 변화에 대해 열정적으로 느끼는 경우 Connect.Microsoft.com을 확인하십시오 . 변경 사항을 제출하고 다른 사람이 투표 할 수있는 피드백 프로세스입니다. 그런 다음 제품 팀에서이를 읽고 구현하지 않는 이유를 알려줍니다. 때때로. 대부분의 경우 그들은 단지 "수정하지 않고 내 컴퓨터에서 작동합니다"라고 표시하지만 때로는 답변을 얻을 수도 있습니다.

나는 당신이 당신이 잃어버린 조각들을 느낀다는 것을 이해할 수 있습니다. 그러나 그것은 그들이 빠져 있기 때문입니다.

그럼에도 불구하고 외래 키가 제약 조건과 같은 물리적 구현이 아닌 개념 (당시 트리거를 통해 구현 된) 일 때 SQL Server가 성공적으로 사용되었습니다. 선언적 참조 무결성은 최소한 SQL Server 7.0에서 제공되었지만 현재 구현보다 훨씬 약합니다.

Clustered ColumnStore Index의 값과 관련하여 인덱스를 제공하고 행을 업데이트 할 수 있습니다. 이 토론은 가치가 있습니다. http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj는 클러스터링 키를 PK (테이블 / 뷰의 첫 번째 열)로하여이 테이블 위에 인덱스 / 머티리얼 라이즈 뷰를 생성 할 수있는 방법이 있다고 지적합니다. 물론 그것이 당신에게 맞는지 여부는 결정해야합니다.

그러나 Aaron Bertrand와 TomTom이 언급했듯이 이는 성능 향상에 관한 것입니다. 당신이 관심있는 다른 이슈들을 관리 할 수 ​​있다면 (그리고 그것들 이 다루기 쉽다고 믿는 다면) 당신은 꽤 많은 혜택을받습니다. 따라서 누락 된 기능을 직접 수행 하고 관리 할 수있는 작업 에는 ColumnStore를 사용 하십시오.

이 질문은 SQL 2014와 관련이 있지만 다른 버전의 제한 사항을 정렬하기가 어려울 수 있으며이 질문은 여전히 ​​Google에서 상당히 높아지기 때문에 SQL 2016에서 columnstore 인덱스에 대한 변경 사항을 고려하여 추가 정보를 제공하고 싶습니다.

SQL 2016의 경우 Microsoft는 클러스터되지 않은 btree 인덱스를 사용하여 (클러스터 된 columnstore 테이블에 보조 인덱스로 추가 할 수있는) 외래 키 제약 조건을 적용하는 방법에 대해 설명합니다 (컬럼 저장소 인덱스 전에 제약 조건이 추가 된 경우) : https : // docs .microsoft.com / ko-kr / sql / relational-databases / indexes / columnstore-indexes-design-guidance

Niko Neugebauer도 이에 관한 블로그 게시물을 보유하고 있습니다. 실제로 columnstore 테이블에 고유 / 외래 제약 조건을 직접 만들 수 있습니다 (저는이 작업 방식을 적용했습니다) : http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- SQL Server-2016-에서 클러스터링 된 더 많은 열 저장소 개선 /