Има ли шаблон за проектиране за работа с големи масиви от данни в интернет?

моделът за проектиране на прокси е моделът, който ще помогне при прехвърлянето на данни от една точка в друга . Моделът на прокси дизайн ще ви позволи да третирате отдалечени обекти като локални.

2 предложени решения могат да бъдат

1) компресирайте вашата колекция и я декомпресирайте след прехвърляне.

2) Използвайте Flyweight + прокси модел.

Чудя се дали бихте могли да намалите количеството данни, отиващи към екрана на клиента, на първо място? Така или иначе не можете да видите 5000 точки данни наведнъж. И ако трябва да превъртате, за да търсите важните неща, помислете за филтриране на неважните неща като начало. Обмислете някои дизайни на потребителския интерфейс (табло за управление и неща от типа на измервателния уред), така че потребителят да вижда само проблемните точки. След това те могат да пробият и да предприемат необходимите действия.

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

Тук намерих статия, която изглежда обяснява как да създавам сокети в Silverlight 2 Silverlight 2 и System.Net.Sockets.Socket

Не съм го прочел много задълбочено (малко е твърде късно да го направя), но изглежда, че може да се използва във вашия случай. Основното ограничение, което видях, е, че вашето приложение silverlight може да се свърже само със сървъра, от който е изтеглено.

Ето урок за канал 9 Silverlight с използване на сокет

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

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

Когато проектирате, мисля, че ще срещнете някои DPs, които може да ви помогнат на малко ниво, но подробностите за това как трябва да работи това гигантско нещо са по-скоро общ (и интересен) проблем с дизайна.

Може би лекото изясняване на вашите въпроси може да помогне на хората да дадат съвети относно цялостния дизайн на тази система. Също така, след като сте положили малко дизайн/усилия да създадете дизайн на високо ниво за това как това трябва да работи, можете да поискате критики/предложения. Трудно е някой да измисли това изцяло като отговор на въпрос на StackOverflow. :)

Ако разбирам правилно, тук наистина има два проблема:

1. Състоянието на системата се представя от данни, идващи от множество източници на данни. Като резултат запитването за състояние е скъпо.
2. Количеството данни, които описват състоянието на системата, е голямо. В резултат на това търсенето на всички данни, които описват състоянието, е скъпо.

Стандартните модели за решаване на тези проблеми са въвеждане на средно ниво и използване на делта за актуализиране на състоянието. напр.:

1. Ясно е, че не искате вашите Silverlight клиенти да говорят директно с бекенд системи. Това не само, че може да не е възможно, но също така е много неефективно, тъй като всеки клиент може да попита същия източник на данни за своето състояние. За да се избегне това стандартно решение е да се въведе средно ниво, което агрегира данните, идващи от всички източници на данни в задната част, и също така предоставя общ интерфейс на клиентите. В резултат на това източниците на бекенд данни ще бъдат запитвани само толкова често, колкото е необходимо (може да се конфигурира за източник на данни в средното ниво), а освен това клиентите не трябва да се справят със спецификите на тези подкрепени източници на данни. Освен това можете да приложите индексиране на данните в средния слой, въз основа на най-често срещаните заявки за клиентите.

2. Ако приемем, че всеки запис ще има ID, клиентът трябва да поиска само делти от последната актуализация. Един от многото модели е използването на клеймо за време. напр. когато клиентът се инициализира, той изисква състоянието на системата и средният слой изпраща това състояние с клеймо за време. Когато клиентът трябва да актуализира определени записи, той предоставя идентификатори в заявката и времевия печат на последната актуализация. Следователно средното ниво ще изпраща само промени от последното времево клеймо и само за заявените идентификатори. Ако обектът има 15 свойства и само 3 от тях са променени след последния времеви печат, тогава актуализацията ще съдържа само стойности на тези 3 свойства.

Що се отнася до push срещу анкета - push не е автоматично най-доброто решение. Това наистина се свежда до въпроса за компромиса между това колко често клиентът трябва да се актуализира и количеството трафик между клиент/средно ниво. напр. ако промяната на състоянието е честа, но рядка (напр. засяга само няколко свойства наведнъж) и няма изискване за незабавно актуализиране на състоянието на клиента, клиентът може да предпочете промените да се натрупват, вместо да получават всяка отделна актуализация, поради което анкетирането би било за предпочитане.

