Unterschiede zwischen dem Speicheremulator und den Windows Azure-Speicherdiensten

Die folgenden allgemeinen Unterschiede gelten für Speicherdienste:

• Von Speicheremulator werden nur ein einzelnes festes Konto und ein bekannter Authentifizierungsschlüssel unterstützt. Dieses Konto und dieser Schlüssel sind die einzigen Anmeldeinformationen, die mit den lokalen Speicherdiensten verwendet werden dürfen. Sie beinhalten Folgendes:
  
  
  Kopieren

  
  Account name: devstoreaccount1
  Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
  

  Wichtig
  Der von Speicheremulator unterstützte Authentifizierungsschlüssel ist nur zum Testen der Funktionalität des Clientauthentifizierungscodes gedacht. Er dient keinerlei Sicherheitszwecken. Sie können das Speicherkonto und den Schlüssel der Produktionsumgebung nicht mit Speicheremulator verwenden. Sie sollten das lokale Speicherkonto nicht mit Produktionsdaten verwenden.

• Speicheremulator ist kein skalierbarer Speicherdienst und unterstützt keine große Anzahl gleichzeitiger Clients.
  
  
• Das von Speicheremulator unterstützte URI-Schema unterscheidet sich vom von den Cloud-Speicherdiensten unterstützten URI-Schema. Das URI-Entwicklungsschema gibt den Kontonamen als Teil des hierarchischen Pfads des URIs anstelle als Teil des Domänennamens an. Dieser Unterschied ist dadurch begründet, dass die Domänennamenauflösung zwar in der Cloud, nicht jedoch auf dem lokalen Computer verfügbar ist. Weitere Informationen zu URI-Unterschieden in Entwicklungs- und Produktionsumgebungen finden Sie unter Verwenden von Speicherdienst-URIs in Übersicht über das Ausführen einer Windows Azure-Anwendung mit lokalem Speicher.
  
  

Die folgenden Unterschiede gelten für den BLOB-Dienst:

• Der BLOB-Dienstemulator unterstützt nur Blob-Größen bis zu 2 GB.
  
  
• Wenn zwei Anforderungen versuchen, einen Block in ein Blob hochzuladen, das in Speicheremulator noch nicht vorhanden ist, erstellt eine Anforderung das Blob. Die andere Anwendung gibt möglicherweise Statuscode 409 (Konflikt) mit Speicherdienst-Fehlercode "BlobAlreadyExists" zurück.
  
  
• Ein Put Blob (REST API)-Vorgang ist möglicherweise bei einem Blob erfolgreich, das in Speicheremulator vorhanden ist und eine aktive Lease besitzt, auch wenn die Lease-ID nicht als Teil der Anforderung angegeben wurde.
  
  
• Der Speicheremulator bietet keine Unterstützung für Set Blob Service Properties oder Microsoft.WindowsAzure.StorageClient.CloudBlobClient.SetServiceProperties(Microsoft.WindowsAzure.StorageClient.Protocol.ServiceProperties).
  
  

Die folgenden Unterschiede gelten für den Tabellendienst:

• Der Speicheremulator unterstützt keine Insert-Or-Replace-Entität (zum Einfügen oder Ersetzen) oder Insert-Or-Merge-Entität (zum Einfügen oder Zusammenführen), die als UPSERT-Features bezeichnet werden.
  
  
• Der Speicheremulator bietet keine Unterstützung für die Entitätsprojektion.
  
  
• Die Datumseigenschaften im Tabellendienst in Speicheremulator unterstützen nur den von SQL Server 2005 unterstützten Bereich. Das Datum muss z. B. nach dem 1. Januar 1753 liegen. Alle Datumsangaben vor dem 1. Januar 1753 werden in diesen Wert geändert. Die Genauigkeit von Datumsangaben ist auf die Genauigkeit von SQL Server 2005 beschränkt, d. h. Datumsangaben weisen eine Genauigkeit von 1/300 Sekunde auf.
  
  
• Speicheremulator unterstützt Werte für die Eigenschaften für Partitionsschlüssel und Zeilenschlüssel von höchstens 900 Byte. Die Gesamtgröße von Kontoname, Tabellenname und Schlüsseleigenschaftenname darf 900 Byte nicht überschreiten.
  
  
• Die Gesamtgröße einer Zeile in einer Tabelle in Speicheremulator ist auf höchstens 1 MB beschränkt.
  
  
• Von Speicheremulator wird nicht überprüft, ob die Größe eines Batch in einer Entitätsgruppentransaktion kleiner als 4 MB. ist Batches sind in Windows Azure auf 4 MB beschränkt. Stellen Sie also vor der Übertragung an die Windows Azure-Speicherdienste sicher, dass ein Batch diese Größe nicht überschreitet.
  
  
• In Speicheremulator gibt das Abfragen einer Eigenschaft, die nicht in der Tabelle vorhanden ist, einen Fehler zurück. Diese Abfrage gibt in der Cloud keinen Fehler zurück.
  
  
• In Speicheremulator unterstützen die Eigenschaften des Datentyps Edm.Guid oder Edm.Binary nur die Vergleichsoperatoren Equal (eq) und NotEqual (ne) in Zeichenfolgen für Abfragefilter.
  
  
• Der Speicheremulator bietet keine Unterstützung für Set Table Service Properties oder Microsoft.WindowsAzure.StorageClient.CloudTableClient.SetServiceProperties(Microsoft.WindowsAzure.StorageClient.Protocol.ServiceProperties).
  
  

Die folgenden Unterschiede gelten für den Warteschlangendienst:

• Der Speicheremulator bietet keine Unterstützung für Set Queue Service Properties oder Microsoft.WindowsAzure.StorageClient.CloudQueueClient.SetServiceProperties(Microsoft.WindowsAzure.StorageClient.Protocol.ServiceProperties).
  
  

Die folgenden Unterschiede gelten für die Windows Azure-Laufwerke:

• Beim Bereitstellen eines Windows Azure-Laufwerks von Windows Azure-Serveremulator muss das Laufwerk von einem in Speicheremulator erstellten Seiten-Blob unterstützt werden. Ein von einem Seiten-Blob unterstütztes Laufwerk kann von Serveremulator nicht in Windows Azure bereitgestellt werden. Dieses Verhalten unterscheidet sich von dem Verhalten anderer Windows Azure-Speicherdienste, auf die in der Cloud über Code zugegriffen werden kann, der in Serveremulator ausgeführt wird.
  
  
• Geben Sie beim Erstellen eines neuen Windows Azure-Laufwerks in Serveremulator unbedingt die Anmeldeinformationen für das lokale Speicherkonto an.