Gestion d'énormes enregistrements de transactions?

Question

J'ai une application planifiée et j'obtiens des données d'une autre table de base de données et des dumps dans ma table de base de données principale, le nombre d'enregistrements dans cette table augmente tous les jours. Ces données sont utilisées pour le traitement par l'application principale qui prend chaque enregistrement et fait l'analyse nécessaire et marque chaque enregistrement tel que traité.

Quel type de solution puis-je fournir afin de pouvoir réduire la taille de la base de données à l'avenir?

Comment vous y prendrez-vous dans cette situation? De mon observation de quelques applications d'entreprise, l'un fournit une option que l'utilisateur peut archiver des enregistrements 'plus de 60 jours' etc ... dans un fichier texte. Bien je pourrais fournir une option pour archiver les enregistrements traités à un fichier texte et supprimer les enregistrements de la base de données, le fichier texte pourrait être importé plus tard si nécessaire? Est-ce une solution?

Answer 1

Si vous avez besoin d'accéder occasionnellement à ces données plus anciennes, la création d'un processus pour l'archiver en texte, puis pour recharger du texte n'est probablement pas une excellente solution. Les disques durs sont bon marché.

Vous pouvez agréger les anciennes données. Par exemple, si les données de transaction sont à la milliseconde maintenant, mais que vous enregistrez des données plus anciennes à la fin de la journée, envisagez d'agréger les données à "tous les jours" comme processus d'archivage. Vous pouvez être en mesure de réduire des centaines de milliers de lignes en un nombre réduit pour chaque jour. Vous pouvez également conserver les transactions les plus récentes sur un jeu de disques et les données archivées sur d'autres disques, dans un processus où vous pouvez facilement ajouter de nouveaux disques et créer des tables sur ces disques.

Answer 2

À mon humble avis, cela dépend de la probabilité que l'utilisateur devra analyser les données passées. Si c'est possible, créez simplement de bons index et conservez toutes les données dans votre base de données principale.

Si ce n'est pas le cas, déposez-le sur un TXT. Le moment où cela arrive doit être configurable bien sûr.

Answer 3

De quel type de données de communication de données votre entreprise a-t-elle besoin? Laisser tomber les données archivées dans un fichier texte est très bien, en supposant que vous n'avez pas besoin d'être en mesure de signaler ces données à l'avenir. Cependant, l'avoir dans un fichier texte signifie que vous devez avoir un processus manuel pour l'importer à la demande dans une base de données quand cela est nécessaire. Une meilleure option consisterait à déplacer les données d'archivage dans une base de données d'entrepôt de données qui n'est pas utilisée pour le traitement des transactions (OLTP) et qui est utilisée comme base d'une base de données de traitement analytique (OLAP). Quand vient le temps de rapporter ces données archivées, c'est prêt à partir. Si vous êtes attentif à la manière dont vous structurez les données dans cette base de données d'archives, il devrait être très facile de regrouper toutes les données dans un cube OLAP, ce qui rend la création de rapports plus rapide et plus flexible. Mais encore une fois ... cela dépend de si vous faites un rapport sur les données ou non, et dans quelle mesure ces rapports peuvent remonter dans le temps.

Answer 4

Cela dépend de la quantité d'analyses effectuées sur les données passées, mais il existe un moyen de tout conserver dans la base de données sans que les performances ne deviennent un problème.

La solution qui vient à l'esprit est de partitionner les tables en question. Mon entreprise dispose d'une table de base de données dont les données sont partitionnées par mois, chacune contenant environ 20 millions de lignes.Le partitionnement fait à l'aide de ces données beaucoup plus pratique que si elle était stockée dans une seule table. Maintenant, la seule contrainte réelle est l'espace disque, ce qui est un non-problème étant donné la façon dont il est pas cher ces jours-ci.

Je sais, cependant, que certaines bases de données ne prennent pas en charge le partitionnement. Si tel est le cas, je suppose que le stockage des données dans un fichier délimité serait une solution appropriée.