내보내기(0) 인쇄
모두 확장

Windows Azure 테이블 저장소 및 Windows Azure SQL 데이터베이스 - 비교 및 대조

업데이트 날짜: 2014년 1월

작성자: Valery Mizonov, Seth Manheim

검토자: Brad Calder, Jai Haridas, Paolo Salvatori, Silvano Coriani, Prem Mehra, Rick Negrin, Stuart Ozer, Michael Thomassy, Ewan Fairweather

이 항목에서는 에서 지원하는 두 가지 유형의 구조적 저장소인 테이블 저장소와 이전에 “SQL Azure”로 알려진 Microsoft Azure SQL 데이터베이스를 비교합니다. 이 문서의 목적은 이 두 기술을 비교하여 두 기술의 비슷한 점과 차이점을 설명하는 것입니다. 이러한 분석은 특정 요구 사항에 가장 적합한 기술을 보다 합리적으로 결정하는 데 도움이 될 수 있습니다.

데이터 저장소 및 지속성 옵션을 고려할 때 는 두 가지 클라우드 기반 기술인 Microsoft Azure SQL 데이터베이스 및 테이블 저장소를 제공합니다.

Microsoft Azure SQL 데이터베이스 는 핵심 SQL Server 기능을 클라우드로 확장하는 관계형 데이터베이스 서비스입니다. Azure SQL 데이터베이스를 사용하면 클라우드에 관계형 데이터베이스 솔루션을 프로비전 및 배포할 수 있습니다. SQL Azure는 관리되는 인프라, 높은 가용성, 확장성, 친숙한 개발 모델, 데이터 액세스 프레임워크 및 도구 등의 이점을 제공합니다. 이러한 이점은 기존 SQL Server 환경의 이점과 유사합니다. 또한 Azure SQL 데이터베이스는 마이그레이션, 내보내기 및 Windows Azure SQL 데이터베이스와 내부 SQL Server 데이터베이스의 동기화(SQL 데이터 동기화를 통해)를 가능하게 하는 기능을 제공합니다.

테이블 저장소는 내결함성이 있는 ISO 27001 인증 NoSQL 키 값 저장소입니다. 테이블 저장소는 많은 양의 비관계형 데이터를 저장해야 하고 이러한 데이터에 대한 추가 구조를 필요로 하는 응용 프로그램에 유용할 수 있습니다. 테이블은 단순화된 데이터 액세스 패턴을 통해 응용 프로그램에 대한 낮은 비용으로 스키마화되지 않은 데이터에 대한 키 기반 액세스를 제공합니다. 테이블 저장소는 스키마가 없는 구조적 데이터를 저장하지만 이러한 데이터 간의 관계를 표시할 수 있는 방법을 제공하지 않습니다.

몇 가지 중요한 차이점에도 불구하고 Microsoft Azure SQL 데이터베이스 및 테이블 저장소는 둘 다 월별 SLA가 99.9%인 가용성이 높은 관리되는 서비스입니다.

Azure SQL 데이터베이스와 마찬가지로 테이블 저장소도 구조적 데이터를 저장합니다. Azure SQL 데이터베이스와 테이블 저장소의 주요 차이점은 Azure SQL 데이터베이스는 SQL Server 엔진을 기반으로 하고 표준 관계형 보안 주체 및 사례를 기반으로 빌드된 관계형 데이터베이스 관리 시스템이라는 점입니다. 따라서 SQL Azure는 Transact-SQL 쿼리, ACID 트랜잭션 또는 서버 쪽에서 실행되는 저장 프로시저를 통해 관계형 데이터 관리 기능을 제공합니다.

테이블 저장소는 응용 프로그램 데이터 모델을 특정 스키마 집합으로 고정하지 않고 클라우드 응용 프로그램을 손쉽게 빌드할 수 있는 유연한 키/값 저장소입니다. 또한 관계형 데이터 저장소가 아니므로 Azure SQL 데이터베이스와 동일한 관계형 데이터 관리 기능(예: 조인 및 저장 프로시저)을 제공하지 않습니다. 테이블 저장소는 서버 쪽 쿼리를 제한적으로 지원하지만 트랜잭션 기능은 제공합니다. 또한 테이블 저장소에서는 동일한 테이블 내의 여러 행이 여러 구조로 되어 있을 수 있습니다. 또한 테이블의 이 스키마 없음 속성을 사용하면 단순 관계형 데이터를 효율적으로 저장하고 검색할 수 있습니다.

