Какова лучшая стратегия для сохранения больших наборов данных?

Question

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

Какова лучшая стратегия для решения этой ситуации? Просто заархивировать старые данные в другую таблицу? Или «свернуть» путем некоторой консолидации самих данных (а затем сохранить их в другой таблице)? Или что-то еще целиком?

Дополнительная информация: мы используем SQL Server 2005.

Answer 1

Мы используем оба метода на моей работе, но немного отличаемся, мы храним все данные о продажах в первичной таблице в течение 30 дней, а затем ночью (часть ночных заданий) дни продаж объединяются в сводки (кол-во x продукт продан сегодня и т. д.) в отдельной таблице по причинам отчетности, а продажи за 30 дней архивируются в другую базу данных, затем один раз в год (мы проводим налоговые годы) запускается новая архивная база данных. не совсем идеально, но ..

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

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

Answer 2

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

Answer 3

В зависимости от ограничений, таких как бюджет и т. Д., Это звучит как идеальный кандидат для приложения хранилища данных. Это обычно вводит новый сервер для использования в качестве хранилища данных. SQL Server 2005 поддерживает многие из этих действий "из коробки", кроме того, вы можете использовать дополнительные службы SQL Server (например, службы Analysis Services, службы Reporting Services), чтобы предоставить дополнительную ценность своим пользователям. (см. http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)

Answer 4

@ Джейсон - я не понимаю, как хранение данных в простых старых текстовых файлах позволит вам легко выполнять долгосрочный анализ тенденций в данных.

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

Answer 5

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