Azure - Update einer bestehenden xml-Datei in BLOB-Speicher
Habe ich XML-Dateien in BLOB-Speicher und ich bin versucht, herauszufinden, was ist der effizienteste Weg, um Sie zu aktualisieren ( und/oder fügen Sie einige Elemente, um Sie). In einer WebRole, ich kam mit dieser :
using (MemoryStream ms = new MemoryStream())
{
var blob = container.GetBlobReference("file.xml");
blob.DownloadToStream(msOriginal);
XDocument xDoc= XDocument.Load(ms);
//Do some updates/inserts using LINQ to XML.
blob.Delete();//Details about this later on.
using(MemoryStream msNew = new MemoryStream())
{
xDoc.Save(msNew);
msNew.Seek(0,SeekOrigin.Begin);
blob.UploadFromStream(msNew);
}
}
Ich bin auf der Suche auf diese Parameter unter Berücksichtigung der Effizienz:
- BLOB Transaktionen.
- Bandbreite. (Nicht sicher, ob es gezählt, da der code läuft im data-center).
- Speicher Verbrauch auf die Instanz.
Einige Dinge zu erwähnen:
-
Meine xml-Dateien werden etwa 150-200 KB.
-
Ich bin der Tatsache bewusst, dass XDocument lädt die ganze Datei in
Speicher, und arbeiten in streams ( XmlWriter und XmlReader ) könnte
lösen Sie dieses. Aber ich nehme an, dies erfordert die Zusammenarbeit mit BlobStream
das könnte dazu führen, dass weniger effiziente Transaktion-Weise (denke ich). -
Etwa blob.Löschen(), ohne dass es die hochgeladenen xml-Datei in den blob-Speicher
scheint zu fehlen einige schließende tags am Ende. Ich nahm
dies wird verursacht durch eine Kollision mit den alten Daten. Ich könnte
völlig falsch hier, aber mit dem löschen gelöst ( kostet ein
mehr Transaktion, obwohl ).
Ist der code, den ich zur Verfügung gestellt ist eine gute Praxis, oder vielleicht eine effizientere Möglichkeit besteht unter Berücksichtigung der Parameter, die ich erwähnt ?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich glaube das problem mit den stream-basierten Methode ist, dass die storage-client nicht wissen, wie lang der Bach ist, bevor es beginnt, Daten zu senden. Dies ist wahrscheinlich verursacht die content-length nicht aktualisiert werden, wodurch der Eindruck von fehlenden Daten am Ende der Datei.
Arbeiten mit dem Inhalt des blob im text-format helfen. Herunterladen können Sie den blob-Inhalt als text und laden Sie dann als text. Dies zu tun, sollten Sie in der Lage sein, um sowohl zu vermeiden, löschen (Sie sparen 1/3rd der Transaktionen) und einfacher code.
Darüber hinaus, wenn Sie neu erstellen können die Datei ohne Download in den ersten Platz (wir können dies tun, manchmal), dann kann man nur hochladen und überschreiben der alte mit einer storage-Transaktion.
Ich bin der Tatsache bewusst, dass XDocument lädt die gesamte Datei in den Speicher, und arbeiten in streams ( XmlWriter und XmlReader ) könnte dieses Problem lösen.
Nicht sicher, es zu lösen wäre zu viel. Denken Sie über es. Wie fügen Sie koolaid, um das Wasser, während es fliegt durch den Schlauch. Das ist das, was ein stream ist. Besser zu warten, bis es in einem container.
Außerhalb der, dass, was ist der Grund für den Fokus auf die Effizienz (ein technisches problem) eher als Bearbeitung (business problem)? Sind die Dokumente Häufig geändert genug, um einen ernsthaften Blick auf die Leistung? Oder sind Sie nur Opfer der normale Entwickler Tendenz, mehr zu tun als das, was notwendig ist? (HINWEIS: ich bin oft schuldig, auch in diesem Bereich)
Ohne ein Konzept, einen Flush(), die zu Löschen ist eine akzeptable option, auf den ersten Blick. Ich bin nicht sicher, wenn Sie in der asynch Methoden erleichtern könnten, haben das gleiche Ziel mit weniger Aufwand.