응용 프로그램에서 많은 관계형 기능이 필요 없는 큰 데이터 집합을 저장하고 검색하는 경우에는 테이블 저장소가 더 적합할 수 있습니다. 응용 프로그램이 기본적으로 관계형이고 스키마화된 데이터 집합을 통해 데이터를 처리해야 하는 경우에는 Azure SQL 데이터베이스가 더 적합할 수 있습니다. Azure SQL 데이터베이스와 테이블 저장소 중에서 결정하기 전에 고려해야 할 몇 가지 다른 요인이 있습니다. 다음 섹션에는 이러한 고려 사항 중 일부가 나열되어 있습니다.

지정된 솔루션의 목적에 맞는 데이터 저장소 기술을 결정할 때 솔루션 설계자 및 개발자는 다음과 같은 권장 사항을 고려해야 합니다.

다음과 같은 경우 솔루션 설계자/개발자는 테이블 저장소 사용을 고려해야 합니다.

  • 응용 프로그램에서 비용은 낮추는 반면 매우 큰 데이터 볼륨(여러 테라바이트로 표시됨)을 저장해야 하는 경우

  • 응용 프로그램이 큰 데이터 집합을 저장 및 검색하고, 서버 쪽 조인, 보조 인덱스 또는 복잡한 서버 쪽 논리가 필요한 복잡한 관계를 포함하고 있지 않은 경우

  • 디자인 타임에 구조를 알 수 없는 비균일 개체를 저장할 수 있는 유연한 데이터 스키마가 응용 프로그램에 필요한 경우

  • 업무상 특정 규정 준수 요구 사항을 충족하기 위해 지리적으로 떨어진 여러 위치에서 재해 복구 기능이 필요한 경우. 테이블은 같은 대륙 내에서 서로 수백 킬로미터 떨어져 있는 두 데이터 센터 간에 지역 간 복제됩니다. 이러한 복제는 주요 재해 시 추가적인 데이터 지속성을 제공합니다.

  • 분할 논리를 구현하지 않고도 150GB 이상의 데이터를 저장해야 하는 경우

  • 수동으로 데이터 집합을 분할하지 않고도 높은 수준의 확장성을 달성해야 하는 경우

다음과 같은 경우 솔루션 설계자/개발자는 Microsoft Azure SQL 데이터베이스 사용을 고려해야 합니다.

  • 응용 프로그램에서 관계로 복잡하게 구조화된 스키마 데이터 집합을 처리해야 하는 경우

  • 데이터가 기본적으로 관계형이고, 데이터 고유성 규칙, 참조 제약 조건 및 기본 또는 외래 키를 사용하여 무결성을 적용하기 위해 관계형 데이터 프로그래밍 모델의 기본 보안 주체를 필요로 하는 경우

  • 데이터 볼륨이 종종 단일 데이터베이스라고도 하는 함께 배치된 데이터 집합의 단일 단위당 150GB를 초과할 수 없지만 여러 집합 간에 데이터를 분할하여 이 명시된 제한을 초과할 수 있는 경우. 이러한 제한은 나중에 변경될 수 있습니다.

  • 기존 데이터 중심 응용 프로그램에서 SQL Server를 이미 사용하고 있고 클라우드에서 기존 데이터 액세스 프레임워크를 사용하여 구조적 데이터에 액세스해야 하는 동시에 응용 프로그램에서 내부와 간의 원활한 이식을 필요로 하는 경우

  • 응용 프로그램이 T-SQL 저장 프로시저를 활용하여 데이터 계층 내에서 계산을 수행할 계획이어서 응용 프로그램과 데이터 저장소 간의 왕복이 최소화되는 경우

  • 응용 프로그램이 조인, 집계 및 복잡한 조건자가 포함된 일관성 있는 쿼리 의미 체제를 통해 공간 데이터, 다양한 데이터 형식 및 복잡한 데이터 액세스 패턴에 대한 지원을 필요로 하는 경우

  • 응용 프로그램에서 즉시 사용 가능한 보고 도구를 사용하여 데이터 모델을 통해 시각화 및 BI(비즈니스 인텔리전스) 보고를 제공해야 하는 경우

