2013-11-01 4 views
0

У нас есть большая таблица данных с примерно 30 000 0000 строк и каждый день растет со скоростью 100 000 строк в день, и это число будет увеличиваться с течением времени.Статистика на большой таблице представлена ​​в Интернете

Сегодня мы генерируем различные отчеты непосредственно из базы данных (MS-SQL 2012) и делаем много расчетов.

Проблема в том, что для этого требуется время. У нас есть индексы и так далее, но люди сегодня хотят невероятно быстрых отчетов.

Мы также хотим иметь возможность изменять временные периоды, различные способы просмотра данных и т. Д.

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

Итак, у любого из вас есть хорошие идеи по решению, которое будет быстро и по-прежнему в сети не в excel или BI-инструменте.

Сегодня все отчеты в asp.net C# WebForms с querys против MS SQL 2012 таблицы ..

+2

** Никогда ** не сообщайте о реальных данных. Создайте отдельную базу данных отчетов или еще лучше хранилище данных и куб OLAP, в котором вы будете хранить данные отчетности. Записи 30M - это относительно * маленький * объем данных при разговоре об отчетности –

+0

Если у вас есть несколько человек, которые звонят одному и тому же отчету по тем же данным, вы можете кэшировать его. – Todoy

+0

Если вы не хотите использовать решение BI, посмотрите на разбиение таблицы таким образом, если вы смотрите только на данные о днях и правильно разделяете таблицу, запрос может потенциально оценивать только один день ценность строк. – steoleary

ответ

0

У вас есть система OLTP. Обычно вы хотите максимизировать свою пропускную способность в такой системе. Отчеты потребуют защелок и блокировок для получения данных. Это приводит к перегрузке вашей OLTP-пропускной способности, и что хорошо для отчетности (дополнительные индексы) будут наносить ущерб вашему OLTP, поскольку это негативно скажется на производительности. И даже не думайте, что хлопок WITH(NOLOCK) собирается облегчить часть этого бремени. ;)

Как указывали другие, вы, вероятно, захотите рассмотреть возможность отделения активных данных от данных отчета.

Разделение таблицы может выполнить это , если у вас есть Enterprise Edition. В противном случае вам понадобится сделать хакерство вроде Paritioned Views, которое может или не может работать для вас на основе доступа к вашим данным.

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

Поскольку кажется, что у вас нет особых требований к отчетности (в настоящее время вы смотрите на вчерашние данные, но было бы неплохо увидеть больше и т. Д.), Я бы посмотрел на реализацию Columnstore Indexes в таблицах отчетов. Он обеспечивает потрясающую производительность для агрегации запросов, даже по совокупным таблицам, при этом вам не нужно указывать конкретное зерно (WTD, MTD, YTD и т. Д.). Недостатком является то, что это структура данных только для чтения (и память & cpu hog при создании индекса). SQL Server 2014 собирается ввести обновляемые индексы столбцов, которые будут хихикающими, но это некоторое время.

Смежные вопросы