Помогите выяснить подходы к (почти) в реальном времени запросам многомерных данных

Question

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

1. Дайте мне все с категорией куртки
2. Дайте мне все с категорией курток-> Парки красного цвета, купленные в прошлом месяце в Нью-Йорке.
3. Дайте мне все, что не было куплено в Нью-Йорке и стоит более 100 долларов.

В настоящее время у нас очень длинный SP, который использует подход «каскадных данных» - мы идем таблица за таблицей, фильтруя все во временную таблицу, используя те критерии, которые были указаны для этой таблицы. Для следующей таблицы мы присоединяем текущую временную таблицу к любой используемой таблице и применяем новый набор фильтров к новой временной таблице. Это работает, но управляемость и производительность медленные. Мне нужно что-то лучше.

Мне нужен новый подход к этой проблеме. Это явно необходимость в OLAP, возможно, с использованием звездообразной схемы. Работает ли это в реальном времени? Можно ли настроить его на работу в реальном времени? Должен ли я использовать индексированные представления для создания набора денормализованных таблиц? Должен ли я полностью разгрузить это вне базы данных?

К вашему сведению Мы используем Sql Server.

Answer 1

Как вы говорите, это идеально подходит для OLAP. С Sql Server 2005 и 2008 вы можете настроить решение практически в режиме реального времени. Вы должны:

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

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

Answer 2

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

Answer 3

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

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

Производительность превысила бы использование всех временных таблиц, и вы могли бы получить некоторые преимущества кэширования после выполнения нескольких запросов.