Windows Azure 테이블 서비스 - 확장 속성 및 테이블 스키마

Question

몇 가지 공통 속성 외에도 컬렉션 내에 문자열의 (이름, 값) 쌍으로 저장된 확장 속성 목록이 포함 된 엔티티가 있습니다. 이러한 확장 속성은 인스턴스마다 매우 다양하며 각 인스턴스에 대해 나열되어야합니다 (확장 속성에 대한 쿼리가 없습니다. 예를 들어 특정 이름 (예 : 값) 쌍). Windows Azure Table Services를 사용하여이 엔티티를 유지하는 방법을 모색 중입니다. 필자가 지금 테스트하고있는 특정 접근 방식을 사용하면 응용 프로그램에서 더 많은 확장 된 속성 이름을 발견 할 때마다 성능이 저하 될 수 있습니다.

이 엔티티를 일반적인 관계형 데이터베이스에 저장하는 경우이 스키마를 지원하는 테이블이 두 개 있습니다. 첫 번째 엔티티 식별자와 공통 속성이 포함되고 두 번째 엔티티 식별자가 참조되어 사용됩니다 확장 (이름, 값) 쌍을 각 행에 하나씩 저장하는 EAV 스타일 행 모델링.

Windows Azure의 테이블은 이미 EAV 모델을 사용하고 있으므로 엔티티에 대한 컴파일 타임에 선언 된 것처럼 확장 속성이 저장되도록 내 엔티티의 사용자 지정 직렬화를 고려하고 있습니다. 이 작업을 수행하기 위해 DataServiceContext에서 제공하는 읽기 및 쓰기 엔티티 이벤트를 사용할 수 있습니다.

private void OnReadingEntity(object sender, ReadingWritingEntityEventArgs e) 
{ 
    MyEntity Entry = e.Entity as MyEntity; 

    if (Entry != null) 
    { 
     XElement Properties = e.Data 
      .Element(Atom + "content") 
      .Element(Meta + "properties"); 

     //select metadata from the extended properties 
     Entry.ExtendedProperties = (from p in Properties.Elements() 
          where p.Name.Namespace == Data && !IsReservedPropertyName(p.Name.LocalName) && !string.IsNullOrEmpty(p.Value) 
          select new Property(p.Name.LocalName, p.Value)).ToArray(); 
    } 
} 

private void OnWritingEntity(object sender, ReadingWritingEntityEventArgs e) 
{ 
    MyEntity Entry = e.Entity as MyEntity; 

    if (Entry != null) 
    { 
     XElement Properties = e.Data 
      .Element(Atom + "content") 
      .Element(Meta + "properties"); 

     //add extended properties from the metadata 
     foreach (Property p in (from p in Entry.ExtendedProperties 
           where !IsReservedPropertyName(p.Name) && !string.IsNullOrEmpty(p.Value) 
           select p)) 
     { 
      Properties.Add(new XElement(Data + p.Name, p.Value)); 
     } 
    } 
} 

이 작동하고, 내가 확장 속성 이름과 값에 대한 요구 사항을 정의 할 수 있기 때문에, 나는 그들이 윈도우 Azure 테이블에서 개체 속성에 대한 모든 표준 요구 사항을 준수하도록 할 수 있습니다.

그래서 응용 프로그램이 수천 개의 서로 다른 확장 속성 이름을 발견하면 어떻게됩니까?

는 여기가 개발 스토리지 환경 내에서 관찰 한 내용은 다음과 같습니다

• 테이블 컨테이너 스키마가 각각 새 이름으로 성장한다. 나는이 스키마가 (아마도 다음 지점에서) 사용 된 방법을 정확히 모르겠다.하지만 분명히이 XML 문서는 시간이 지남에 따라 상당히 커질 수있다.

• 인스턴스를 읽을 때마다 OnReadingEntity에 전달 된 XML에는 다른 인스턴스 (읽은 특정 인스턴스에 대해 저장된 인스턴스뿐만 아니라)에 저장된 모든 속성 이름의 요소가 포함됩니다. 이는 엔티티 검색이 시간이 지남에 따라 느려질 것임을 의미합니다.

은 내가 생산 스토리지 환경에서 이러한 행동을 기대해야 하는가? 스키마는 대부분 시간이 지남에 따라 정적이기 때문에 이러한 동작이 대부분의 테이블에서 허용되는 방법을 알 수 있습니다. 아마도 Windows Azure 테이블은 이와 같이 사용하도록 설계되지 않았습니까? 그렇다면 분명히 내 접근 방식을 바꿔야 할 것입니다. 대체 접근법에 대한 제안도 열려 있습니다.

Answer 1

개발 저장소는 SQL Express를 사용하여 클라우드 테이블 저장소를 시뮬레이션합니다. 생산 스토리지 시스템에는 스키마가 저장되지 않으므로 테이블에 많은 고유 한 특성을 갖는 데 오버 헤드가 없습니다.