面對資料量大的情況如何進行優化?

時間 2021-05-30 15:01:34

1樓:黃鑫

GIS方面我們也遇到過類似的問題。最終的解決方案是從儲存到服務端再到前端都做了優化,儲存採用了ES,運用了GEOHASH的技術,這個具體可以看geohash es_360搜尋 ,請求和響應也做了諸多優化,用信令的方式的輪詢,分片返回資料,前端接收到任何乙個分片的資料就直接渲染,由於geohash本身就定義了當前zoom級別下每乙個經緯度區塊的value,對於前端而言就沒有聚合的開銷了。

再補充乙個場景,我們做大規模(百萬+節點,百萬+邊)Graph(Network)布局計算渲染時,整個布局計算採用C++實現的,也就是在伺服器上計算的,計算結果存成JSON是非常巨大的,更別說傳輸給瀏覽器然後在繪製出來了。下面是原始的JSON格式:

{ nodesid: 1,

label: 'node-1'id: 2,

label: 'node-2'linksfrom: 1,

to: 2

我們就把JSON進行轉化,分成幾部分:

第一部分是節點編號(正整數)和位置(x,y,z)資訊,座標是浮點型;

第二部分是關係(from,to)序列,from、to都是節點編號;

第三部分就是節點編號和label(節點名稱)文字資訊(這一部分可以進一步劃分,label可能是第一優先的)。

針對第一部分和第二部分都是數值型我們可以使用二進位制的方式進行壓縮傳輸,只需自己設定乙個編碼規則即可:

第一部分是包含所有節點的位置資訊,其實就是乙個二維浮點數序列:[[x1,y1,z1], [x2,y2,z2], ...],xyz都轉為32bit,連續3個32bit就是乙個xyz,整個二進位制序列的長度就是3 * 32bit * 節點個數,還原解析時每連續3個就是乙個xyz;

第二部分是節點關係,其實也是乙個二維正整數序列:[[from1,to1], [from2,to2], ...],from、to都是正整數,對這個序列先調整順序,調整為同乙個from的按順序依次排列,那就變為了:

[[from1,to1], [from1,to2],[from1, to3], [from2, to1], ...],然後再把相同的from保留乙個就變為了:[[from1, to1, to2, to3], [from2, to1, to4, to7], ...

],接著from用負整數表示fromNew=-(from+1),to用非負整數表示toNew=to-1,這樣做的原因是為了降維和對應分段,根據這樣的規則將二維正整數序列轉化為一維整數序列:[fromNew1, toNew1, toNew2, toNew3, fromNew2, toNew1, toNew4, toNew7, ...],然後再將每個整數轉為32bit,就構成了乙個二進位制序列,還原解析時遇到負數就是from後面的就是to,規則為from=|fromNew+1|,to=toNew+1。

第一部分和第二部分轉為二進位制檔案後的體積是非常小的,這兩部分可以通過http進行傳輸,在JS中通過arraybuffer根據定義好的規則進行解析,然後交由WebGL進行繪製,整個Graph(Network)的形態已經可以完整的呈現出來。第三部分僅僅包含了我們優先需要的文字資訊的序列,這個依舊可以選擇使用JSON,那也就是:[label1, label2, label3, ...

],其它需要的文字資訊也可以類似的拆解,然後按需載入。

希望這兩個思路能夠對你的場景產生啟發。

2樓:地平星

這種情況,前端聚合不現實。先讓服務端按一定演算法聚合好(參考 @Undefined 的答案geohash),前端直接展示。

3樓:

你算是問對人了,我們公司之前做過類似的東西1.聚合功能必須要使用

2.資料要做動靜分離

3.webgis承載的物件大小要合理分配

4.非同步載入這是肯定要支援的

5.小比例尺可以考慮用切片顯示

4樓:程墨Morgan

這問題太大,不具體也就沒法說得很細,從大原則上說,前端能做的事情包括:

只給瀏覽器肯定用得上的資料。後端服務往往不知道前端具體需要哪些資料,給的資料冗餘,如果去掉不必要的資料,可以節省資料傳輸時間。

先展示使用者第一眼看到的介面,然後懶載入其餘部分。不管頁面有多大,使用者同一時間看到的也就螢幕那麼大,先把使用者第一眼看到的資料載入展示了,能打打提高感知效能。

快取資料。這個快取可以放在瀏覽器端,比如用Service Worker的Cache Storage,也可以在伺服器端,比如常用的圖表的顯示,可以在伺服器端預先計算出接過來,省去瀏覽器的計算時間。

差不多就這些。

另外,如果問題說得更具體,別人才更可能幫助得到你。

天生對數字不敏感的人,如何提公升對資料運營的敏感性?

小士多啤梨 其實工作久了,都還好吧,慢慢就好了,可以看看這篇運營小白的資料分析之路 silent sadness 我雖然天生聰穎,但在小學時還是有過失誤,即便這樣,老師還是把我當神童捧著,到了初中,老師不會這樣,他們只會讓我追求更高的目標。說來奇怪,我這人做應用題 競賽題都能準確無誤,但那簡單的計算...

超大資料量,如何加快寫檔案的速度?

牙雅 源資料是什麼格式?可否用load方式匯入資料庫,編寫程式分批次並行運算元據庫,生成符合要求的檔案。大型機處理億級別的資料,應該1個小時足夠了。 不是十分清楚題主遇到的是什麼樣的問題,是已經有了硬碟裡的資料要讀進來處理一下再寫回硬碟嗎?如果是這樣的話原始資料是什麼格式的呢?寫回去的時候有什麼格式...

為什麼在資料量較小的時候,CPU 計算會快於 GPU?

道窮則變 1 假定資料已經載入到主機記憶體,CPU處理資料是沒有延遲的,Gpu則需要將資料從記憶體傳輸到視訊記憶體,這裡是有延遲的。2 CPU是針對處理複雜行為而優化的,gpu是針對處理簡單行為的大量並行執行而優化的 可以對比的是,CPU相當於一輛大卡車,可以自由裝載貨物,自由規劃道路 gpu相當於...