Logiciel de bande passante/Base de données des formules de croissance

Question

Y at-il des formules standard de l'industrie ou des règles empiriques pour déterminer:

1. utilisation de la bande passante Application/exigences
2. exigences de croissance de base de données

J'ai récemment commencé à gérer un nouveau projet .NET 3.5/SQL Server et souhaite adopter une approche plus structurée qu'auparavant pour déterminer exactement ce dont mon application a besoin en termes de stockage et de bande passante. Si quelqu'un là-bas a des pointeurs, je l'apprécierais grandement!

Answer 1

Irréverently je vous dirigerais à Parkinson's Law of Data. Cependant, pour chaque table d'une base de données, j'essaie de me faire une idée de la taille moyenne de l'enregistrement (en particulier lorsque je traite des champs de longueur variable comme varchars), puis multipliez cela par le nombre d'enregistrements que vous prévoyez d'ajouter. an. Ensuite, je les ajoute tous ensemble, arrondis au chiffre le plus significatif et doublons le résultat. Cela laisse beaucoup de place pour les frais généraux et la croissance.

round_up_to_one_sig_digit(sum(average_table_row_size 
          * num_rows_in_one_year)) * 2 

Une approche similaire fonctionne avec la capacité du réseau, mais vous courrez dans une particularité de l'être humain et Réseaux extérieurs. Ils ne se connectent pas tous à des intervalles moyens (vous obtenez donc des pics en journée/soirée et des vallées en début de matinée.) Vous ne voulez pas non plus dépasser 80% de votre capacité ou de votre performance réseau.

Answer 2

Je ne suis pas un expert SQL Server, mais en général, pour le dimensionnement de la base de données, la meilleure façon d'aller de l'avant est de comprendre le peu de schéma. Par exemple, des partitions sont-elles présentes dans la base de données? Y a-t-il beaucoup d'index, etc. Maintenant Multipliez le nombre d'enregistrements arrivant à la base de données dans chaque transaction avec la fréquence des transactions par heure. Cela donne le nombre total d'enregistrements arrivant à la base de données par heure. Multipliez ceci par la taille moyenne des lignes, ceci fournit la taille de la base de données sans partition ni espace d'index. Pour calculer le surcoût de partition, vous devez comprendre le type de partition comme la partition de plage ou la partition de hachage, le nombre de partitions qui seront créées par heure ou par jour et ajouter la surcharge de l'espace pour les partitions. Habituellement, ce nombre doit être augmenté de 50% pour estimer la taille de la base de données. En cas de réseau, il existe plusieurs façons de le faire. Je cours éthérée pour capturer le trafic réseau. Si vous capturez du trafic réseau, il devient intéressant - comment la saisonnalité des données est - comme quand les heures de peack sont, quelle est l'utilisation maximale de la bande passante aux heures chargées, etc Alors vous avez besoin d'un bon outil pour faire la prévision - comme qui prendra soin de la saisonnalité dans les données, comprendre la tendance des données et prévoir approximativement ce qui se passera si vous augmentez la charge. Un graphique simple et une courbe d'ajustement de ligne utilisant y = mx + c vous aideront également ici.

Answer 3

Divulgation d'abord: Je travaille pour Quest Software, une entreprise qui fait de la gestion de la performance et de la planification de la capacité.

Il y a beaucoup de produits pour répondre à ces besoins. Quest en fait quelques-uns, comme Spotlight pour SQL Server, Spotlight pour IIS, Capacity Manager pour SQL Server, etc. Il n'y a pas de formule unique ou de règle empirique, car chaque composant du système réagit différemment à la charge, et chaque élément que vous stockez est mis à l'échelle différemment. Par exemple, si vous stockez des données de vente dans un entrepôt de données, vos données de ventes augmenteront linéairement.Il est une formule simple:

(Journées Portes Ouvertes) * (transactions par jour) * (articles par transaction)

Lorsque vous ouvrez votre boutique, les transactions par jour est assez faible, mais comme mot se répand au sujet votre entreprise, les transactions par jour augmente. Si vous commencez à transporter plus d'objets (comme Amazon allant des livres à tout), vos Articles par Transaction peuvent également augmenter - mais pas nécessairement. Au fil du temps, au fur et à mesure que vos besoins de reporting augmenteront, vous implémenterez des tables globales pour inclure des données sur vos clients, vos données démographiques, etc. et cela modifiera également la quantité de données que vous stockez. D'autre part, si vous construisez une application de filtrage Web, la formule tourne autour du nombre d'employés de chaque entreprise. Les gens vont surfer à peu près le même montant au fil du temps, mais la formule est affectée par le fait que vous allez embaucher plus de gens ou licencier des gens.

Si vous définissez une formule pour prédire la croissance de vos données, cette formule n'est pas forcément utile pour prédire, par exemple, les besoins de votre processeur ou vos besoins en bande passante. En conséquence, chaque produit de planification de capacité a ses propres ensembles de formules. Par exemple, Capacity Manager a quelque chose comme une demi-douzaine de formules différentes juste pour prédire la croissance du disque, et cela ne parle même pas des besoins CPU ou de mémoire. Dans un grand magasin, vous constaterez que différentes formules fonctionnent mieux pour différents types de données. Généralement, j'ai trouvé qu'il est plus efficace d'acheter un produit sur étagère qui a toutes ces formules intégrées au lieu de réinventer la roue pour devenir un expert en formules prédictives. (Je sais, je sais, vous vous attendez à ce que je dise cela parce que je travaille pour un vendeur, mais j'ai acheté Capacity Manager en tant que DBA avant de venir travailler pour Quest, heh.)