Мисля, че може да пропускате нещо: от Silverlight 3 има възможност за изпращане на данни към клиента. Тук е статия, която може да бъде полезна с това.

Гласувах за няколко добри отговора, но излязох с решение с някои промени в данните от задния край и нов начин за извличане на данните от Silverlight. Ето какво се прави за справяне с това:

1. Използвам зърна, за да представя тази голяма графика с данни. Това премахна много XML предаване. Така или иначе съм загрижен само за подмножество от данни, въпреки че е доста значително подмножество. Чрез изравняване на данните в зърно мисля, че съм намалил размера на моя сериализиран обект до около 20 - 25% от оригиналната графика на обекта.
2. Почти всички данни в задната част вече ще имат поле за последната им промяна. Успях да получа това за всички големи данни. Има няколко части от данни, които няма да имат това, но истинските проблеми с производителността на заявките и агрегирането на данни бяха решени с това. Като общо решение за други, изглежда, че това е доста лесно за прилагане в редица СУБД.
3. Пиша нови API за извличане на данни, които са били актуализирани след предоставен DateTime. Това ми позволява да правя заявки само за нови и променени обекти от задната система (това е уеб услугата, която извиква тези API, а Silverlight извиква уеб услугата).
4. Агрегирайте промените в уеб услугата и открийте дали част от графиката на данни се е променила. За простота просто изпращам цялата графика с данни, ако нещо се е променило. Това всъщност беше най-трудната част за разгадаване. Част от графиката с данни може да има ново актуализирано време, но основният обект на графиката не е актуализиран. В крайна сметка трябваше да напиша API, за да търся промените на подобектите, а след това API, за да намеря основните обекти въз основа на тези подобекти (ако са били променени). Обектна графика може да бъде върната с основен обект (и всъщност голяма част от обектната графика), който не е актуализиран от последното проучване. Логиката на уеб услугата прави заявки за малък брой промени, така че въпреки че заявките не са евтини поотделно, те потенциално ще се изпълняват само няколко пъти на анкета. Дори при много големи инсталации на нашия продукт, този цикъл на заявка ще се изпълнява само 10 или 20 пъти на цикъл на анкета (вижте за моето решение за анкета по-долу). Въпреки че нашите системи са много динамични, не толкова се променят много за 30 секунди. Извикването на уеб услугата, което обработва всичко това, реагира по същия начин на първоначално извикване на зареждане, както прави анкета. Всичко, с което се занимава, е извличане на данни, по-нови от даден момент.
5. Написах колекция, която наследява от ObservableCollection, която обработва заявките и анкетите. Клиентският код, използващ тази колекция, предоставя делегат, който отправя запитвания към данните. Датата се връща асинхронно и в страници. Не съм се спрял на размера на страницата. Той продължава да прави повторни заявки за страници, докато сървърът върне страница, която е по-малка от максималния размер на страницата. Колекцията също така предоставя информация как да определите най-новата дата на най-новия обект в колекцията. Проучва периодично за актуализации, които са по-нови от най-новия елемент в колекцията. В действителност тази „последна дата“ всъщност е обект, съдържащ няколко дати на различни части от оригиналната графика на обекта. Ако даден елемент се върне от сървъра, който съществува в колекцията, елементът в колекцията се актуализира с тези върнати данни. Направих това, вместо да вмъкна новия елемент и да премахна стария, защото работи в ситуации, свързани с повече данни.

Този модел може да бъде подобрен. Мога да изпратя само делти на Silverlight за промени. Все още мога да опитам да използвам някаква технология за натискане. Но това решение ми дава едно извикване на уеб услуга, което може да върне данни за различни случаи. Проучването също е много просто и има само едно нещо, което извършва цялото извличане на данни. Няма много движещи се части. Това обработва промените в състоянието на обекта както по време на първоначалното зареждане на данни, така и по време на запитване, чрез същия механизъм. Това също изглежда се мащабира добре. Първоначалното обаждане изглежда най-скъпо, а следващите разговори протичат все по-бързо. Предполагам, че това е така, защото данните, които остават в задната част, стават все по-малки с всяко преминаване.

Все още имам един въпрос относно моята реализация на това, което Публикувах тук.

Благодаря за всички предложения. Въпреки че не се вслушах в всички съвети, няколко идеи или директно ми помогнаха, или накараха ума ми да помисля по различен начин как да накарам това да работи.