Lignes directrices pour la duplication des tables de base de données

Question

J'ai un flux de données constant. Toutes les données doivent être stockées dans la base de données avec un horodatage. Les données sont dans un 5 minutes d'intervalle et une sélection des dernières données est effectuée dans le même intervalle, en pseudo code SQL:

SELECT * FROM TB_TABLE WHERE TIMESTAMP = MAX(TIMESTAMP) 

Comme ce tableau pousse très gros (giga-octets), je l'ai fait une optimisation prématurée le diviser en deux tables: une pour toutes les données (seulement pour les insertions), et une autre pour les dernières données (pour les insertions, supprimer et sélectionner).

Je me demande si cette duplication est une bonne chose à faire, puisque je n'ai aucune mesure pour prouver qu'elle a amélioré les performances de mes applications. En tant que lignes directrices générales, recommanderiez-vous ce que j'ai fait?

Mise à jour BTW J'utilise MS SQL Server 2005 et .NET C# LINQ to Sql

Answer 1

Je me demande si le partitionnement de table serait utile. Je ne l'ai pas personnellement utilisé, donc je ne peux pas parler d'expérience, mais cela semble être la situation appropriée pour l'utiliser.

Answer 2

tables Fractionnement avec un volume d'entrée élevé dans une écriture optimisée tableau « récente » et une lecture optimisé « archive » La table est généralement une très bonne optimisation. Cela augmente la complexité, alors vous ne voulez pas le faire là où ce n'est pas nécessaire, mais c'est raisonnable si vous êtes sûr que la table en question va recevoir des tonnes de données.

Answer 3

Je ne recommanderais pas l'approche que vous avez prise. Si l'intention était d'améliorer les performances des applications, il aurait été plus approprié de collecter les métriques de performance en premier. Si une tendance indiquait une diminution de la performance à mesure que la quantité de données augmentait, il serait clair qu'une modification de la base de données était appropriée. En supposant que votre principale préoccupation est la performance des sélections sur une grande table, des étapes comme l'application de bons index et le remplacement de "select *" par les colonnes que vous voulez peut être un meilleur point de départ que la duplication de données sur plusieurs tables. Si vos requêtes comportaient un nombre important de jointures, cela pourrait avoir un impact négatif sur vos performances. Dans ce cas, créer une table supplémentaire qui élimine le besoin de jointures dans vos requêtes serait une bonne optimisation.

Answer 4

Vous n'avez pas mentionné la base de données que vous utilisez mais je peux penser à quelques optimisations rapides possibles. De combien de gigaoctets parle-t-on?

1) Le calcul du maximum (horodatage) peut être coûteux compte tenu du grand nombre de lignes. Vous savez probablement déjà ce que cette valeur est, stockez-la dans une table différente ou un fichier de configuration ou quelque chose. Ce sera probablement votre plus grande optimisation.

2) Ajouter une autre colonne pour marquer les mises à jour récentes. Lorsque vous démarrez votre mise à jour SET recent = false WHERE recent = true, écrivez tous vos enregistrements avec recent = true. Vous pouvez être en mesure de limiter la taille de votre index en lui ajoutant une condition where CREATE INDEX foo_index sur "TB_TABLE" (récent) WHERE recent = true;

3) Assurez-vous que votre serveur db est correctement optimisé. Assurez-vous que vos tampons de clé et de tri sont correctement dimensionnés pour votre jeu de données. La plupart des bases de données open source sont pré-réglées pour le poste de travail d'un développeur, pas pour une charge de travail de production.

4) Réexaminez votre schéma. Etes-vous sûr d'avoir besoin de tous vos enregistrements? Enregistrez-vous toutes les données et pas seulement celles qui ont été modifiées? J'ai fait bon usage de deux horodatages dans cette situation, un horodatage pour le dernier chargement et un horodatage pour le dernier changement.