Существует ли шаблон проектирования для работы с большими наборами данных через Интернет?

Я ищу шаблон дизайна, который обрабатывает большие наборы данных через Интернет и выполняет периодическое обновление этих объектов. Я разрабатываю приложение, которое будет отображать тысячи записей в пользовательском интерфейсе за один раз. Кроме того, различные свойства этих объектов являются довольно временными и нуждаются в обновлении на клиенте, чтобы информировать пользователя об изменении состояния этих записей в системе. У меня есть несколько идей, как подойти к этой проблеме, но предположил, что там может быть шаблон (или шаблоны) дизайна, который обрабатывает этот тип сценария.

Ограничения:

Клиентская сторона для этого написана в Silverlight.
Объекты сами по себе не очень большие (около 15 значений типа и строковых свойств), но запросы для всех данных дороги. 15 свойств содержат данные из разных источников; никакая умная операция объединения или индексация не ускорит запрос. Я подумываю о заполнении только подмножества свойств при начальной загрузке и затем заполнении более дорогих деталей, когда пользователь приближается к заданной группировке объектов. Подумайте, Google maps, но вместо улиц и зданий он показывает объекты.
Я смогу ограничить часть тысяч объектов, которые обновляются. Тем не менее, я буду нуждаться в том, чтобы пользователь мог "уменьшить" контекст, который позволяет гранулировать обновление, которое показывает все тысячи объектов. Я предполагаю, что обновление будет снова отключено для объектов, когда они оставят достаточный контекст масштабирования.

Идеи о том, как решить всю или часть этой проблемы? Как я уже упоминал, я уже подумываю о нескольких идеях, но ничто из того, что я собрал до сих пор, не дает мне хорошего представления об успехе этого проекта.

Edit:

Я думаю, что трудные части действительно сводятся к двум вещам, для которых мне могут понадобиться две разные модели/практики/стратегии:

Загрузка большого количества записей через Интернет (~ 5k).
Сохранение подмножества этих объектов (~ 500) с обновлением по Интернету.

Существует несколько шаблонов проектирования, которые можно использовать для всего остального.

Изменить 2:

Спасибо за ссылки на различные реализации "push" в Silverlight. Я мог поклясться, что сокеты были вывезены из Silverlight, но нашли ссылку Silverlight 3, основанную на ответе ниже. Для меня это все равно не было большой проблемой, и я не потратил много времени на изучение, поэтому я редактирую это из оригинального текста. Независимо от того, происходят ли обновления в опросах или через push, общие проблемы дизайна все еще существуют. Хорошо знать, что у меня есть варианты.

Редактировать 3: Последующие действия над технологиями push.

Как я и предполагал, реализация дуплекса Silverlight WCF кометный push. Это не будет масштабироваться, и есть множество статей о том, как это не происходит в реальном мире.

Реализация сокетов в Silverlight повреждена несколькими способами. Похоже, что это будет бесполезно в нашем сценарии, так как веб-сервер может зависеть от любого конкретного брандмауэра клиента, который не позволит нестандартным портам, а разъемы Silverlight не будут подключаться на 80, 443 и т.д.

Я все еще думаю, используя подход WCFduplex в некотором ограниченном ключе, но похоже, что опрос будет ответом.

Изменить 4: Найден шаблон для решения половины моей проблемы

Я нашел этот шаблон (PDF), который иллюстрирует использование шаблона итератора для извлечения страниц данных из сервер и представить их как простой итератор. В среде .Net я предполагаю, что это будет реализовано как IEnumerable (код примеров находится в Java и Oracle SQL). Особый интерес для меня представлял асинхронный предварительный выбор страниц, в основном буферизирующий результирующий набор на стороне клиента. С объектами 5k все сразу не будет помещаться на экране, поэтому я могу использовать стратегию не получать все сразу, но скрывать эту деталь реализации из пользовательского интерфейса. Основные объекты, которые приложение будет извлекать, находятся в базе данных, тогда для полного заполнения этих объектов требуются другие функции поиска. Эта методология кажется хорошим подходом к быстрому извлечению некоторых данных клиенту.

Теперь я думаю об использовании этого patter + своего рода шаблона прокси-объекта, который прислушивается к дельтам к набору результатов и соответственно обновляет объект. Есть несколько стратегий, которые можно было бы предпринять здесь. Я мог загружать все данные upfront, а затем отправлять дельтах изменений (что, вероятно, потребуется дополнительный код в подсистемах для уведомления об изменениях). Это может быть мой первый подход. Я все еще смотрю. Спасибо за все идеи.