note참고
이 두 기술은 다양한 응용 프로그램에서 사용될 수 있으므로 이 두 기술의 조합을 사용하는 것이 좋습니다.

다음 섹션에 나오는 표에서는 기능을 논리적으로 그룹화하고 테이블 저장소와 Microsoft Azure SQL 데이터베이스에서 제공하는 기능을 한 눈에 비교할 수 있습니다.

이 섹션에서는 테이블 저장소와 Azure SQL 데이터베이스가 제공하는 몇 가지 기본 저장소 기능을 비교합니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

데이터 관계

아니요

테이블 저장소에서는 데이터 간의 관계를 표시할 수 없습니다. 테이블의 스키마 없음 속성을 사용하고 데이터를 필요한 형식으로 구조화하여 간단한 관계만 표시할 수 있습니다.

SQL Server와 마찬가지로 Azure SQL 데이터베이스에서는 외래 키를 사용하여 서로 다른 테이블에 저장된 데이터 간의 관계를 정의할 수 있습니다.

서버 쪽 처리

아니요

insert, update, delete, select 등과 같은 기본 작업은 지원하지만 저장소 엔진 쪽의 조인, 외래 키, 저장 프로시저, 트리거 또는 처리는 지원하지 않습니다.

저장 프로시저, 보기, 다중 인덱스, 조인, 집계 등과 같은 표준 SQL Server 기능을 제공합니다.

트랜잭션 지원

제한됨

동일한 테이블 및 동일한 파티션의 엔터티에 대한 트랜잭션을 지원합니다. 최대 100개의 작업이 트랜잭션에서 지원됩니다. 낙관적 동시성을 지원합니다. 자세한 내용은 TechNet의 엔터티 그룹 트랜잭션.

동일한 데이터베이스 내에서의 일반적인 ACID 트랜잭션을 지원합니다. 트랜잭션은 데이터베이스 전체에서 지원되지 않습니다. Azure SQL 데이터베이스에서도 낙관적 동시성을 지원합니다.

지역 간 복제

기본적으로 테이블은 다른 지역으로 복제됩니다. 이 복제는 높은 수준의 재해 복구 기능을 제공합니다.

아니요

이 문서를 작성하는 당시에는 Azure SQL 데이터베이스 인스턴스가 다른 지역에 복제되지 않습니다. 이 동작은 나중에 변경될 수 있습니다.

테이블 스키마

완화됨

각 엔터티(행)는 서로 다른 속성을 가질 수 있습니다. 예를 들어 동일한 테이블에서는 한 행에는 주문 정보를 저장하고 다른 행에는 고객 정보를 저장할 수 있습니다.

관리됨

정의된 경우 전체 테이블의 고정 스키마이지만 언제든지 변경할 수 있습니다. 모든 행은 스키마 규칙을 준수해야 합니다. 보다 나은 유연성을 위해 XML 유형 또는 스파스 열을 사용할 수 있습니다.

내부에서 사용되는 기존 데이터 저장소와의 유사성

아니요

현재 내부 대안이 없는 클라우드 기반 저장소입니다.

일부 제한이 있는 SQL Server와 유사합니다. 자세한 내용은 TechNet의 일반 지침 및 제한 사항.

확장

자동

PartitionKey 속성을 기반으로 분할됩니다. 테이블은 여러 저장소 장치의 여러 파티션에 저장할 수 있습니다. 이 구조를 사용하면 클라이언트가 데이터에 병렬로 액세스할 수 있습니다.

수동

SQL 페더레이션 또는 사용자 지정 분할 방법을 사용하여 데이터베이스 인스턴스의 관리 그룹 전체에서 분할됩니다.

데이터 형식

단순

지원 되는 데이터 형식에 대한 자세한 내용은 "추가 정보" 섹션의 표를 참조하십시오.

단순, 복합 및 사용자 정의

