我有一项暴露服务的任务，它将提供潜在的非常大量的数据（千兆字节）。因此它将不得不按需流式传输数据，这样数据就不会被缓存在内存中。数据在发送给客户之前将经历以下步骤。从数据库通过web服务按需流式传输数据
步骤3可能会留出作为压缩可以通过WCF完成。有没有推荐的方法来做到这一点，而不是在任何步骤中缓冲大量的数据，这显然会使应用程序崩溃，数据可能是100GB？
由于这是一项任务，我不确定你有什么限制或练习的基本目的是什么，但是优化这样的数据传输服务并使其稳定不是微不足道的。发生通信问题的可能性很大，因此您需要处理这种可能性。但是如果出现问题，您不仅要重新开始，因为这会浪费您所做的所有工作，直到问题出现。
在基本层面上，服务应该将数据分解为可管理的部分（比如，100K，取决于网络速度，稳定性和环境）。块的大小意味着是错误可能性与请求每个块的开销的平衡。如果错误的可能性很高，块应该更小。
这也解决了在内存中缓冲大量数据的问题，但是需要强大的错误处理机制同样重要。因此，该服务应该有一种方法来发起一个请求，该请求将响应客户端有关数据流总大小的信息以及块的数量，另一个请求特定的数据块。
客户端可以选择指定块大小，或协议可以设计为自动调整块大小以响应错误条件。也就是说，如果错误频繁发生，块大小通常应该减小。
无论采用哪种方式，客户端一旦启动请求，就会调用另一个请求特定数据块的方法，并在每个请求成功接收后，将其附加到文件的末尾。如果发生故障，客户端可以重新请求一个特定的块。
最后，以XML格式发送大量数据可能非常低效，除非与标记相比数据量非常大。也就是说，如果数据结构与每个元素包含的信息量（例如，大量简单的数字数据）相比具有许多元素（字段，记录），那么为数据格式建立合同会更有意义当它最初被要求时。另一方面，如果几个字段都包含大量数据（例如文本），那么它并不重要。
如果数据格式总是相同的（这是典型的），那么客户端可以设计为期望。如果没有，服务器可以通过为它将要传输的数据提供一个结构来开始交换，然后在建立的结构中传输数据，而不需要标记标记的开销。
对于一个非常高效，结构化的数据编码器检查protocol buffers.基本点（无论您使用协议缓冲区，还是仅以您自己的标准化格式布置数据）都是标记标记可能会增加很多开销，如果客户端和服务器有发送数据格式的合同，并且您应该将数据分解为可由客户端专门请求的可管理部分，则它们完全没有必要。