xml 데이터 형식 및 열(SQL Server)

아티클
08/21/2023

적용 대상:SQL Server Azure SQL DatabaseAzure SQL Managed Instance

이 문서에서는 SQL Server에서 xml 데이터 형식의 장점과 제한 사항에 대해 설명하고 XML 데이터를 저장하는 방법을 선택하는 데 도움이 됩니다.

관계형 또는 XML 데이터 모델

데이터가 알려진 스키마로 고도로 구조화된 경우 관계형 모델은 데이터 스토리지에 가장 적합합니다. SQL Server는 필요한 기능과 도구를 제공합니다. 반면에 반구조화되어 있거나 구조화되지 않았거나 구조화 상태를 알 수 없는 경우에는 이러한 데이터의 모델링을 고려해야 합니다.

구조적 및 의미적 태그를 사용하여 데이터의 이동성을 보장하기 위해 플랫폼 독립적인 모델이 필요한 경우에는 XML이 좋은 대안입니다. 또한 XML은 다음과 같은 상황에서도 적절한 대안이 될 수 있습니다.

데이터가 스파스이거나 데이터의 구조를 모르거나 데이터 구조가 나중에 크게 변경될 수 있습니다.
데이터는 엔터티 간의 참조 대신 포함 계층 구조를 나타내며 재귀적일 수 있습니다.
순서는 데이터에 내재되어 있습니다.
구조에 따라 데이터를 쿼리하거나 데이터의 일부를 업데이트하려고 합니다.

이러한 조건이 충족되지 않는 경우 관계형 데이터 모델을 사용해야 합니다. 예를 들어 데이터가 XML 형식이지만 애플리케이션에서 데이터베이스를 사용하여 데이터를 저장하고 검색하는 경우 [n]varchar(max) 열만 있으면 됩니다. XML 열에 데이터를 저장하면 추가적인 이점이 있습니다. 여기에는 엔진이 데이터가 잘 구성되거나 유효한지 확인하고 XML 데이터에 대한 세분화된 쿼리 및 업데이트에 대한 지원도 포함됩니다.

SQL Server에 XML 데이터를 저장하는 이유

다음은 파일 시스템에서 XML 데이터를 관리하는 대신 SQL Server에서 네이티브 XML 기능을 사용하는 몇 가지 이유입니다.

효율적이고 실용적인 방식으로 XML 데이터를 공유, 쿼리 및 수정하고자 합니다. 세분화된 데이터 액세스는 애플리케이션에 중요합니다. 예를 들어 XML 문서 내의 일부 섹션을 추출하거나 전체 문서를 대체하지 않고 새 섹션을 삽입할 수 있습니다.
관계형 데이터와 XML 데이터가 있고 애플리케이션 내에서 관계형 데이터와 XML 데이터 간의 상호 운용성을 원합니다.
도메인 간 애플리케이션에 대한 쿼리 및 데이터 수정에 대한 언어 지원이 필요합니다.
서버에서 데이터가 제대로 구성되도록 보장하고 XML 스키마에 따라 선택적으로 데이터의 유효성을 검사하려고 합니다.
효율적인 쿼리 처리 및 확장성을 위해 XML 데이터를 인덱싱하고 일류 쿼리 최적화 프로그램을 사용하려고 합니다.
XML 데이터에 대한 SOAP, ADO.NET 및 OLE DB 액세스를 원합니다.
XML 데이터를 관리하기 위해 데이터베이스 서버의 관리 기능을 사용하려고 합니다. 예를 들어 이러한 기능에는 백업, 복구 및 복제가 포함될 수 있습니다.

이러한 상황에 하나도 해당되지 않으면 [n]varchar(max) 또는 varbinary(max)와 같은 비-XML의 큰 개체 형식으로 데이터를 저장하는 것이 좋습니다.

XML 스토리지 옵션

SQL Server의 XML에 대한 스토리지 옵션은 다음과 같습니다.

xml 데이터 형식의 네이티브 스토리지

데이터는 데이터의 XML 콘텐츠를 보존하는 내부 표현으로 저장됩니다. 이 내부 표현에는 포함 계층, 문서 순서 및 요소 및 특성 값에 대한 정보가 포함됩니다. 특히 XML 데이터의 InfoSet 내용이 보존됩니다. InfoSet에 대한 자세한 내용은 다음을 참조하세요 http://www.w3.org/TR/xml-infoset. InfoSet 콘텐츠는 다음과 같은 정보가 유지되지 않으므로 텍스트 XML의 동일한 복사본이 아닐 수 있습니다. 사소한 공백, 특성 순서, 네임스페이스 접두사 및 XML 선언입니다.