Azure SQL 데이터베이스는 사용자 정의 형식을 비롯한 다양한 데이터 형식을 지원합니다.

  • 테이블을 만들 때 열을 정의하지 않아도 됩니다. 테이블 자체가 구조화되지 않고 디자인 타임 스키마를 포함하지 않습니다. 열 이름은 테이블에 저장되는 엔터티(행)의 일부이며 단일 테이블 내의 엔터티에 따라 다를 수 있습니다. 테이블에는 속성 이름은 같지만 속성 값의 유형이 다른 두 개의 엔터티가 있을 수 있습니다. 그러나 단일 엔터티 내에서는 속성 이름이 고유해야 합니다.

  • 테이블 저장소는 여러 테이블 간의 수정 사항을 조정하는 쿼리 또는 트랜잭션에서 조인 및 집계와 같은 관계형 기능을 지원하지 않습니다. 동일한 파티션 키를 사용하여 테이블에 저장되는 엔터티는 저장소에 함께 제공됩니다. 이러한 엔터티는 효율적으로 검색할 수 있으며, 엔터티 그룹 트랜잭션을 사용하여 단일 요청으로 수정할 수 있습니다.

  • 엔터티 그룹 트랜잭션을 사용할 때는 몇 가지 제한 사항을 알고 있어야 합니다. 이러한 제한 사항으로는 최대 일괄 처리 크기가 4MB이라는 것과 일괄 처리 내의 모든 엔터티가 동일한 파티션 키 값을 공유해야 한다는 것이 있습니다. 자세한 내용은 TechNet의 이 문서.

  • 테이블 저장소 유형은 하나의 클러스터형 인덱스를 제공하고 결과는 항상 PartitionKeyRowKey를 기준으로 오름차순으로 정렬됩니다. PartitionKeyRowKey 값은 테이블에서 행을 고유하게 식별합니다. 동일한 PartitionKeyRowKey를 가진 두 개의 행을 만들려고 하면 예외가 생성됩니다.

  • 이 문서에서는 Azure SQL 데이터베이스와 내부 SQL Server 중에서 선택할 때 사용할 수 있는 의사 결정 트리를 제공합니다. 이러한 의사 결정 기준은 Azure SQL 데이터베이스와 테이블 저장소 중에서 선택할 때도 적용할 수 있습니다.

  • 두 기술에 적용되는 처리량 조건은 많은 변수가 있는 복잡한 방정식입니다. 이러한 요인으로는 쿼리 유형, 쿼리의 복잡성, 데이터 액세스 패턴, 결과 집합 크기, 저장소 인프라와의 접근성 및 네트워크 대기 시간이 있습니다. 응용 프로그램의 특정 클래스에 대한 개별 특성을 고려할 때 관련 지표를 측정하려면 항상 자체 성능 테스트를 수행하는 것이 좋습니다. Windows Azure 테이블에 대한 최선의 구현 방법에 대한 자세한 내용은 이 블로그 게시물을 참조하십시오.

  • 다음 표에서는 테이블의 속성 값에 대해 지원되는 데이터 형식을 보여 줍니다. Azure SQL 데이터베이스에서 지원하는 데이터 형식의 목록을 보려면 데이터 형식(Azure SQL 데이터베이스)을 참조하십시오.

     

    속성 유형 세부 정보

    이진

    최대 크기가 64KB인 바이트 배열입니다.

    Bool

    부울 값입니다.

    DateTime

    UTC 시간으로 표시되는 64비트 값입니다. 지원되는 값 범위는 1/1/1601에서 12/31/9999 사이입니다.

    Double

    64비트 부동 소수점 값입니다.

    GUID

    128비트 GUID(Globally Unique Identifier)입니다.

    Int

    32비트 정수입니다.

    Int64

    64비트 정수입니다.

    문자열

    UTF-16으로 인코딩된 값입니다. 문자열 값의 최대 크기는 64KB입니다.

이 섹션에서는 테이블 저장소와 Azure SQL 데이터베이스에서 제공하는 고급 기능을 비교합니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

내부 응용 프로그램 또는 비 플랫폼에 호스팅된 응용 프로그램에서 액세스할 수 있습니다.

일관성 모델

강력

강력

WCF(Windows Communication Foundation) 데이터 서비스 클라이언트 지원

REST 클라이언트 지원

기본적으로 REST 기반 액세스를 지원합니다.

