将大量带有Guid ID的对象传输到客户端

我有一个Web应用程序，它使用Guids作为DB中的一个Employee对象和一个Association对象的PK。将大量带有Guid ID的对象传输到客户端

我的应用程序中的一个页面返回大量数据，显示所有员工可能参与的所有关联。

所以现在，我派基本上客户端一堆看起来像对象：

{assocation_id: guid, employees: [guid1, guid2, ..., guidN]}

事实证明，很多员工都属于许多联想，所以我送上下一致的GUID的这些员工反复在这些不同的对象。例如，在某些情况下，我可能会在所有协会中发送30,000个全面指导，其中只有500名独特员工。

我想知道，如果它是值得我建立某种查找索引的，我也向客户端发送类似

{ 1: Guid1, 2: Guid2 ... }

和替换我送下来的整数对象的所有的GUID，

或者如果简单地gzip响应将压缩足够多，这额外的努力是不值得的？

请注意：如果我要发送30,000条数据或不发送这些信息 - 这不是我的选择，我无能为力（我也可以不要将Guid改为数据库中的整数或长整数）。

来源

2012-03-15 Davis Dimitriov

为什么你不使用Linq Distinct（）方法？或者在dbase查询中使用DISTINCT？ – 2012-03-15 15:22:49

为什么不发送*关联*每个*员工*的名单呢？ – ydroneaud 2012-03-22 11:16:45

有关响应带宽的更多原因，我会按照您的建议为这种情况分离出嵌套资源。你可以为它们使用单独的ajax请求，或者按需延迟加载它们。 – aceofspades 2012-03-27 16:52:59

所以你想要完成的是字典压缩，对吧？ http://en.wikibooks.org/wiki/Data_Compression/Dictionary_compression 你会得到什么，而不是长度为16字节的Guids是4字节长的int。你会得到一个完整的关键值对的字典，将每个guid关联到一些int值，对吧？当有许多使用相同ID的对象时，它会减少您的传输时间。但是在传输到压缩之前以及在传输到解压缩之后，会花费CPU时间。那么你传输的数据量是多少？是mb/gb/tb吗？在发送之前是否有充分的理由对其进行压缩？

来源

2012-03-16 18:08:46 amdmax

将小整数**序列化为JSON **占用较少的地方作为GUID的一半，并且少于GUID。比较'“{7EDBB957-5255-4b83-A4C4-0DF664905735}”或'“7EDBB95752554b83A4C40DF664905735”'与'499'（34或3个字符）。 – Oleg 2012-03-21 09:03:57

你在你的问题的最后写了下面

注：请不要误会在我是否应该向下发送3万多条数据与否的细节赶上了 - 这是不是我的选择和我没有办法做到这一点（并且我也不能在数据库中将Guid更改为整数或长整数）。

我认为这是您的主要问题。例如，如果您没有解决主要问题，您将能够将传输数据的大小减少到10倍，但您仍然无法解决主要问题。让我们考虑一下这个问题：为什么这么多数据应该发送到客户端（到Web浏览器）？

需要客户端数据才能向用户显示某些信息。显示器并不大，在一页上显示总共30,000张。没有用户能够掌握如此多的信息。所以我相信你只能显示一小部分信息。在这种情况下，您应该只发送的小部分信息，您显示。

你没有描述如何在客户端使用GUID。例如，如果您在行编辑期间需要这些信息。只有在用户开始编辑时才可以传输数据。在这种情况下，您只需要将数据传输给一个关联。

如果您需要直接显示指导，则无法一次显示所有信息。所以你可以只发送一页信息。如果用户开始滚动或启动“下一页”按钮，则可以发送下一部分数据。通过这种方式，您可以显着减少传输数据的大小。

如果你有没有可能重新设计应用程序的一部分，你可以实现你原来的建议：由GUID "{7EDBB957-5255-4b83-A4C4-0DF664905735}"或"7EDBB95752554b83A4C40DF664905735"的更换像123数量从34个字符减少GUID的大小为3，如果你愿意发送附加阵列的 “GUID映射” 的元素，如

123:"7EDBB95752554b83A4C40DF664905735",

可以减少数据30000 * 34 = 1020000（1 MB）到的原始大小300 * 39 + 30000 * 3 = 11700 + 90000 = 101700（100 KB）。所以你可以减少10次数据的大小。在Web服务器上使用动态数据压缩可以额外减少数据的大小。

