Jaký je časově nejefektivnější způsob serializace/deserializace DataTable do/z Redis?

Bohužel při práci s velkými datovými sadami bude serializace a deserializace struktury vždy nějakou dobu trvat. DataTable Zejména s jsou poměrně složité objekty, protože mají řádky a sloupce, ke kterým je často připojeno mnoho metadat – i když se zdá, že jde o základní tabulku.

`DataTable` vs `List<POCO>` :

Zvažte, zda opravdu potřebujete serializovat jako DataTable . Mohli byste vytvořit jednodušší POCO a serializovat List<YourRecord> ? Jinými slovy, pokud nepotřebujete další atributy pro pole a sloupce a můžete serializovat do jednoduššího formátu, je to pravděpodobně rychlejší a efektivnější v mezipaměti; a poté obnovit do DataTable v případě potřeby.

Další možností je rozdělit DataTable do menších sad, které serializujete a skladujete po menších částech. Možná vám to přijde výkonnější. Měli byste být schopni to porovnat.

Srovnávací:

V konečném důsledku by vaše mezipaměť Redis měla být vylepšením oproti času potřebnému k opětovnému dotazu na zdroj dat. Používáte výraz takes too much time , ale pokud trvá 2 sekundy, než se dostanete z mezipaměti, oproti 8 sekundám dotaz na zdroj dat, pak je to významný nárůst. Ale jediný způsob, jak mít jistotu, je provést benchmark.

Nastavte své prostředí tak, abyste spouštěli pouze nezbytné nástroje. Během spouštění srovnávacích testů neprovádějte žádné jiné úkoly, abyste nezavedli žádné zkreslení.
Zaznamenejte si čas potřebný k serializaci DataTable . Proveďte tuto akci mnohokrát a průměrně.
```
var start = DateTime.Now;
// Serialize
var duration = DateTime.Now - start;
```
Experimentujte s různými velikostmi DataTable s a uvidíte, zda najdete přijatelný čas.
Zkuste jinou serializační knihovnu, například JSON.NET. I když je hezké ponechat si vše ServiceStack, může vám to pomoci určit, zda se jedná o nedostatek ServiceStack.Text nebo jen problém s velkou datovou sadou.
Opakujte proces pro deserializaci.

Paměť:

Pokud pracujete s velkými datovými sadami, má vaše aplikace i mezipaměť dostatek paměti? Paměť ve vaší aplikaci může být úzkým hrdlem; Při provádění operací byste měli sledovat monitor aktivity vašeho systému a ujistit se, že vám nedochází paměť a že váš systém provádí stránkování. Pokud zjistíte, že k tomu dochází, zvažte buď zvýšení paměti RAM, nebo rozdělte DataTable na menší datové sady, jak bylo uvedeno výše.

Latence:

Pokud se připojujete k serveru Redis přes síť a ne na stejném počítači, zkontrolovali jste latenci sítě? Možná budete chtít provést ping mezi vaším aplikačním serverem a serverem mezipaměti a ujistit se, že máte skutečně nízký ping. Zejména pokud zjistíte, že ukládání jednoduchých objektů do mezipaměti je pomalé.

Redis?

Pokud zjišťujete, že neexistuje způsob, jak zlepšit dobu ukládání do mezipaměti a obnovy, pak možná použití Redis není to pravé. Možná pomocí static DataTable v paměti aplikace by bylo vhodnější. Jinými slovy, ponecháním mezipaměti v paměti aplikace a pak se nemusíte starat o serializaci a deserializaci. Samozřejmě si možná budete muset dávat pozor, abyste zajistili, že k tomu máte pro vaši aplikaci dostatek paměti. Překvapilo by mě však, kdybyste si museli vybrat tuto možnost .

Shrnutí:

Aniž byste viděli svůj datový soubor nebo znali službu, kterou vytváříte, je to nakonec pouze obecná rada o tom, jak nejlépe zúžit příčinu vašeho problému. Klíčovým doporučením je nepoužívat DataTable pokud to bude stačit jednodušší struktura, a porovnejte každou z operací, abyste určili případná úzká hrdla.

Doufám, že to pomůže.