Archivage des anciennes données
Nous rencontrons actuellement des problèmes de performances car notre base de données devient trop volumineuse. Il y a des données stockées des 10 dernières années et je ne vois pas pourquoi les données de plus de 2 ans doivent être stockées dans les mêmes tables que les nouvelles données.
Maintenant que je n'ai pas une expérience très approfondie dans l'administration de bases de données, je recherche les meilleures façons d'archiver les anciennes données.
Info
Il y a environ 310'000'000 enregistrements dans la base de données au total.
La base de données a besoin de 250 Go sur le disque dur.
- La version du serveur est SQL Server 2008 avec le niveau de compatibilité SQL Server 2005 (90), mais nous prévoyons de mettre à niveau vers SQL Server 2012 bientôt
J'ai pensé à deux possibilités:
Nouvelle base de données
Créez une base de données similaire à celle du serveur de production et insérez toutes les anciennes données dans la nouvelle base de données.
- Inconvénient: les serveurs liés n'étant pas autorisés dans notre environnement, il serait difficile de joindre les anciennes données si nécessaire
Schéma historique
Créez un nouveau schéma f.e. [hist] avec les mêmes tables que dans la base de données de production. Insérez toutes les anciennes données dans ces nouvelles tables dans le nouveau schéma.
- Avantage: intégration facile, si d'anciennes données étaient nécessaires à l'avenir
- Préférez-vous l'une des solutions par rapport à l'autre?
- Pourquoi?
- Y a-t-il de meilleures possibilités?
- Existe-t-il des outils avec lesquels cette tâche est facilement possible?
- D'autres réflexions?
Merci d'avance
Éditer
Question supplémentaire:
La table d'archivage nouvellement créée aurait-elle également besoin de clés primaires/étrangères?
Ou devraient-ils simplement avoir les colonnes mais sans clés/contraintes?
Je pense que la réponse à bon nombre de vos questions est que cela dépend. Quels problèmes de performances rencontrez-vous? Il semble inhabituel qu'une base de données ait des problèmes de performances simplement en passant à 250 Go.
Peut-être que vos requêtes effectuent des analyses de table sur l'intégralité de la table de faits même lorsqu'une petite partie (par exemple, la dernière année) de la plage de dates est nécessaire? S'il existe une requête particulière qui est la plus importante à optimiser, envisagez de publier votre schéma, votre requête et un plan d'exécution réel dans une autre question pour voir si elle peut être optimisée.
Préférez-vous l'une des solutions par rapport à l'autre?
Je préfère généralement la base de données historique, et je pense que Guy décrit les bonnes raisons pour cela dans sa réponse .
Le principal inconvénient que je vois pour une base de données d'historique (par opposition à un schéma) est que vous ne pouvez plus utiliser de clés étrangères pour votre table d'archives. Cela peut vous convenir, mais c'est quelque chose dont vous devez être conscient.
L'inconvénient que vous avez indiqué pour cette approche n'est pas précis; vous pourrez interroger facilement des bases de données sur le même serveur et l'optimiseur de requêtes gère généralement très bien les requêtes inter-bases de données.
Y a-t-il de meilleures possibilités?
Si vous devez interroger les données d'archives régulièrement, je pourrais envisager partitionner la table par date . Cependant, c'est un grand changement qui peut avoir de nombreuses implications en termes de performances, à la fois positives (par exemple, élimination de partition, chargement de données plus efficace) et négatives (par exemple, recherche de singleton plus lente, plus grand potentiel de biais de thread dans les requêtes parallèles). Je ne prendrais donc pas cette décision à la légère s'il s'agit d'une base de données très utilisée.
La table d'archivage nouvellement créée aurait-elle également besoin de clés primaires/étrangères? Ou devraient-ils simplement avoir les colonnes mais sans clés/contraintes?
Je recommanderais d'avoir au moins la clé primaire et des index uniques afin que vous puissiez obtenir les avantages d'intégrité des données qu'ils fournissent. Par exemple, cela vous évitera d'insérer accidentellement une année de données dans la table d'historique deux fois. Et comme avantage secondaire, il peut améliorer les performances si vous avez besoin d'interroger la table d'historique.
D'autres réflexions?
Étant donné que vous utilisez l'édition Entreprise et que vous prévoyez de mettre à niveau vers SQL 2008+, vous pouvez envisager compression des données pour ce tableau. La compression réduira certainement l'espace disque, mais en fonction des ressources du disque et du processeur de votre serveur, elle peut également améliorer les performances des requêtes pour les lectures en réduisant les E/S du disque et en améliorant l'utilisation de la mémoire (plus de données tiennent dans le cache à la fois).
Je préférerais avoir un schéma historique ou une deuxième base de données historique sur un serveur lié tous les jours. Il économise les coûts de licence est plus facile à gérer et à interroger. Vous pouvez ensuite également utiliser un schéma plus simple et supprimer certains des index en réduisant la taille de la base de données
Mais puisque vous avez l'édition entreprise, vous avez la troisième option qui est de partitionner vos tables qui, une fois mis en place, facilite l'archivage des données et l'interrogation des anciennes données est transparente pour vos utilisateurs et vous n'aura pas besoin de modifier l'application.
D'après mon expérience, une deuxième base de données serait le choix préféré pour deux raisons.
- Vous pouvez restaurer les données à partir d'une sauvegarde historique, puis supprimer les tables et index dont vous n'avez pas besoin.
- Vous pouvez le déplacer vers un autre serveur à des fins de génération de rapports, ce qui présente les avantages de ne pas utiliser les ressources du serveur principal
Vous devrez toujours supprimer toutes les données historiques de la base de données principale, mais cela pourrait être planifié dans.
Ignorer la licence pour l'instant car ce n'est pas là que je passe mon temps.
À mon humble avis, la base de données d'archives est la plus simple à mettre en œuvre et à maintenir. Ce sont des entités distinctes, faiblement couplées. Le contrôle des mouvements de données et des charges/ressources a des limites claires. Peut facilement migrer vers une autre instance ou un autre serveur pour une meilleure gestion des performances et le coût n'est pas un problème majeur. Notez que le plus simple! = Le moins cher ou le moins d'effort. Il a en fait un peu plus de tâches, mais ce sont toutes des tâches simples avec deux exceptions importantes:
- application des contraintes - rien de tel que les contraintes de bases de données croisées dans SQL Server, vous devez donc décider s'il s'agit d'une rupture de contrat.
- les requêtes entre bases de données utilisent des requêtes distribuées qui dépendent toujours d'OLEDB qui est obsolète. Cela signifie que vous pourriez rencontrer des problèmes avec de nouveaux types de données et si vous rencontrez des problèmes de performances, il est peu probable qu'ils soient résolus
Le schéma d'archivage ou simplement la table d'archivage est un peu plus complexe à implémenter mais beaucoup plus facile à utiliser. Tous les objets de la même base de données vous évitent de répliquer et de gérer les contrôles d'accès. Pas de requêtes inter-bases de données facilitant le réglage, la surveillance, le dépannage des performances, etc.
Le partitionnement de table est une excellente solution et offre de nombreux avantages d'une table/schéma d'archive, mais offre une transparence aux utilisateurs/requêtes. Cela dit, il est le plus complexe à mettre en œuvre et nécessite des soins continus qui ne sont pas faciles pour un débutant.
Quelques considérations importantes:
- Les requêtes renvoient-elles régulièrement des données historiques/froides ou les données froides sont-elles rarement consultées?
- Les données historiques sont-elles immuables ou sont-elles mises à jour/supprimées régulièrement?
- 310 m de lignes est "modéré" (en supposant que tout dans un tableau) en fonction de la taille des lignes. Avez-vous des données sur la taille des lignes? Combien de Go est cette ligne de 310 m?
- Quel est le taux de croissance de ce tableau?
- Êtes-vous en mesure de modifier le code d'application et ses requêtes SQL?
Ce sont des considérations importantes car elles peuvent avoir un impact significatif sur la solution que vous choisissez ou peuvent même ne pas autoriser certaines solutions. Par exemple, si vos données historiques sont modifiées/mises à jour régulièrement (plus d'une fois par semaine), l'utilisation d'une base de données distincte signifie que vous devez utiliser le DTC pour ces requêtes ou gérer manuellement la sécurité des transactions (non trivial pour garantir toujours correct). Le coût est nettement supérieur aux données historiques immuables.
En outre, si vous envisagez de mettre à niveau, pensez à 2016 et à la nouvelle fonctionnalité Stretch Database: https://msdn.Microsoft.com/en-us/library/dn935011.aspx
Je préférerais diviser la base de données en une base de données logique distincte pour les raisons suivantes:
1. Besoins en ressources
En le divisant en une base de données distincte, il peut être stocké sur un lecteur différent et surveillé à un rythme différent des données de production principales.
2. Performance
En répartissant les données dans une base de données distincte, la base de données de production principale est réduite en taille, ce qui améliore les performances globales.
. Sauvegardes plus simples
La sauvegarde des données archivées peut ne pas être considérée comme aussi essentielle que les enregistrements "en direct/actuels" dans la base de données SQL principale. Cela peut signifier que les données archivées pourraient être sauvegardées moins souvent. En raison également de la nature séquentielle de la façon dont les données archivées sont enregistrées, il peut être possible de sauvegarder des sections de la base de données archivée une fois puis plus jamais. Par exemple. une fois que les données d'archive sont écrites dans la base de données des archives de modification pour 2014, il n'y aura plus de modification de ces données.
Remarque: Je pense que la réponse à bon nombre de vos questions dépend de votre situation, de la nature des données et des problèmes de performances que vous rencontriez.