我有一項暴露服務的任務，它將提供潛在的非常大量的數據（千兆字節）。因此它將不得不按需流式傳輸數據，這樣數據就不會被緩存在內存中。數據在發送給客戶之前將經歷以下步驟。從數據庫通過web服務按需流式傳輸數據
步驟3可能會留出作爲壓縮可以通過WCF完成。有沒有推薦的方法來做到這一點，而不是在任何步驟中緩衝大量的數據，這顯然會使應用程序崩潰，數據可能是100GB？
由於這是一項任務，我不確定你有什麼限制或練習的基本目的是什麼，但是優化這樣的數據傳輸服務並使其穩定不是微不足道的。發生通信問題的可能性很大，因此您需要處理這種可能性。但是如果出現問題，您不僅要重新開始，因爲這會浪費您所做的所有工作，直到問題出現。
在基本層面上，服務應該將數據分解爲可管理的部分（比如，100K，取決於網絡速度，穩定性和環境）。塊的大小意味着是錯誤可能性與請求每個塊的開銷的平衡。如果錯誤的可能性很高，塊應該更小。
這也解決了在內存中緩衝大量數據的問題，但是需要強大的錯誤處理機制同樣重要。因此，該服務應該有一種方法來發起一個請求，該請求將響應客戶端有關數據流總大小的信息以及塊的數量，另一個請求特定的數據塊。
客戶端可以選擇指定塊大小，或協議可以設計爲自動調整塊大小以響應錯誤條件。也就是說，如果錯誤頻繁發生，塊大小通常應該減小。
無論採用哪種方式，客戶端一旦啓動請求，就會調用另一個請求特定數據塊的方法，並在每個請求成功接收後，將其附加到文件的末尾。如果發生故障，客戶端可以重新請求一個特定的塊。
最後，以XML格式發送大量數據可能非常低效，除非與標記相比數據量非常大。也就是說，如果數據結構與每個元素包含的信息量（例如，大量簡單的數字數據）相比具有許多元素（字段，記錄），那麼爲數據格式建立合同會更有意義當它最初被要求時。另一方面，如果幾個字段都包含大量數據（例如文本），那麼它並不重要。
如果數據格式總是相同的（這是典型的），那麼客戶端可以設計爲期望。如果沒有，服務器可以通過爲它將要傳輸的數據提供一個結構來開始交換，然後在建立的結構中傳輸數據，而不需要標記標記的開銷。
對於一個非常高效，結構化的數據編碼器檢查protocol buffers.基本點（無論您使用協議緩衝區，還是僅以您自己的標準化格式佈置數據）都是標記標記可能會增加很多開銷，如果客戶端和服務器有發送數據格式的合同，並且您應該將數據分解爲可由客戶端專門請求的可管理部分，則它們完全沒有必要。