Suggestion pour la conception d'une grande base de données SQL Server

Nous créons une base de données dans MSSQL 2008 R2 Standard où nous allons stocker un grand nombre d'enregistrements. Nous estimons plus de 200 millions d'enregistrements dans un seul tableau chaque année et nous insérons principalement avec très peu de MISES À JOUR ou SUPPRESSION sur les données. C'est un système d'archivage de données où nous insérons quotidiennement des enregistrements historiques. Nous générerons différents types de rapports sur ce dossier historique à la demande des utilisateurs, nous avons donc certaines préoccupations et nous avons besoin de contributions et de conseils techniques.

• Quelle est la meilleure façon de gérer ce type de tables d'archives et de base de données?

Voici mon avis:

1. Si vous rencontrez très peu de mises à jour / suppressions, vous pouvez augmenter le facteur de remplissage de page à 95%. Cela permettra d'économiser de l'espace et de lire. Faites quelques tests cependant.
2. Partitionnez le tableau en fonction d'une large catégorie comme l'année.
3. Placez ces partitions sur différents groupes de fichiers.

200 millions de lignes par an ne sont pas particulièrement grandes (sauf si les lignes sont inhabituellement grandes). Vous devez faire attention aux principes de conception de base de données (normalisation) et utiliser des fonctionnalités standard comme l'indexation et le partitionnement. De toute évidence, le bon matériel est également important.

Il n'y a pas assez d'informations ici pour donner des conseils spécifiques. Envisagez d'embaucher quelqu'un si vous sentez que vous avez besoin d'aide pour la conception détaillée et la mise en œuvre.

• Assurez-vous que votre conception permet à vos inserts d'être toujours au bout de la table. Indice Clustered Index.

• Il n'y a que très peu d'index non cluster prenant en charge les rapports que vous devez faire pour les maintenir au minimum. Ces rapports sont-ils prégénérés? Si oui, considérez cette question: est-ce correct si le rapport prend 2 heures pour être généré? (sans index) ou 1 min (avec index). Peut-être qu'il est acceptable de laisser le rapport prendre 2 heures pour avoir un index de moins? ou peut être pas? Si le rapport n'est pas bien pré-généré, c'est une autre question, car les utilisateurs n'aiment pas attendre et vous devrez peut-être implémenter plus d'index pour prendre en charge vos rapports.

• D'après la façon dont vous décrivez cette base de données, il semble que vous vous attendiez à beaucoup de lignes et les données s'ajouteront et augmenteront beaucoup. Avez-vous pensé à sauvegarder ce système? Je meen la plupart des données seront les mêmes et en ajoutant juste de nouvelles? Je ne connais pas les exigences commerciales de ce système, mais il me semble que dans un an ou deux, cela pourrait être une base de données de taille considérable et vous pourriez avoir du mal à effectuer de nombreuses sauvegardes complètes. Envisagez de faire une sauvegarde complète avec des journaux de transactions périodiques (hebdomadaires?) Et différentiels (quotidiens?) Et de transactions (toutes les heures?). Bien sûr, comme je l'ai dit, je ne connais pas les exigences de l'entreprise, peut-être n'avez-vous pas besoin de toutes les sauvegardes tout le temps? La taille peut être un problème dans les systèmes d'archivage.