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

Ответ 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 позволяет передавать данные клиенту. Здесь статья, которая может быть полезна с этим.