Ответ 1

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

Я использую beans для представления этого большого графика данных. Это удалено много для передачи XML. В любом случае я интересуюсь только подмножеством данных, хотя это довольно значительное подмножество. Сглаживая данные в bean, я думаю, что сократил свой размер сериализованного объекта примерно до 20-25% от исходного графа объектов.
Почти все данные на задней панели теперь будут иметь поле в последний раз, когда оно было изменено. Я смог получить это для всех больших данных. Есть несколько данных, которые не будут иметь этого, но реальные проблемы производительности запросов и агрегации данных были решены с этим. Как общее решение для других, похоже, что это довольно просто реализовать в ряде СУБД.
Я пишу новые API для извлечения данных, которые были обновлены после предоставленного DateTime. Это позволяет мне запрашивать только новые и измененные объекты из внутренней системы (это веб-служба, вызывающая эти API, и Silverlight вызывает веб-службу).
Совокупные изменения в веб-службе и обнаружение изменения части документа. Для простоты я просто отправляю полный абзац, если что-то изменилось. На самом деле это была самая сложная задача. Часть этого абзаца может иметь новое обновленное время, но основной объект графика не обновляется. Мне пришлось писать API-интерфейсы для поиска изменений под-объектов, а затем API для поиска корневых объектов на основе этих под-объектов (если они были изменены). Граф объекта может быть возвращен с корневым объектом (и фактически большей частью графика объекта), который не был обновлен со времени последнего опроса. Логика веб-сервиса запрашивает небольшое количество изменений, поэтому, несмотря на то, что запросы не являются дешевыми по отдельности, они потенциально могут работать только несколько раз за опрос. Даже в очень больших установках нашего продукта этот цикл запросов будет выполняться только 10 или 20 раз за цикл опроса (см. Ниже мой опрос). Хотя наши системы очень динамичны, не так много изменений за 30 секунд. Вызов веб-службы, который обрабатывает все это, реагирует одинаково на начальный вызов загрузки, поскольку он выполняет опрос. Все, что связано с этим, - это получение данных более новым, чем заданное время.
Я написал коллекцию, наследующую от ObservableCollection, которая обрабатывает запрос и опрос. Клиентский код с использованием этой коллекции предоставляет делегат, который запрашивает данные. Дата возвращается асинхронно и на страницах. Я не установил размер страницы. Он сохраняет повторный запрос для страниц, пока сервер не вернет страницу, которая меньше максимального размера страницы. В сборнике также представлена информация о том, как определить самую последнюю дату новейшего объекта в коллекции. Он периодически проверяет обновления, которые новее, чем новый элемент коллекции. В действительности эта "последняя дата" на самом деле представляет собой объект, содержащий несколько дат различных частей исходного графа объектов. Если элемент возвращается с сервера, который существует в коллекции, элемент в коллекции обновляется с возвращенными данными. Я сделал это вместо того, чтобы вставлять новый элемент и удалять старый, потому что он работает в более сложных ситуациях.

Этот шаблон можно улучшить. Я могу отправить только deltas в Silverlight для внесения изменений. Я все еще мог попытаться использовать какую-то технологию push. Но это решение дает мне один вызов веб-службы, который может возвращать данные для разных случаев. Опрос также очень прост, и есть всего лишь одна вещь, которая делает все данные. Не так много движущихся частей. Это обрабатывает изменения состояния объекта как во время начальной загрузки данных, так и во время опроса по тому же механизму. Это также, по-видимому, хорошо масштабируется. Первоначальный вызов кажется самым дорогим, если последующие вызовы выполняются все быстрее и быстрее. Я бы предположил, что это происходит потому, что данные, оставшиеся на back-end, становятся все меньше и меньше с каждым проходом.

У меня все еще есть один вопрос о моей реализации этого который я опубликовал здесь.

Спасибо за все предложения. Хотя я не прислушался ко всем советам, некоторые идеи либо напрямую помогли мне, либо заставили меня думать о другом пути, как это сделать.

Ответ 2

шаблон прокси-сервера - это шаблон, который поможет в передаче данных из одной точки в другую. Шаблон проектирования прокси позволит вам обрабатывать удаленные объекты, как если бы они были локальными.

Ответ 3

2 предложенные решения могут быть

1) сжимайте свою коллекцию и распаковывайте ее после переноса.

2) Используйте шаблон Flyweight + proxy.

Ответ 4