SQL 데이터베이스 위에 OData 계층을 추가하여 REST 기반 액세스를 지원합니다.

방화벽 보호(제한된 IP 범위 액세스)

아니요

명령줄 도구를 사용하거나 포털에서 구성할 수 있는 Windows Azure 방화벽을 사용합니다.

트랜잭션 제한 동작

자세한 내용은 TechNet의 이 블로그 게시물.

자세한 내용은 TechNet의 이 문서.

내결함성

높은 수준의 내결함성을 제공하기 위해 저장된 데이터가 동일한 지역 내에서 3회 복제되고 644킬로미터 이상 떨어진 다른 지역으로 추가로 3회 복제됩니다.

이러한 Azure SQL 데이터베이스 인스턴스 복사본은 선택한 데이터 센터 내에서 유지됩니다.

로깅 및 메트릭

자세한 내용은 TechNet의 이 블로그 게시물.

아니요

트랜잭션 로그

아니요

트랜잭션 로그의 최대 크기는 10GB이며, 트랜잭션당 1GB로 제한됩니다.

  • 기본 제공 방화벽 기능을 사용하여 네트워크 수준에서 Azure SQL 데이터베이스 인스턴스에 대한 액세스를 제한할 수 있습니다. 또한 포털을 통해 방화벽 액세스 규칙을 구성할 수도 있습니다. 반면에 HTTP/HTTPS를 통해 저장소 계정 끝점에 액세스할 수 있는 모든 클라이언트는 테이블에 액세스할 수 있습니다.

  • 테이블 저장소는 테이블의 단일 엔터티에 대한 모든 삽입/업데이트/삭제 트랜잭션 및 엔터티 그룹 트랜잭션에 대해 ACID 트랜잭션 보증을 제공합니다. 서비스에 대한 각 단일 쿼리 요청에 대해서는 스냅숏 격리가 제공됩니다. 쿼리는 쿼리가 시작될 때부터 트랜잭션이 끝날 때까지 파티션의 일관된 뷰를 유지합니다. 응용 프로그램 개발자는 여러 테이블 간에 일관성을 유지할 책임이 있습니다.

  • 테이블은 서비스에 대해 수행되는 모든 요청을 확인할 수 있도록 함으로써 로깅을 지원합니다. 또한 로깅은 서비스에 대한 요청의 집계 메트릭을 제공합니다.

  • Microsoft Azure SQL 데이터베이스는 현재 로깅 및 메트릭을 제공하지 않지만 DMV(동적 관리 뷰)의 하위 집합을 제공합니다. DMV를 사용하면 쿼리 성능 문제를 진단하고, 데이터베이스 연결을 모니터링하고, 활성 트랜잭션을 보고, 쿼리 계획을 검사할 수 있습니다.

  • Microsoft Azure SQL 데이터베이스가 SQL Server 엔진 위에 빌드되었으므로 TempDB 및 트랜잭션 로그와 같은 일부 개념은 아직도 관련성이 있습니다. 트랜잭션 로그 파일이 갑자기 커지는 것을 방지하기 위해 Azure SQL 데이터베이스는 로그 크기를 10GB로 제한합니다. Azure SQL 데이터베이스 인프라는 사용자가 직접 액세스할 수 없는 이러한 트랜잭션 로그를 관리합니다. 트랜잭션 저장소에는 트랜잭션 로그에 해당하는 것이 없습니다. 테이블 저장소에서 지원하는 로깅 및 메트릭 기능은 수정할 실제 데이터가 아니라 서비스에 대한 요청을 추적하므로 트랜잭션 로깅과 다릅니다.

  • 다중 테넌트 환경에서 리소스의 과도한 사용을 방지하기 위해 테이블 저장소와 Azure SQL 데이터베이스는 둘 다 시스템 임계값을 제어하는 메커니즘을 사용합니다. 이 메커니즘을 제한이라고 하며, 해당 동작은 두 서비스 간에 다릅니다. 예를 들어 Azure SQL 데이터베이스는 두 가지 제한 전략인 소프트 제한하드 제한을 사용합니다. 이러한 제한 메커니즘은 이 문서에서 자세히 설명합니다.

