3

いくつかの一般的なプロパティに加えて、コレクション内の文字列の（Name、Value）ペアとして格納されている拡張プロパティのリストを含むエンティティがあります。これらの拡張プロパティはインスタンスごとに大きく異なり、インスタンスごとにリストするだけで済みます（たとえば、特定の（Name、値）ペア）。Windows Azureテーブルサービスを使用して、このエンティティを永続化する方法を模索しています。私が現在テストしている特定のアプローチでは、アプリケーションがより明確な拡張プロパティ名に遭遇するため、時間の経過とともにパフォーマンスが低下する可能性があることを懸念しています。

このエンティティを一般的なリレーショナルデータベースに格納している場合、このスキーマをサポートするためにおそらく2つのテーブルがあります。1つ目はエンティティ識別子とその共通プロパティを含み、2つ目はエンティティ識別子を参照してEAVスタイルの行を使用します-拡張（名前、値）ペアを各行に1つずつ格納するためのモデリング。

Windows AzureのテーブルはすでにEAVモデルを使用しているため、エンティティのコンパイル時に宣言されたかのように拡張プロパティが格納されるように、エンティティのカスタムシリアル化を検討しています。これを実現するために、 DataServiceContextによって提供されるReading-およびWriting-Entityイベントを使用できます。

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));
        }
    }
}

これは機能し、拡張プロパティの名前と値の要件を定義できるため、WindowsAzureテーブル内のエンティティプロパティのすべての標準要件に準拠していることを確認できます。

では、アプリケーションが何千もの異なる拡張プロパティ名に遭遇すると、時間の経過とともに何が起こるでしょうか。

開発ストレージ環境内で私が観察したことは次のとおりです。

  • テーブルコンテナスキーマは、新しい名前ごとに大きくなります。このスキーマがどのように使用されているか（おそらく次のポイントで）正確にはわかりませんが、明らかにこのxmlドキュメントは時間の経過とともに非常に大きくなる可能性があります。

  • インスタンスが読み取られるたびに、OnReadingEntityに渡されるxmlには、他のインスタンス用に保存されたすべてのプロパティ名の要素が含まれます（読み取られる特定のインスタンス用に保存されたものだけではありません）。これは、エンティティの取得が時間の経過とともに遅くなることを意味します。

本番ストレージ環境でこれらの動作を期待する必要がありますか？スキーマは時間の経過とともにほとんど静的になるため、これらの動作がほとんどのテーブルでどのように受け入れられるかがわかります。おそらく、Windows Azureテーブルはこのように使用するように設計されていませんか？もしそうなら、私は確かに私のアプローチを変える必要があります。また、別のアプローチについての提案も受け付けています。

4

1 に答える 1

4

開発ストレージは、SQL Express を使用してクラウド テーブル ストレージをシミュレートします。そこに表示される内容は無視してください... 運用ストレージ システムにはスキーマが保存されないため、テーブルに多数の一意のプロパティを含めることによるオーバーヘッドはありません。

于 2010-06-19T18:12:39.607 に答える