Кой е най-ефективният във времето начин за сериализиране/десериализиране на DataTable към/от Redis?

За съжаление, когато се работи с големи набори от данни, винаги ще отнеме време за сериализиране и десериализиране на структурата. DataTable По-специално s са доста сложни обекти, тъй като имат редове и колони, които често имат много мета данни, прикачени към тях - дори когато изглежда, че е основна таблица.

`DataTable` срещу `List<POCO>` :

Помислете дали наистина трябва да се сериализирате като DataTable . Можете ли да създадете по-опростен POCO и да сериализирате List<YourRecord> ? С други думи, ако не се нуждаете от допълнителни атрибути на полета и колони и можете да сериализирате в по-опростен формат, вероятно е по-бързо и по-ефективно в кеша; и след това се възстанови в DataTable ако е необходимо.

Друга възможност е да разделите DataTable в по-малки комплекти, които сериализирате и съхранявате на по-малки части. Може да намерите това за по-ефективно. Трябва да можете да сравните това.

Сравнение:

В крайна сметка вашият Redis кеш трябва да бъде подобрение спрямо времето, необходимо за повторно запитване на източника на данни. Използвате термина takes too much time , но ако са необходими 2 секунди, за да се стигне от кеша срещу 8 секунди, за да се направи заявка към източника на данни, това е значително увеличение. Но единственият начин да сте сигурни е да сравните.

Настройте средата си, така че да използвате само необходимите инструменти. Не изпълнявайте други задачи, докато изпълнявате сравнителните показатели, за да не въвеждате пристрастия.
Запишете времето, необходимо за сериализиране на DataTable . Извършете това действие много пъти и средно.
```
var start = DateTime.Now;
// Serialize
var duration = DateTime.Now - start;
```
Експериментирайте с различни размери на DataTable и вижте дали ще намерите подходящо време.
Опитайте друга библиотека за сериализация, като JSON.NET. Макар че е хубаво да запазите целия ServiceStack, това може да ви помогне да определите дали това е недостатък на ServiceStack.Text или просто проблем с големия набор от данни.
Повторете процеса за десериализация.

Памет:

Ако работите с големи набори от данни, има ли достатъчно памет и вашето приложение, и кеш паметта? Паметта във вашето приложение може да бъде пречка; Трябва да наблюдавате монитора на активността на вашата система, докато извършвате операциите, и да се уверите, че няма да ви свърши паметта и системата ви да извършва пейджинг. Ако установите, че това се случва, помислете или за увеличаване на RAM паметта, или разделете DataTable на по-малки набори от данни, както беше споменато по-горе.

Закъснение:

Ако се свързвате със сървър на Redis през мрежа, а не на същата машина, проверили ли сте латентността на мрежата? Може да искате да изпратите пинг между вашия сървър на приложения и кеш сървъра и да се уверите, че всъщност имате нисък пинг. Особено ако откриете, че кеширането на прости обекти е бавно.

Redis?

Ако откриете, че няма начин да подобрите времето за кеширане и възстановяване, тогава може би използването на Redis не е подходящо. Може би с помощта на static DataTable в паметта на приложението би било по-подходящо. С други думи, като запазите кеша в паметта на приложението и тогава няма сериализация и десериализация, за които да се притеснявате. Разбира се, може да се наложи да внимавате да се уверите, че разполагате с достатъчно памет за вашето приложение, за да направите това. Бих се изненадал обаче, ако трябва да изберете тази опция .

Резюме:

Без да виждате вашия набор от данни или познания за услугата, която изграждате, в крайна сметка това е само общ съвет за това как най-добре да стесните причината за вашия проблем. Основният съвет е да не използвате DataTable ако по-опростена структура ще свърши работа, и проверете всяка от операциите, за да определите всички тесни места.

Надявам се това да помогне.