이 섹션에서는 적용 가능한 용량 및 할당량 관점에서 테이블 저장소와 Azure SQL 데이터베이스를 비교합니다. 여기에 표시된 모든 용량과 할당량은 나중에 변경될 수 있습니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

최대 행 크기

1MB

세 가지 필수 속성인 PartitionKey, RowKeyTimestamp를 비롯하여 255개 미만의 속성이 있습니다.

2GB

최대 1024개의 열을 포함할 수 있습니다. 스파스 열을 사용할 경우 30,000개까지 포함할 수 있습니다. varchar(max), varbinary(max), xml, text 또는 image 열을 사용하면 최대 2GB의 행 외부 저장소가 제공됩니다.

최대 데이터 크기

테이블당 200TB

2012년 6월 8일이나 그 후에 만들어진 단일 저장소 계정(테이블, Blob 및 큐 포함)은 최대 200TB의 Blob, 큐 및 테이블 데이터를 포함할 수 있습니다. 그 전에 만들어진 저장소 계정의 경우 총 용량은 100TB입니다. 따라서 테이블의 최대 크기는 200TB입니다.

데이터베이스당 150GB

허용되는 최대 데이터베이스 크기가 나중에 증가할 수 있지만 SQL 페더레이션(또는 사용자 지정 분할)을 사용하여 더 큰 데이터 집합을 저장하는 것이 좋습니다.

쿼리당 검색되는 최대 행 수

1,000

1, 000개 미만의 행 (엔터티)가 단일 요청에 대한 응답으로 반환됩니다. 쿼리에 이 양보다 많은 결과가 포함될 경우 쿼리가 추가 요청을 계속 처리할 수 있도록 연속 토큰이 반환됩니다.

제한 없음

올바르게 조정되지 않은 경우 연결 및 쿼리 시간 제한이 일출되는 행 수를 제한할 수 있습니다.

  • 테이블 저장소는 응답 헤더에 있는 연속 토큰을 사용하여 쿼리에 대한 추가 결과가 있음을 나타냅니다. 연속 토큰으로 매개 변수화된 다른 요청을 실행하여 이러한 요청을 검색할 수 있습니다. 이 경우 제한된 엔터티 수인 1,000개를 넘는 항목을 검색할 수 있습니다. 스냅숏 일관성은 각 요청에 대해서는 유지되지만 쿼리에 대한 연속 토큰 요청 간에는 유지되지 않습니다.

  • 테이블 행(엔터티)에 있는 모든 필드(속성)의 결합된 크기는 1MB를 초과할 수 없습니다. 이 제한은 속성 값 또는 속성 값 유형뿐 아니라 속성 이름 크기에도 적용됩니다. 이러한 속성에는 두 개의 필수 키 속성(PartitionKeyRowKey)이 포함됩니다.

  • Azure SQL 데이터베이스는 현재 웹 버전에서는 최대 5GB의 데이터베이스를 지원하고 비즈니스 버전에서는 최대 150GB의 데이터베이스를 지원합니다. 지정된 임계값 내에서 데이터베이스 크기를 유지하기 위해 데이터베이스를 모니터링해야 하는 것은 관리자의 책임입니다. Azure SQL 데이터베이스 최대 크기는 관리 작업을 통해 미리 구성되며 저장된 데이터 볼륨이 커져도 자동으로 증가하지 않습니다. 자세한 내용은 TechNet의 Azure SQL 데이터베이스 설명서의 ALTER DATABASE(Azure SQL 데이터베이스).

  • 내부 SQL Server와 마찬가지로 일반 Azure SQL 데이터베이스 테이블의 열 수는 1024개로 제한됩니다. 스파스 열을 사용할 경우 테이블에 최대 30,000개의 열이 포함될 수 있으며, 이 중 스파스가 아닌 열은 1023개까지 포함될 수 있습니다. 그러나 적어도 28,976개는 스파스 열이어야 합니다. 총 열 개수가 1024개 이상일 경우 필수 열 집합에 대해 하나의 비스파스 열이 사용됩니다.

이 섹션에서는 테이블 저장소 및 Azure SQL 데이터베이스에서 제공하는 관리 기능을 비교합니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

관리 프로토콜 및 도구

REST over HTTP/HTTPS

Windows Azure 저장소 탐색기 또는 다른 타사 도구(예: Cloud Storage Studio)를 사용할 수 있습니다.

