ReST在涉及超过100 Gig的读/写操作中有用吗

Question

我在医疗保健部门工作，我们使用SAS提取和转换医疗和制药索赔数据，以便用于下游报告应用程序。对于给定的报表请求(通常一次运行40次)，我们必须从各种DBMS中提取并转换数据。完成此ET步骤后，数据将以聚合形式(SAS表)超过100 gig。对此数据进行索引并对其进行优化，以供报表使用。在提取数据之后，我们不需要返回数据库。

对我来说，在这种情况下使用ReST没有多大意义，因为XML对于大数据量并不是很有效。但我想我应该问问其他程序员的想法。

Answer 1

答案通常讨论使用REST通过HTTP发送大数据的方面。请确保您还阅读了更具体的罗伯特·杰克的回答，并建议了一种避免首先发送大数据的方法。

REST与XML无关:数据的格式(是JSON、XML、纯文本还是二进制流)是无关的。例如，您可以提供图像(JPEG、PNG.)通过REST，这并不意味着您需要将它们包含在XML中。

另一方面，REST是基于HTTP的，HTTP确实适合大数据传输。当然，在将您的服务和客户端配置为在下载如此大的数据时使用流时，您必须小心，而不是将其加载到内存中。

至于数据的实际格式：

• 如果必须保持自文档化结构，请使用JSON、XML或纯文本，但在发送之前请确保在服务器端压缩内容。压缩算法的选择将取决于您的平台和互操作性要求，因为诸如RAR这样的专有格式通常可以实现更好的压缩比(尽管如此，还是用您的数据进行测试，看看不同的算法执行得有多好)。请注意，要为XML或JSON找到序列化程序/反序列化程序并不那么容易，因为它将生成/接受流而不是字符串。在这种情况下，纯文本可能是您的最佳选择。
• 如果不需要自文档结构，二进制格式在大小方面可能是更好的选择。尽管如此，还是要对纯文本压缩数据和二进制数据进行实际比较，看看哪一个结果更小；您可能会感到惊讶。

Answer 2

至于是否和如何使用HTTP进行数据传输，我完全同意MainMa的回答。

但是，与数据大小无关，您描述的过程听起来并不像Rest的典型应用程序。Rest的主要思想之一是命名资源(如mycompany.com/claims/customer/{number}/claim/{number} )，这些资源可以单独查询和更新。

另一方面，您的问题听起来更像是批处理:您有大量数据，甚至包括索引，既然您希望稍后运行报告，为什么不将这些数据存储到数据库或分析引擎中，比如弹性搜索？然后，您可以让报告逻辑高效地查询数据库/搜索引擎，并通过Rest: mycompany.com/healthreport/{year}/{month}/claimsdata/{region}或somesuch提供报告结果。

根据您有多少实体和关系，在从ET引擎到报表生成器的过程中编组所有这些数据可能需要做大量工作，只有在需要在很大程度上分离这两个阶段时才值得麻烦。(例如，当它们在独立的IT组织/公司中运行时。)使用单独的数据库已经可以以较少的努力提供一定量的解耦。