Интересно, можно ли в первую очередь уменьшить объем данных, идущих на экран клиента? В любом случае вы не можете видеть 5000 точек данных. И если вам нужно прокрутить страницу, чтобы найти важный материал, подумайте о том, чтобы начать отфильтровывать не важные вещи. Подумайте о некоторых конструкциях пользовательского интерфейса (приборной панели и типа калибровочного типа), чтобы пользователь видел только пятна проблем. Затем они могут просверливаться и действовать по мере необходимости.

Я знаю, что вы не можете раскрыть детали, и я сделал массу предположений, и это не прямой технический ответ на ваш вопрос, но, возможно, переосмысление необходимого фида данных поможет вам в более эффективном направлении для обоих back-end и front-end.

Ответ 5

Здесь я нашел статью, которая, похоже, объясняет, как создавать сокеты в Silverlight 2 Silverlight 2 и System.Net.Sockets.Socket

Я не читал его очень глубоко (мне слишком поздно делать это), но кажется, что он может быть использован в вашем случае. Основное ограничение, которое я видел, это то, что приложение silverlight может подключаться только к серверу, на котором он был загружен.

Здесь учебник по каналу 9 Silverlight с использованием сокета

Я надеюсь, что это поможет

Ответ 6

В целом, я думаю, что ответ на ваш вопрос заключается в том, что нет ни одного шаблона дизайна, который действительно решит вашу проблему. Вместо этого это отличный пример прилично крупномасштабного приложения, которому просто нужно много планирования и проектирования.

Когда вы проектируете, я думаю, что вы столкнетесь с некоторыми DP, которые могут помочь вам на небольшом уровне, но детали того, как эта гигантская вещь должна работать, скорее являются общей (и интересной) проблемой дизайна.

Возможно, разъяснение ваших вопросов немного может помочь людям дать советы по общему дизайну для этой системы. Кроме того, как только вы приложите немного усилий для разработки высокоуровневого дизайна того, как это должно работать, вы можете запросить критику/предложения. Трудно кому-то придумать это полностью как ответ на вопрос StackOverflow.:)

Ответ 7

Если я правильно понимаю, здесь есть две проблемы:

Состояние системы представлено данными, поступающими из нескольких источников данных. В результате запрос на состояние дорог.
Объем данных, описывающих состояние системы, большой. В результате запрос всех данных, описывающих состояние, является дорогостоящим.

Стандартными шаблонами для решения этих проблем являются введение среднего уровня и использование дельт для обновления состояния. Например:.

Очевидно, что вы не хотите, чтобы ваши клиенты Silverlight напрямую разговаривали с бэкэнд-системами. Не только это может быть невозможно, но и очень неэффективно, поскольку каждый клиент может запросить тот же источник данных о своем состоянии. Чтобы избежать этого стандартного решения, необходимо ввести средний уровень, который объединяет данные, поступающие из всех исходных источников данных, а также обеспечивает общий интерфейс для клиентов. В результате исходные источники данных будут опробованы только так часто, как это необходимо (могут быть настроены для каждого источника данных в среднем уровне), а также клиентам не нужно иметь дело со спецификой этих резервных источников данных. Кроме того, вы можете внедрить индексирование данных в средний уровень на основе запросов, наиболее распространенных для клиентов.
Предполагая, что каждая запись будет иметь идентификатор, клиент должен запрашивать только дельта с момента последнего обновления. Один из многих шаблонов - использовать временную метку. Например. когда клиент инициализирует его, запрашивает состояние системы, а средний уровень отправляет это состояние с отметкой времени. Когда клиенту необходимо обновить определенные записи, он предоставляет идентификаторы в запросе и временную метку последнего обновления. Поэтому средний уровень отправляет только изменения с этой последней метки времени и только для запрошенных идентификаторов. Если объект имеет 15 свойств, и только 3 из них были изменены с момента последней отметки времени, то обновление будет содержать только значения этих трех свойств.

Что касается push и poll - push, это не самое лучшее решение. Речь идет о компромиссе между тем, как часто нужно обновлять клиент и объем трафика между клиентом/средним уровнем. Например. если изменение состояния является частым, но разреженным (например, влияет только на несколько свойств за раз), и нет необходимости немедленно обновлять состояние клиента, клиент может предпочесть, чтобы изменения накапливались, а не получали каждое отдельное обновление, поэтому опрос был бы предпочтительным.

Ответ 8

Я думаю, что вы можете чего-то упустить: поскольку Silverlight 3 позволяет передавать данные клиенту. Здесь статья, которая может быть полезна с этим.