无论如何，你应该检查你的网页为什么如此缓慢。如果程序在局域网中工作，那么即使是1MB的数据传输也可以足够快。在网页上放置数据时，网页可能会缓慢。我的意思是以下。如果修改页面上的某个元素，则必须重新计算的所有现有元素的位置。如果您将首先使用断开的DOM对象，然后将整个数据部分放在页面上，则可以显着提高性能。您不会在问题中发布您在Web应用程序中使用的技术，因此我不包含任何示例。例如，如果你使用jQuery，我可以举一些例子来说明我的意思。

来源

2012-03-22 09:16:59 Oleg

尽管有其他方法的逻辑，但开发人员有时会给予他们无法更改的要求。我认为戴维斯很清楚地表明了这里的情况。 – Random 2012-03-27 15:30:28

@Random：如果可以更改服务器响应的格式，例如在[Guid1，Guid2，...]阵列中用索引替换，那么一个* do *可以更改服务器和客户端。我们对这个问题的了解太少。我想提到的是，为一页显示的30,000个全面指导，显然太多了，因为需要显示页面上的现有信息。我想如果在这个方面更多地分析问题，可以多次减少传输数据的大小。 – Oleg 2012-03-27 15:39:55

我不一定不同意。你的答案中的信息是有用的。我只是说，因为戴维斯似乎也理解这一点，所以它限制了你的答案对他的具体问题的适用性。 – Random 2012-03-27 15:49:54

您提出的查找索引只是“自定义”压缩方案。正如amdmax所说，如果你有很多相同的GUID，这会提高你的性能，但是也会这样gzip。

恕我直言，编写自定义代码的额外工作将不值得。

奥列格指出正确的，只有当用户需要它，它可能是值得获取数据。但这当然取决于您的具体要求。

来源

2012-03-27 09:03:15 gzm0

如果单纯使用gzip压缩的响应将压缩它足够的，这额外的努力是不值得吗？
答案是：是的，它会的。

压缩数据将删除尽可能（取决于算法）一样好冗余部分，直到减压。

为了确保，只需发送/生成未压缩和压缩的数据并比较结果。您可以计算重复的GUID以计算您的数据块与字典压缩方法的大小。但我猜gzip会更好，因为它也可以压缩数据对象内的大括号，冒号等句法元素。

来源

2012-03-27 12:28:19 Tarion

事实证明，在做了一些测试之后，将大约50％的数据传输给gzip'd，而不是进行字典压缩。不幸的是相当多 – 2012-03-30 13:51:54

我不知道如何动态的数据，但我会

上的第一呼叫发送两个目录/字典映射短ID来长GUIDS，一个为你的关联，并在为您的员工如{1：AssoGUID1,2：AssoGUID2，...}和{1：EmpGUID1,2：EmpGUID2，...}。这些目录还可能包含有关关联和员工实例的其他信息;我怀疑你不会简单地显示GUIDs
后续调用只发送每个关联的雇员索引{1：[2,4,5]，3：[2,4]，...}，关键是数字值中的关联简称和ID，即员工的简短ID。鉴于你的描述构建反向索引：Employee和协会可以提供更好的结果大小明智的（但更高的处理）

那么它的一切归因于关联数组的操作是简单的JS。同样，如果你的数据是非常动态的服务器端，那么这两个目录很快就会过时，并且保持同步会花费你很多。

来源

2012-03-27 15:42:44

我会从回答以下问题开始：

性能要求是什么？有尺寸要求吗？速度要求？真正需要的最低性能是多少？

什么是当前的性能指标？你离需求有多远？

您将数据描述为可能主要是重复的。这是正常的情况吗？如果不是，那是什么？

上面列出的2个选项听起来很合理，而且实施起来很简单。尝试创建一个查找表，并查看您在实际查询中获得的性能收益。尝试压缩结果（查找和不查找），并查看获得的收益。

根据我的经验，如果你远离目标太远，性能要求往往是反复试验。

如果这些选项没有让您接近要求，我会退后一步，看看在您必须解决问题时，要求是否合理。

下一步做什么取决于缺乏哪些性能目标。如果它的规模很大，如果您需要随时发送整个关联列表，那么您开始受到限制。这真的是一个要求吗？你可以发送整个列表一次，然后只是更新？

来源

2012-03-27 18:09:19 kevingallagher

将大量带有Guid ID的对象传输到客户端

回答

相关问题