загрузка большого количества данных больших двоичных объектов Azure в приложение WPF

Насколько я понимаю, у вас есть набор файлов журнала в хранилище BLOB-объектов Azure, которые отформатированы определенным образом (gzip), и вы хотите их отобразить.

Насколько велики эти файлы? Отображаете ли вы каждую часть информации в файле журнала?

Предполагая, что если это файл журнала, он является статическим и историческим... это означает, что после создания файла журнала/gzip его нельзя изменить (вы не обновляете файл gzip, когда он отсутствует в хранилище блога). Можно создавать только новые файлы...

Одно решение

Почему бы не создать рабочую роль/рабочий процесс, который периодически сканирует хранилище больших двоичных объектов и создает постоянную «базу данных», чтобы вы могли ее отображать. Хорошая вещь в этом заключается в том, что вы не используете распаковку/бизнес-логику для извлечения файла журнала в приложении или пользовательском интерфейсе WPF.

1) Я бы попросил рабочую роль сканировать файл журнала в хранилище BLOB-объектов Azure. 2) Иметь какой-то механизм для отслеживания того, какие из них были обработаны, и текущее «состояние», возможно, дату UTC последнего файла gzip. 3) Выполнить всю распаковку /извлечение файла журнала в рабочей роли. 4) Рабочая роль помещает содержимое в базу данных SQL, хранилище таблиц Azure или распределенный кэш для доступа. 5) Доступ может осуществляться с помощью службы REST (ASP.NET Web API/Node). .js и т. д.)

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

Хорошая вещь в этом заключается в том, что если вам нужно масштабировать свою работу (в одночасье), вы можете развернуть 2, 3, 6 рабочих ролей ... извлечь контент, передать результат в служебную шину или очередь хранения, которые будут вставлены в SQL , кэш и т.д. для доступа.

Простого хранения больших двоичных объектов недостаточно. Метаданные, которые вы хотите отфильтровать, должны храниться в другом месте, где их можно легко отфильтровать и получить все метаданные. Поэтому я думаю, что вы должны разделить это на 2 проблемы:

A. Как мне эффективно составить список всех «gzip» с их метаданными и как применить фильтр к этим gzip-файлам, чтобы отобразить их в моем клиентском приложении.

Решения

• Большие двоичные объекты: список больших двоичных объектов выполняется медленно, а фильтрация невозможна (вы можете группировать в контейнере по месяцам, неделям, пользователям или ..., но это не фильтрация).
• Хранилище таблиц: Очень быстро, но поиск медленный (индексируются только PK и RK)
• SQL Azure: вы можете создать таблицу со списком «gzip» вместе с некоторыми другими метаданными (например, пользователь, создавший gzip, когда, общий размер и т. д.). Используя хранимую процедуру с несколькими хорошими индексами, вы можете сделать поиск очень быстрым, но SQL Azure — не самое масштабируемое решение.
• Lucene.NET: существует AzureDirectory для Windows Azure, который позволяет использовать Lucene.NET в вашем приложении. Это сверхбыстрая поисковая система, которая позволяет вам индексировать ваши «документы» (метаданные), и это идеально подходит для фильтрации и возврата списка «gzip».

Обновление. Поскольку вы фильтруете только по дате и серьезности, вам следует просмотреть параметры больших двоичных объектов и таблиц:

• Большие двоичные объекты: вы можете создать контейнер на дату + уровень серьезности (20121107-низкий, 20121107-средний, 20121107-высокий...). Предполагая, что у вас не слишком много больших двоичных объектов на данные + серьезность, вы можете просто перечислить большие двоичные объекты непосредственно из контейнера. Единственная проблема, которая может возникнуть здесь, заключается в том, что пользователь захочет просмотреть все элементы с высокой серьезностью за последнюю неделю (7 дней). Это означает, что вам нужно перечислить большие двоичные объекты в 7 контейнерах.
• Таблицы: даже если вы говорите, что хранилище таблиц или БД не вариант, подумайте о хранении таблиц. Используя разделы и ключи строк, вы можете легко фильтровать очень масштабируемым способом (вы также можете использовать CompareTo, чтобы получить диапазон элементов (например, все записи с 1 по 7 ноября). Дублирование данных идеально приемлемо в хранилище таблиц. Вы можете включить некоторые данные из gzip в объект хранилища таблиц, чтобы отобразить их в своем приложении WPF (наиболее важная информация, которую вы хотите отобразить после фильтрации). Это означает, что вам нужно будет обработать только blob, когда пользователь открывает/дважды щелкает запись в приложении WPF

B. Как отобразить "gzip" в моем приложении (например, после двойного щелчка по результату поиска)

Решения

• Подключитесь к учетной записи хранения из приложения WPF, загрузите файл, распакуйте его и отобразите. Это означает, что вам нужно будет сохранить учетную запись хранения в приложении WPF (или использовать SAS или политику контейнера), и если вы решите изменить что-то в бэкэнде, как хранятся файлы, вам также нужно будет изменить WPF-приложение.
• Подключиться к веб-роли. Эта веб-роль получает большой двоичный объект из хранилища больших двоичных объектов, распаковывает его и отправляет по сети (или отправляет в сжатом виде, чтобы ускорить передачу). Если что-то изменится в том, как вы храните файлы, вам нужно только обновить веб-роль.