лучший способ сделать отчет за миллион строк

Question

У меня есть две таблицы базы данных, subscription и transaction, где в одной подписке может быть много транзакций. Статус подписки зависит в основном от транзакций, которые к ней относятся. Поэтому, если я хочу вычислить дату следующего процесса, я бы посмотрел на поле периода объекта подписки, а затем проанализировал транзакции подписки, чтобы определить ее статус. Это все отлично работает.

Проблема, с которой я сталкиваюсь, состоит в том, что таблица содержит более 400 000 объектов подписки и миллионы записей транзакций, поэтому довольно сложно создать сводный отчет по подпискам (например, сколько из каждого из примерно десяти возможных состояний, которые являются рассчитывается динамически)

Поскольку вся логика для расчета состояния каждой подписки находится в коде c #, я должен загрузить весь граф объектов подписки со всеми их дочерними объектами транзакций, используя linq-to-sql. Это занимает довольно много времени, может быть, две минуты или около того. Я смотрю на кеширование, но не буду давать результаты в реальном времени. Мне просто интересно, есть ли стратегия, которая могла бы решить эту проблему, или, может быть, индекс в моей базе данных, который может ускорить запрос linq to sql. Или, если бы я просто придумал это с самого начала.

Спасибо.

Answer 1

Поскольку вся логика для расчета статус каждой подписки находится в код C #, я должен загрузить весь график объектов подписки со всеми их дочерней транзакции

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Можете ли вы создать представление, содержащее логику для расчета требуемого статуса? Это, вероятно, уменьшит количество операций ввода-вывода, поскольку не нужно будет возвращать столько данных клиенту.