ODBC/JDBC

REST over HTTP/HTTPS

관리 포털 도는 SQL Server Management Studio를 사용하여 Azure SQL 데이터베이스 인스턴스를 관리할 수 있습니다.

데이터 액세스

OData 프로토콜 인터페이스

Windows Azure SDK에 포함된 WCF 데이터 서비스용 .NET 클라이언트 라이브러리 또는 HTTP(S) REST API를 사용하여 데이터에 액세스할 수 있습니다.

ODBC/JDBC

SQL Server와 통신하는 ADO.NET 및 ODBC와 같은 기존 기술을 사용하여 작성된 응용 프로그램을 사용하여 최소의 코드만 변경하여 Azure SQL 데이터베이스 인스턴스에 액세스할 수 있습니다.

Java API 지원

Node.js API 지원

PHP API 지원

LINQ 지원

Python 지원

아니요

오프라인 개발자 환경

SDK에 포함된 로컬 저장소 에뮬레이터를 통해 제공됩니다.

아니요

SQL Express 또는 다른 버전의 SQL Server는 다른 제품이므로 Microsoft Azure SQL 데이터베이스 환경의 전체 시뮬레이션을 제공하지 않습니다.

  • 로컬 SQL Server 설치에서 Azure SQL 데이터베이스를 시뮬레이션할 수는 있지만 이 방법은 조정 및 기타 적용 가능한 제한과 같은 클라우드 기반 서비스에만 적용되는 복제 동작을 허용하지 않습니다.

  • Microsoft Azure SQL 데이터베이스는 웹 기반 대화형 쿼리 환경을 제공합니다. 또한 Azure SQL 데이터베이스에는 SSMS이나 ODBC를 지원하는 타사 RDBMS 도구와 같은 임시 클라이언트 콘솔 도구에서 액세스할 수도 있습니다.

  • T-SQL 기능은 SQL Server와 Azure SQL 데이터베이스 간에 다릅니다. 일부 기능은 제한되었거나 지원되지 않으며 일부 기능은 중요한 차이점(예: 데이터베이스 및 페더레이션 만들기)이 있습니다.

이 섹션에서는 테이블 저장소 및 Azure SQL 데이터베이스에서 지원하는 인증 및 권한 부여 기능에 대해 설명합니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

인증

대칭 키

공유 액세스 서명

512비트 HMAC 키가 사용자를 인증하는 데 사용됩니다.

SQL 인증

표준 SQL 인증이 사용자를 인증하는 데 사용됩니다.

역할 기반 액세스

아니요

표준 SQL 데이터베이스 및 응용 프로그램 역할을 지원합니다.

Windows Azure Active Directory(이전의 ACS) 지원

아니요

아니요

ID 공급자 페더레이션

아니요

아니요

  • Azure SQL 데이터베이스에서 지원하는 역할 기반 액세스는 읽기 전용, 쓰기 전용 및 읽기/쓰기 모드를 구성하기 위한 모든 유연성을 제공합니다. 이 기능은 개별 응용 프로그램의 요구 사항에 따라 다양한 데이터 액세스 옵션을 제공할 수 있습니다.

  • 현재 두 기술 모두 페더레이션된 인증, 인증서 기반 인증 또는 Active Directory 인증을 지원하지 않으므로 암호화와 같은 적절한 보호 수단으로 보안 자격 증명(예: HMAC 키 또는 SQL 사용자 이름 및 암호)을 보호해야 합니다. 이러한 보호는 이러한 자격 증명에 대한 액세스가 IT 규정 준수와 관련이 있을 때 특히 중요합니다.

  • 테이블 저장소는 테이블 SAS(공유 액세스 서명)라고 하는 서명된 URL 기반 액세스를 제공합니다. SAS를 사용하면 저장소 계정 비밀 키를 노출하지 않고도 클라이언트에 역할 기반 액세스 권한을 부여할 수 있습니다. 자세한 내용은 이 블로그 게시물을 참조하십시오.

이 섹션에서는 비용 관점에서 테이블 저장소와 Azure SQL 데이터베이스를 비교합니다. 여기에 표시된 모든 비용은 나중에 변경될 수 있습니다.

 

