將大量帶有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的對象傳輸到客戶端

回答

相關問題