Conception de schéma de base de données - Conseils pour améliorer la capacité d'archivage?

Question

Je conçois dans la base de données une table qui stockera les entrées de journal de l'application. Il y a quelques petites choses qui me font penser à ce design plus que d’habitude.

• Cependant, ces entrées de journal seront utilisées au moment de l'exécution par le système pour prendre des décisions. Elles doivent donc être relativement rapides à accéder.
• Ils ont également le problème, c’est qu’il y en aura beaucoup (12,5 millions d’euros supplémentaires par mois), selon mon estimation.
• Je n'ai pas besoin de plus que les 30 à 45 derniers jours pour le traitement de la décision.
• Je dois les garder tous pendant plus de 45 jours pour bénéficier de l'assistance & amp; questions juridiques, probablement au moins deux ans.
• La conception de la table est assez simple, tous les types simples (pas de blobs ou autre), dans la mesure du possible, utiliseront le moteur de base de données pour insérer les données par défaut, au plus une clé étrangère.
• Si cela fait une différence, la base de données sera Microsoft SQL Server 2005.

Ce que je pensais, c’est de les écrire sur une table / base de données, puis d’utiliser une solution ETL move & "old &"; entrées dans une table / base de données d’archives - qui est volumineuse et dont le matériel est plus lent.

Ma question est la suivante: connaissez-vous des astuces, des astuces ou des suggestions pour la conception de la base de données / des tables afin de vous assurer que cela fonctionne le mieux possible? Si vous pensez que c'est une mauvaise idée, faites-le-moi savoir, et indiquez-nous ce que vous pensez être une meilleure idée.

Answer 1

Certaines bases de données offrent des partitions " " (Oracle, par exemple). Une partition est comme une vue qui regroupe plusieurs tables de définition identique. Vous pouvez définir des critères permettant de trier les nouvelles données dans les différentes tables (par exemple, le mois ou la semaine% 6).

Du point de vue de l'utilisateur, il ne s'agit que d'une table. La base de données PoV contient plusieurs tables indépendantes. Vous pouvez ainsi exécuter des commandes complètes (telles que tronquer, supprimer, supprimer de la table (sans condition), charger / dump, etc.) de manière efficace.

Si vous ne pouvez pas avoir de partition, vous obtenez un effet similaire avec les vues. Dans ce cas, vous pouvez collecter plusieurs tables dans une seule vue et redéfinir cette vue, par exemple, une fois par mois en & "Gratuit &"; une table avec les anciennes données du reste. Maintenant, vous pouvez archiver efficacement cette table, la vider et la rattacher à la vue lorsque le gros travail est terminé. Cela devrait grandement aider à améliorer les performances.

[EDIT] SQL Server 2005 (Enterprise Edition) prend en charge les partitions. Merci à Mitch Wheat

Answer 2

Les grandes tables ralentissent rapidement et l’utilisation d’ETL pour extraire des données en fonction de la date, d’une grande table, puis supprimer les anciennes lignes est une lourde charge de performances. La solution consiste à utiliser plusieurs tableaux - probablement un tableau / mois en fonction de vos chiffres. Bien sûr, vous aurez besoin d’une certaine logique pour générer les noms de table dans vos requêtes.

Je suis d'accord avec l'utilisation de déclencheurs pour renseigner la table 'CurrentMonthAudit'. Vous pouvez alors renommer cette table en MonthAuditYYYYMM à la fin du mois. Déplacer les anciennes tables de votre serveur principal à l'aide d'ETL sera alors facile et chacune de vos tables sera gérable. Croyez-moi, c'est beaucoup mieux que d'essayer de gérer une seule table avec environ 250 millions de lignes.

Answer 3

Votre première bonne décision est de tout simplifier au maximum.

J'ai eu de la chance avec votre modèle de fichier journal de transaction en écriture seule dans lequel les enregistrements sont simplement classés dans un ordre chronologique. Ensuite, vous avez plusieurs options pour déconnecter les données anciennes. Même en ayant des tables mensuelles disparates est une requête gérable tant que vous gardez la simplicité à l'esprit. Si vous avez un type quelconque de réplication en opération, vos tables répliquées peuvent être déployées et servir d'archive. Commencez ensuite avec une nouvelle table vide le premier de chaque mois.

Normalement, je frémis devant les conséquences de la conception relationnelle sur la conception relationnelle, mais j’ai constaté que les tables de consignation chronologiques en écriture seule sont une exception des modèles de conception habituels, pour les raisons que vous avez décrites ici.

Mais évitez les déclencheurs. Le plus loin possible. La solution la plus simple est un tableau principal du type dont vous parlez ici, avec un mécanisme de réplication simple, robuste et éprouvé.

(BTW - Les grandes tables ne ralentissent pas rapidement si elles sont bien conçues - elles ralentissent lentement.)

Answer 4

Si vous n'avez pas besoin de rechercher les enregistrements de journal récents, il existe une autre option: ne pas utiliser de base de données. Au lieu de cela, écrivez les informations de journal dans un fichier et faites pivoter le nom de fichier toutes les nuits. Une fois le fichier écrit, vous pouvez alors lancer un travail en arrière-plan pour importer les données directement dans la base de données d’archives.

Les bases de données ne sont pas toujours la meilleure option, en particulier pour les fichiers journaux:)