비교 기준 테이블 저장소 Azure SQL 데이터베이스

저장소 비용

$0.125

일일 평균을 기준으로 매월 저장되는 GB당

가격 책정에 대해 자세히 알아보려면 Windows Azure 가격 책정 개요를 참조하십시오.

데이터베이스 크기를 기준으로 누진 비율로 요금이 청구됩니다.

가격 책정에 대해 자세히 알아보려면 Windows Azure 가격 책정 개요를 참조하십시오.

트랜잭션 비용

$0.01

100,000개의 저장소 트랜잭션당

$0.00

Azure SQL 데이터베이스는 트랜잭션에 대한 요금을 청구하지 않습니다.

청구 가능한 작업

모두

저장소 비용 외에도 트랜잭션 비용은 테이블에 대한 트랜잭션 볼륨을 기준으로 계산됩니다.

없음

비용은 트랜잭션 볼륨으로 결정되는 것이 아니라 데이터베이스 크기로만 결정됩니다.

송신 비용

$0.12 - $0.19

지역별 누진 크기를 기준으로 GB당

$0.12 - $0.19

지역별 누진 크기를 기준으로 GB당

  • 송신 비용은 인터넷을 통해 데이터 센터에서 나가는 총 데이터 양을 기준으로 계산됩니다. 금액은 응용 프로그램이 쿼리를 수행하고 각 데이터 서비스로부터 결과를 수신하는 지정된 요금 청구 기간 동안 계산됩니다.

  • Azure SQL 데이터베이스와 달리 테이블 저장소는 트랜잭션별로 비용을 부과합니다. 이 요금 청구 모델은 비용 관련 고려 사항에 저장소 트랜잭션의 빈도를 포함해야 함을 의미합니다.

테이블 저장소 및 Microsoft Azure SQL 데이터베이스를 언제 사용할지는 다양한 요인에 의해 결정됩니다. 이러한 요인은 주로 응용 프로그램 및 해당 아키텍처에 대한 개별 요구 사항뿐만 아니라 작업 및 데이터 액세스 패턴에 따라 달라질 수 있습니다. 이 섹션에서는 몇 가지 중요한 고려 사항을 요약하여 설명합니다.

테이블 저장소는 많은 양의 데이터를 클라우드에서 확장성이 뛰어난 테이블에 저장하는 것을 지원합니다. 이러한 테이블에는 테라바이트의 데이터와 수십억 개의 엔터티를 저장할 수 있습니다. 이러한 수준의 확장성을 달성하기 위해 테이블 저장소는 확장 모델을 사용하여 여러 저장소 노드에 엔터티를 배포합니다. 즉, NoSQL 데이터 모델을 사용하여 강력한 일관성과 함께 뛰어난 확장성을 지원합니다. 적은 비용으로 많은 양의 비관계형 또는 단순화된 데이터 모델을 유지해야 하는 경우 테이블 저장소를 사용하는 것이 좋습니다.

Microsoft Azure SQL 데이터베이스는 클라우드 플랫폼으로 확장된 SQL Server 데이터베이스 엔진으로 간주할 수 있습니다. 이러한 데이터베이스 엔진에서는 친숙한 SQL Server 개발자 환경, 다양한 쿼리 의미 체계, 여러 격리 수준이 있는 ACID 트랜잭션에 대한 지원 및 복잡한 데이터 처리 기능을 제공합니다. 데이터가 고도의 관계형 데이터이기 때문에 이러한 기능과 결합된 관계형 데이터 관리가 필요할 경우 Azure SQL 데이터베이스가 더 적합할 수 있습니다.

특정 기술을 언제 사용할지 결정하는 것은 항상 양자택일이지는 않기 때문에 항상 하나의 기술을 선택할 수 있는 것은 아닙니다. 두 기술의 균형 잡힌 조화가 솔루션의 요구 사항을 잘 충족하는지 여부를 평가하고 해결할 특정 클래스의 문제가 있는 각 영역에 둘 다 적용할 수도 있습니다.

이 두 기술을 보다 깊이 이해하면 에서 언제, 어떤 데이터 저장소 기술을 사용할지를 보다 합리적으로 결정할 수 있습니다.

참고 항목

표시:
© 2014 Microsoft