Лучшая архитектура для 30 + часового запроса - PullRequest
11 голосов
/ 08 июля 2010

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

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

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

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

У кого-нибудь есть общие идеи или опыт работы с веб-архитектурой, которая будет поддерживать сверхдлинные асинхронные процессы?

Спасибо

Ответы [ 10 ]

17 голосов
/ 08 июля 2010

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

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

Лучше всего сохранять веб-запросы до одной-двух минут максимум - они никогда не были рассчитаны на большие сроки обработки. Таким образом, вы можете «проверять» статус задания каждую минуту или около того (используя веб-сервис).

Если у вас есть какие-либо вопросы обо мне или об этой идее, пожалуйста, оставьте комментарий, и я буду рад помочь, уточнить или предложить.

Надеюсь, это поможет!


(Дополнительно: я считаю, что службы Windows используются недостаточно! Все, что требуется, - это быстрый базовый класс или набор вспомогательных методов многократного использования, и у вас есть зарегистрированный, надежный, автоматический, настраиваемый, быстро реализуемый процесс, работающий под вашим управление. Быстрое создание прототипа!)

6 голосов
/ 08 июля 2010

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

5 голосов
/ 08 июля 2010

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

Однако, учитывая Мерфи, у вас, вероятно, будут некоторые длительные запросы. Различаются ли данные для разных конечных пользователей? Если нет, то почему бы не заранее вычислить ответы? Ничто из основанного на http не должно занимать больше минуты для обработки, если на то - по крайней мере, не задумано!

3 голосов
/ 08 июля 2010

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

Применяются обычные предостережения: сначала проверьте текущую реализацию фильтра на предмет узких мест производительности.Удостоверьтесь, что таблицы, по которым вы работаете, правильно проиндексированы и т. Д. Предварительно просчитайте отношения и дайджесты часто используемых вычислений.Хранилище дешево, если сэкономит время.

Ваш веб-запрос может запустить операцию разброса / сбора, распределяя запрос по доступным вычислительным узлам в облаке (Windows Azure, Google Apps, Amazon).При наличии достаточного количества вычислительных узлов и надлежащего распределения работы вы, вероятно, сможете получить ответ почти в реальном времени.

2 голосов
/ 08 июля 2010

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

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

2 голосов
/ 08 июля 2010

Шесть минут на фильтрацию данных за неделю? Похоже, ваш БД нуждается в правильной настройке индекса.

2 голосов
/ 08 июля 2010

Как правило, сверхдлинные асинхронные процессы не выходят в Интернет.

Его запрос должен быть поставлен в очередь, а другой процесс должен запустить задание и сохранить данные в формате, в котором пользователь будет их использовать.

1 голос
/ 08 июля 2010

Майк,

Есть много способов ответить на этот вопрос, но я вижу, что вам нужно задать более важный вопрос: почему для фильтрации акций требуется 6 минут?

Да, я знаю, что у вас есть данные за 50 лет и много акций, НО это не должно занять 6 минут.Поэтому, что более важно, я бы посмотрел на эту конкретную структуру таблицы, на ее индексы и на запрос, и на то, что он делает.

Раньше я работал в аналогичной компании, с таблицами почти 100 ГБ каждая.Да, размер таблицы, а не всей базы данных, и после некоторой тонкой настройки получил запросы, которые раньше занимали 15 минут + до 3 секунд.

Я хотел бы помочь вам, особенно если вы работаете на SQLСервер.Напишите мне ryk99 [at] hotmail [dot] com, и мы увидим, что мы можем сделать оттуда.

1 голос
/ 08 июля 2010

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

И предложение использовать «вычислительные узлы» только что завершило мое модное бинго, спасибо, dthorpe! вам не нужны «вычислительные узлы», только ядра. Большинство РСУБД имеют встроенную PX (параллельное выполнение). Зачем платить за облачные вычисления, которыми вы пользуетесь каждый день, просто купите сервер с достаточным количеством процессоров, у вас все будет в порядке ... Нет необходимости в "разбросе" запросов, просто включите PX ...

Понт указывает вам правильное направление. Быть довольным 6-минутным выступлением и беспокоиться о том, как составить расписание, это ваша проблема. Существует множество стратегий для управления вашими данными в форматах, обеспечивающих скорость. Индексы, разбиения, кубы, IOT. Возможно, вы делаете два прохода, а не в памяти. Ваша статистика может быть устаревшей, что может привести к плохому плану.

Я предполагаю, что вы не выполнили целую тонну настройки дБ из-за сути этого вопроса. Вы действительно должны опубликовать вопрос (ы) о настройке базы данных и сообщить нам, какую СУБД вы используете и как далеко вы уже настроились.

0 голосов
/ 08 июля 2010

Задумывались ли вы об использовании решения ETL, такого как SSIS, для предварительного заполнения ваших данных?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...