Gestion d'une énorme quantité de données dans un tableau

Question

Je voudrais poser quelques questions sur la façon de gérer un énorme 100 millions de données dans un seul tableau.
La table exécutera INSERT, SELECT & UPDATE.

J'ai quelques conseils que pour indexer la table et archiver la table dans la table de couple.

Toute autre suggestion pouvant aider à améliorer la performance SQL.

Cas: SQL Server 2008. La plupart du temps, la mise à jour concernant la valeur décimale et l'état du minuscule int. L'instruction INSERT n'utilisera pas BULK INSERT car je suppose que par minute il y a beaucoup d'utilisateurs qui laissent 10000-500000 exécuter l'instruction INSERT et mettre à jour la table.

Answer 1

Vous devriez considérer quel type de colonnes vous avez.

Plus vous avez inclus de colonnes nvarchar/text/etc dans les différents index, plus l'index sera lent.

De même, quel RDBMS allez-vous utiliser? Vous avez des options différentes basées sur SQL Server, Oracle et MySQL ...

Mais la chose essentielle est différemment pour créer l'index droit de vous utiliseriez ...

Une autre chose, vous pouvez utiliser sur BULK INSERT SQL Server pour accélérer les insertions.

Mais demandez loin, j'ai traité des bases de données étant peuplées avec 70 lignes de données de l'usine pr jour;)

EDIT ----- Après plus d'informations est venu

Je vais essayer de prendre peu d'autre approche de l'affaire et de le comparer à la grattage des données.

Il ne fait aucun doute que les INSERT sont plus rapides que UPDATE. Et vous pourriez vouloir faire une table qui agit comme une table "collect". Ce que je veux dire, c'est que ça n'obtient que des inserts tout le temps. Aucune mise à jour, tout est gérer avec des insertions. Ensuite, vous utilisez un déclencheur/événement/planificateur pour gérer ce qui est entré dans cette table et remplir ce que vous avez besoin de table (s) autre (s). De cette façon, vous pourrez appliquer une petite logique métier au "nettoyage" (mise à jour) et conserver les performances sur le serveur DB et ne pas maintenir une connexion pendant que ces opérations sont effectuées.

Bien sûr, ont aussi quelque chose à voir avec ce que les données « finales » sont à utiliser pour ...

\ T

Answer 2

Il est clair que SQL 2008 est capable de 100 millions de disques, mais beaucoup de les détails à regarder cela ne viennent tout simplement pas en jeu à 100 mille. Choisissez une bonne clé primaire. Facteur de remplissage. Autres index (ralentit l'insertion mais sélectionne la vitesse). Concurrence (verrouillage). Si vous pouvez accepter des lectures sales, cela aidera les performances. Cette question a besoin de beaucoup plus de détails. Vous devez publier la conception de table et vos instructions TSQL de sélection, de mise à jour et d'insertion. Je n'ai pas voté votre question mais si vous ne fournissez pas plus de détails, elle sera rejetée.Pour insérer soyez conscient que vous pouvez insérer plusieurs lignes à la fois et est beaucoup plus rapide que plusieurs instructions d'insertion si BULK INSERT n'est pas une option.

INSERT INTO Production.UnitMeasure 
    VALUES (N'FT2', N'Square Feet ', '20080923'), (N'Y', N'Yards', '20080923'), (N'Y3', N'Cubic Yards', '20080923');