Diskuze: Web API stahování souboru s mnoha údaji
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 11 zpráv z 11.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Když to přeneseš přes REST API nebo souborem je myslím jedno, protože
oboje jde přes síť.
Zhodnoť zda data potřebuješ najednou a jak často to chceš stahovat. Jestli
by ti pro zpracování nestačilo přenášet data po 100 000 každých 5x
minut. Tak by se ti to postupně celé načetlo.
Dále zda nemůžeš něco na serveru předpočítat aby jsi mohl přenést
méně dat.
Ještě můžeš data zkomprimovat - nepoužívat xml, použít vlastní formát
bez "značek". Případně data zazipovat.
Když by jsi napsal více podrobností o použítí dat, tak můžeme vymyslet něco více.
Můžeš uvést nějakou situaci, kde by bylo potřeba najednou 10mio záznamů? I tisíc je hodně na to, aby se tím někdo prokousával...
Problém je v tom že data posílám ve formátu JSON a následně je v aplikaci za pomocí JavaScriptSerializer deserializuji. Avšak při větším množství dat, tento deserializer hodil Exception že dat je již mnoho.
Nyní to mám vyřešené takto a funguje to docela spolehlivě. Na server pošlu žádost o vygenerování souboru, zpět se mi vrátí ticket, se kterým mohu zjišťovat, zda již generování soboru doběhlo (přeci jen vyčíst takové množství dat dost zdlouhavá operace). Jestliže již doběhlo, soubor prostě jednoduše stáhnu a předám uživateli.
Ano nakonec jsem to vymyslel tak, jak jsem odpovídal na zelvicek
Na serveru si vše předpřipravím a jakmile je soubor vygenerovaný, prostě
ho jenom stáhnu. Rychlost se pak už odvíjí jen od rychlosti sítě, což u
nás ve fimě není problém.
To je jednoduché. Tato aplikace bude sloužit k vyčítání archivu s hodnotami sklářských feederů. Z těchno feederů je zapotřebí vyčítat tyto hodnoty: teplota, setpoint, proud, napětí, příkon, odpor každých 30s
Zároveň každý feeder může mít až 10 zón. Tj: 28 800 zápisů/den; 10 512 000 zápisů/rok
Dále zde jsou různá data o odběrech elektřiny, odběrech skloviny, chybové stavy, další měření, apod... Ve finále se může jednat i o stovky až tisíce údajů, které je za potřebí ukládat a přenášet.
Naše technologové si žádájí aby bylo možné vytáhnout zpětně veškeré parametry v naprosto variabilním časovém úseku. Takže musím bohužel počítat i s variantou celého roku. Co a proč to potřebují ? Netuším, ale to není již moje starost.
Takže problém není v posílání dat, jak jsi uvedl původně, ale v deserializaci.
Problém s přetečením (čehokoliv) při deserializaci je klasika. Přitom musí být každému jasné, že do RAM nemůže narvat neomezené množství dat - zejména pokud IIS admin omezí RAM na poolu. Zde bych doporučil místo JavaScriptSerializer použít https://docs.microsoft.com/…f8jsonreader?… (nebo jiný vhodný - např.:Newtonsoft). Použití XXXReaderu se může zdát složitější, ale pokud si nad tím uděláš pár obecných zjednodušujících method, není to tak strašné. A hlavně budeš pánem nad procesem deserializace (read+materialize).
A třešnička na dortu může být implementace IEnumerator<> či IAsyncEnumerator<> nad readerem.
Trošku nechápu smysl toho, aby měli ta data všechna, protože ručně se
v tom stejně nikdo hrabat nebude. Chápal bych třeba nejnižší hodnoty,
nejvyšší, různé průměry za období, ale toto?
Ale pokud ti to takto funguje, tak OK
Ano, bohužel oni si tyto data poté vloží do Excelu a následně si s nimi
dělají co potřebují. Jak jsem psal, doopravdy netuším co s tím následně
dělají.
Tak to je upřímně lituji, pracovat v excelu s takovým množstvím dat...
Zobrazeno 11 zpráv z 11.