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

Question

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

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

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

Answer 1

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

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

единственная реальная проблема, с которой мы сталкиваемся, — это доступ к подробным данным, охватывающим несколько баз данных, поскольку подключение и отключение происходит медленно, а анализ необходимо выполнять в коде, а не в 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

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