XML 스키마에 바인딩된 xml 데이터 형식인 형식화된 xml 데이터 형식의 경우 PSVI(사후 스키마 유효성 검사 InfoSet)는 InfoSet에 형식 정보를 추가하고 내부 표현으로 인코딩됩니다. 이렇게 하면 구문 분석 속도가 크게 향상됩니다. 자세한 내용은 W3C XML 스키마 사양을 http://www.w3.org/TR/xmlschema-1 참조하세요 http://www.w3.org/TR/xmlschema-2.
XML과 관계형 스토리지 간의 매핑

주석이 추가된 스키마(AXSD)를 사용하면 XML이 하나 이상의 테이블의 열로 분해됩니다. 이렇게 하면 관계형 수준에서 데이터의 충실도가 유지됩니다. 따라서 요소 간의 순서는 무시되지만 계층 구조는 유지됩니다. 스키마는 재귀적일 수 없습니다.
큰 개체 스토리지 [n]varchar(max) 및 varbinary(max)

동일한 데이터 복사본이 저장됩니다. 이는 법률 문서와 같은 특수 용도의 애플리케이션에 유용합니다. 대부분의 애플리케이션은 정확한 복사가 필요하지 않으며 XML 콘텐츠(InfoSet 충실도)에 만족합니다.

일반적으로 이러한 방법의 조합을 사용해야 할 수 있습니다. 예를 들어 XML 데이터 형식 열에 XML 데이터를 저장하고 XML 데이터 형식 열에서 관계형 열로 속성을 승격할 수 있습니다. 또는 매핑 기술을 사용하여 비 XML 열에 비귀적 파트를 저장하고 xml 데이터 형식 열에 재귀 부분만 저장할 수 있습니다.

XML 기술 선택

XML 기술( 네이티브 XML 및 XML 뷰)의 선택은 일반적으로 다음 요인에 따라 달라집니다.

스토리지 옵션

XML 데이터는 큰 개체 스토리지(예: 제품 설명서)에 더 적합하거나 관계형 열의 스토리지에 더 적합할 수 있습니다(예: XML로 변환된 품목). 각 스토리지 옵션은 문서 충실도를 다른 범위로 유지합니다.
쿼리 기능

쿼리의 특성 및 XML 데이터를 쿼리하는 정도에 따라 하나의 스토리지 옵션이 다른 스토리지 옵션보다 더 적합할 수 있습니다. XML 데이터의 세분화된 쿼리(예: XML 노드에 대한 조건자 평가)는 두 스토리지 옵션에서 다양한 각도로 지원됩니다.
XML 데이터 인덱싱

XML 데이터를 인덱싱하여 XML 쿼리 성능 속도를 높일 수 있습니다. 인덱싱 옵션은 스토리지 옵션에 따라 다릅니다. 워크로드를 최적화하려면 적절한 선택을 해야 합니다.
데이터 수정 기능

일부 워크로드에는 XML 데이터의 세분화된 수정이 포함됩니다. 예를 들어 여기에는 문서 내에 새 섹션을 추가하는 작업이 포함될 수 있지만 웹 콘텐츠와 같은 다른 워크로드는 추가하지 않습니다. 데이터 수정 언어 지원은 애플리케이션에 중요할 수 있습니다.
스키마 지원

XML 데이터를 스키마에 의해 기술할 수 있으며 이러한 스키마는 XML 스키마 문서일 수도 혹은 아닐 수도 있습니다. 스키마 바인딩된 XML에 대한 지원은 XML 기술에 따라 달라집니다.

선택한 옵션에 따라 성능 특성이 달라집니다.

네이티브 XML 스토리지

XML 데이터를 서버의 xml 데이터 형식 열에 저장할 수 있습니다. 다음이 적용되는 경우 적절한 선택입니다.

서버에 XML 데이터를 저장하고 동시에 문서 순서 및 문서 구조를 보존할 수 있는 직관적인 방식이 필요합니다.
XML 데이터에 대한 스키마가 있거나 없습니다.
XML 데이터를 쿼리하고 수정하려고 합니다.
신속한 쿼리 처리를 위해 XML 데이터를 인덱싱해야 합니다.
XML 데이터 및 XML 스키마를 관리하려면 애플리케이션에 시스템 카탈로그 뷰가 필요합니다.

