Quelle est la meilleure stratégie pour la conservation de grands ensembles de données ?

Question

Je dirige un projet où nous allons enregistrer des données métriques. J'aimerais conserver ces données pendant des années. Cependant, j'aimerais également éviter que la table primaire ne soit encombrée de données qui, bien que nécessaires pour les tendances à long terme, ne le sont pas pour les rapports à court terme.

Quelle est la meilleure stratégie pour gérer cette situation ? Archiver simplement les anciennes données dans une autre table ? Ou bien "l'enrouler" en consolidant les données elles-mêmes (puis en les stockant dans une autre table) ? Ou quelque chose d'entièrement différent ?

Info supplémentaire : nous utilisons SQL Server 2005.

Answer 1

Nous utilisons les deux méthodes à mon travail, mais légèrement différentes, nous conservons toutes les données de vente dans la table primaire pendant 30 jours, puis la nuit (dans le cadre des travaux de nuit) les ventes du jour sont regroupées dans des résumés (n qté de x produit vendu aujourd'hui ect) dans une table séparée pour des raisons de rapport, et les ventes de plus de 30 jours sont archivées dans une base de données différente, puis une fois par an (nous allons sur les années fiscales) une nouvelle base de données d'archives est démarrée. pas exactement parfait mais .

De cette façon, nous obtenons rapidement les résumés, nous gardons à portée de main toutes les données de vente actuelles et nous disposons d'un espace illimité pour les données d'archive détaillées. Nous avons essayé de tout conserver dans une seule base de données (dans différentes tables), mais la taille du fichier de la base de données (interbase) devenait si importante qu'elle entraînait l'arrêt du système.

le seul véritable problème que nous rencontrons est l'accès à des données détaillées qui couvrent plusieurs bases de données, car la connexion et la déconnexion sont lentes, et l'analyse doit être faite en code plutôt qu'en sql.

Answer 2

Si vous utilisez le serveur SQL 2005, vous pouvez utiliser la méthode suivante tables partitionnées .

Answer 3

@Jason - Je ne vois pas comment le fait de conserver les données dans de simples fichiers texte vous permettra d'effectuer facilement des analyses de tendances à long terme sur ces données.

@Jason - Je pense que ce que je veux dire, c'est que si une analyse ad hoc (c'est-à-dire une analyse des tendances) doit être effectuée sur les données par des personnes de l'entreprise, l'enroulement ou l'archivage des données dans des fichiers texte ne résout pas vraiment les problèmes. Bien sûr, écrire du code pour consommer un fichier texte est facile dans de nombreux langages, mais ce problème a été résolu. De plus, je dirais que les SGBDR d'aujourd'hui sont tous extrêmement durables lorsqu'ils sont configurés et maintenus correctement. S'ils ne l'étaient pas, pourquoi faire fonctionner une entreprise à partir d'un tel système (sans parler de l'archivage des données) ? Je ne vois pas l'intérêt d'archiver des données dans un fichier texte simple, sous prétexte que la durabilité des fichiers texte est supérieure à celle des bases de données.

Answer 4

En fonction de contraintes telles que le budget, etc., cela semble être un candidat parfait pour une application d'entrepôt de données. Il s'agit généralement d'introduire un nouveau serveur pour l'utiliser comme entrepôt de données. SQL Server 2005 prend en charge une grande partie de cette activité, mais vous pouvez également utiliser d'autres services SQL Server (par exemple, Analysis Services, Reporting Services) pour offrir une valeur ajoutée à vos utilisateurs. (voir http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx )

Answer 5

L'une ou l'autre de ces options est excellente, mais cela dépend vraiment du domaine du problème. Pour des choses comme les soldes de caisse ou les données statistiques, je pense que la meilleure solution consiste à enrouler les enregistrements et à les consolider. Vous pouvez ensuite déplacer les enregistrements enroulés dans une table d'archives parallèle, en les saisissant de manière à pouvoir les "dérouler" si nécessaire. Ainsi, votre table de données primaire reste propre et rapide, mais vous pouvez conserver les données supplémentaires à des fins d'audit ou autres. La question clé est de savoir comment mettre en œuvre le processus de "roll-up". Soit automatiquement, via un déclencheur ou un processus côté serveur, soit par une intervention de l'utilisateur au niveau de l'application ?