Лучшая архитектура для 30 + запрос часа

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

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

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

Вообще, сверхдлинные асихронные процессы не попадают в веб.

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

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

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

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

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

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

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

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

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

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

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

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

Майк,

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

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

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

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