네이티브 XML 스토리지는 구조 범위가 포함된 XML 문서가 있거나 관계형 구조로 매핑하기 어려운 여러 스키마 또는 복잡한 스키마에 해당하는 XML 문서가 있는 경우에 유용합니다.

예: xml 데이터 형식을 사용하여 XML 데이터 모델링

각 항목에 대한 별도의 장으로 구성되어 있고 각 장 내에 여러 섹션이 포함된 XML 형식의 제품 설명서를 가정해 보십시오. 섹션에는 하위 섹션이 포함될 수 있습니다. 따라서 <section>은 재귀적 요소입니다. 제품 설명서에는 다량의 콘텐츠, 다이어그램 및 기술 자료가 혼합되어 있으며 데이터는 반구조적입니다. 사용자는 "인덱싱" 장에서 "클러스터형 인덱스" 섹션을 검색하는 것과 같이 원하는 항목을 문맥에 따라 검색하고 많은 기술 자료를 쿼리할 수 있습니다.

XML 문서에 적합한 스토리지 모델은 xml 데이터 형식 열입니다. 이렇게 하면 XML 데이터의 InfoSet 콘텐츠가 유지됩니다. XML 열을 인덱싱하면 쿼리 성능이 향상됩니다.

예: XML 데이터의 정확한 복사본 유지

예를 들어 정부 규정에 따라 XML 문서의 정확한 텍스트 복사본을 유지해야 하는 것으로 가정합니다. 예를 들어 서명된 문서, 법적 문서 또는 주식 거래 주문이 포함될 수 있습니다. 문서를 [n]varchar(max) 열에 저장할 수 있습니다.

쿼리의 경우 런타임에 데이터를 xml 데이터 형식으로 변환하고 XQuery를 실행합니다. 런타임 변환은 특히 문서가 큰 경우 비용이 많이 들 수 있습니다. 자주 쿼리하는 경우 [n]varchar(max) 열에서 정확한 문서 복사본을 반환하는 동안 문서를 xml 데이터 형식 열에 중복으로 저장하고 인덱싱할 수 있습니다.

XML 열은 [n]varchar(max) 열을 기반으로 계산 열일 수 있습니다. 그러나 계산된 XML 열에는 XML 인덱스를 만들 수 없으며 [n]varchar(max) 또는 varbinary(max) 열에 XML 인덱스를 작성할 수도 없습니다.

XML 보기 기술

XML 스키마와 데이터베이스의 테이블 간의 매핑을 정의하여 영구 데이터의 XML 뷰를 만듭니다. XML 대량 로드를 사용하면 XML 뷰를 사용하여 기본 테이블을 채울 수 있습니다. XPath 버전 1.0을 사용하여 XML 뷰를 쿼리할 수 있습니다. 쿼리는 테이블의 SQL 쿼리로 변환됩니다. 마찬가지로 업데이트도 해당 테이블로 전파됩니다.

이 기술은 다음과 같은 경우 유용합니다.

기존 관계형 데이터에 대해 XML 뷰를 사용하는 XML 중심 프로그래밍 모델을 갖고자 합니다.
외부 파트너가 제공한 XML 데이터에 대한 스키마(XSD, XDR)가 있습니다.
순서는 데이터에서 중요하지 않거나 쿼리 테이블 데이터가 재귀적이지 않거나 최대 재귀 깊이를 미리 알고 있습니다.
XPath 버전 1.0을 사용하여 XML 뷰를 통해 데이터를 쿼리하고 수정하려고 합니다.
XML 뷰를 사용하여 XML 데이터를 대량 로드하고 기본 테이블로 분해하려고 합니다.

이러한 예로는 데이터 교환 및 웹 서비스에 대해 XML로 제공된 관계형 데이터와 고정 스키마가 포함된 XML 데이터가 있습니다. 자세한 내용은

예: 주석이 추가된 XML 스키마를 사용하여 데이터 모델링(AXSD)

이해를 돕기 위해 고객, 주문 및 라인 항목 등과 같은 기존 관계형 데이터가 있고 이를 XML로 처리하려는 경우를 가정해 보십시오. 관계형 데이터에 대해 AXSD를 사용하여 XML 뷰를 정의합니다. XML 뷰를 사용하면 XML 뷰를 사용하여 XML 데이터를 테이블에 대량 로드하고 관계형 데이터를 쿼리하고 업데이트할 수 있습니다. 이 모델은 SQL 애플리케이션이 중단 없이 작동하는 동안 XML 태그가 포함된 데이터를 다른 애플리케이션과 교환해야 하는 경우에 유용합니다.

하이브리드 모델

관계형 및 xml 데이터 형식의 열을 조합하면 데이터 모델링에 적합한 경우가 많습니다. XML 데이터의 일부 값은 관계형 열에 저장하고 나머지 값이나 전체 XML 값은 XML 열에 저장할 수 있습니다. 이렇게 하면 관계형 열 및 잠금 특성에서 만든 인덱스를 더 잘 제어할 수 있으므로 성능이 향상됩니다.

관계형 열에 저장할 값은 워크로드에 따라 달라집니다. 예를 들어 경로 식을 /Customer/@CustId기반으로 모든 XML 값을 검색하는 경우 특성 값을 CustId 관계형 열로 승격하고 인덱싱하면 쿼리 성능이 더 빨라질 수 있습니다. 반면에 XML 데이터가 광범위하고 무분별하게 관계형 열로 분해되는 경우 재조립 비용이 상당할 수 있습니다.

예를 들어 구조화 수준이 높은 XML 데이터의 경우 테이블의 내용이 XML로 변환되어 모든 값을 관계형 열로 매핑하고 XML 뷰 기술을 사용할 수 있습니다.

XML 데이터의 세분성

XML 열에 저장된 XML 데이터의 세분성은 잠금에 중요하며, 업데이트에도 중요합니다. SQL Server는 XML 및 비 XML 데이터에 대해 동일한 잠금 메커니즘을 사용합니다. 따라서 행 수준 잠금으로 인해 행의 모든 XML 인스턴스가 잠깁니다. 세분성이 큰 경우 업데이트를 위해 큰 XML 인스턴스를 잠그면 다중 사용자 환경에서 처리량이 줄어듭니다. 반면에 심각한 분해로 인해 개체 캡슐화가 손실되고 재조립 비용이 증가합니다.

데이터 모델링 요구 사항과 잠금 및 업데이트 특성 간의 균형은 훌륭한 디자인을 위해 중요한 요소입니다. 그러나 SQL Server에서 실제 저장된 XML 인스턴스의 크기는 중요하지 않습니다.

예를 들어 XML 인스턴스에 대한 업데이트는 BLOB(Partial Binary Large Object) 및 기존 저장된 XML 인스턴스가 업데이트된 버전과 비교되는 부분 인덱스 업데이트에 대한 새 지원을 사용하여 수행됩니다. BLOB(Partial Binary Large Object) 업데이트는 두 XML 인스턴스 간의 차등 비교를 수행하고 차이점만 업데이트합니다. 부분적 인덱스 업데이트는 XML 인덱스에서 변경되어야 하는 행만 수정합니다.

xml 데이터 형식의 제한 사항

다음의 일반적인 제한 사항이 xml 데이터 형식에 적용됩니다.

xml 데이터 형식 인스턴스의 저장된 표현은 2GB를 초과할 수 없습니다.
sql_variant 인스턴스의 하위 형식으로 사용할 수 없습니다.
텍스트 또는 ntext로 캐스팅 또는 변환을 지원하지 않습니다. 대신 varchar(max) 또는 nvarchar(max)를 사용합니다.
비교하거나 정렬할 수 없습니다. 즉, XML 데이터 형식은 GROUP BY 문에서 사용할 수 없습니다.
ISNULL, COALESCE 및 DATALENGTH 이외의 스칼라 기본 제공 함수에 대한 매개 변수로 사용할 수 없습니다.
인덱스의 키 열로 사용할 수 없습니다. 그러나 클러스터형 인덱스로 데이터로 포함되거나 비클러스터형 인덱스가 만들어질 때 INCLUDE 키워드를 사용하여 비클러스터형 인덱스로 명시적으로 추가할 수 있습니다.
XML 요소는 최대 128개 수준까지 중첩할 수 있습니다.

참고 항목

XML 문서 대량 가져오기 및 내보내기 예(SQL Server)