Capacité maximale de table dans SQL Server 2008

J'ai une application qui insère plus d'un milliard de lignes par an dans une table. Ce tableau contient quelques - unes varcharet des bigintcolonnes et une colonne de blob ainsi.

Les 1 milliard de lignes sont constituées de données d'historique qui sont conservées à des fins de suivi. Je me demandais donc s'il y aurait une limitation de la capacité de la table si je continuais dans cette structure selon cet article MSDN sur la taille maximale de la table .

La taille du fichier de données mentionnée dans ce lien fait-elle référence au groupe de fichiers de données de la table?

sql-server-2008

— ÉCART
source

@marc_s merci d'avoir attrapé ça. n'hésitez pas à nous rejoindre dans The Heap où, entre autres, nous apportons une attention collective à ces derniers

— JNK

Quelle est la taille maximale de chaque ligne?

— Nick Chammas

Réponses:

Il n'y a pas de limite pratique, sauf l'espace disque. J'ai lu le tableau auquel vous avez lié entièrement et l'ai vérifié.

Si vous devez dépasser 16 To, vous avez besoin de plusieurs fichiers (une procédure simple).

— usr
source

Je suppose que cela peut être réalisé en partitionnant la table et en hachant le partitionnement pour utiliser différents groupes de fichiers, si j'ai raison?

— GAP

Ce n'est même pas nécessaire. Ajoutez simplement un nouveau fichier (au groupe de fichiers existant). SQL Server commencera à remplir tous les fichiers uniformément. Si un fichier ne peut plus grandir, il ne fera que développer l'autre fichier.

— usr

une table dans sql server 2008 peut gérer un grand nombre d'enregistrements et, comme @usr l'a mentionné, cela dépend de l'espace disque, mais il est recommandé que si votre table comporte de nombreuses lignes et continue de croître, vous utilisiez la table partitionnée http://technet.microsoft. com / fr-fr / library / dd578580 (v = sql.100) .aspx

Lorsqu'une table de base de données atteint des centaines de gigaoctets ou plus, il peut devenir plus difficile de charger de nouvelles données, de supprimer les anciennes données et de maintenir les index

plus d'informations à ce sujet

http://msdn.microsoft.com/en-us/library/ms190787.aspx

et comment l'implémenter http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/

— AmmarR
source

Vous devez cependant faire très attention au partitionnement. La fonction et la clé doivent être soigneusement examinées, ainsi que le cas d'utilisation. Le champ logique sur lequel partitionner ne doit jamais être utilisé dans aucune des requêtes, ce qui réduirait les performances.

— JNK

Certes, mais des milliards de lignes dans une seule table vont également affecter les performances, il existe également la possibilité de fractionner les données ur dans de nombreuses tables, par exemple une table distincte pour chaque année et si vous souhaitez afficher toutes les données, vous pouvez utiliser une vue mais à moins l'insert et la mise à jour seront plus rapides sur chaque table

— AmmarR

les insertions sur une énorme table ne sont pas nécessairement lentes, cela dépend des clés et des index. Je fais des charges mensuelles d'environ 30 m de lignes dans une table qui a 700 m de lignes existantes, et nous ne faisons aucun partitionnement. J'ai essayé de partitionner mais cela a causé plus de problèmes qu'il n'en a résolu. C'est en fait une question si vous voulez le vérifier.

— JNK

Je pensais à déplacer mes données d'historique vers une table séparée et à créer une vue d'union afin qu'elle puisse être utilisée par l'application en cas de besoin d'historique de requête + dernières données, ce qui représente moins de 25% des requêtes que j'ai dans le système. Cela sera-t-il plus efficace que d'avoir plusieurs fichiers de données ou de partitionner le tableau en fonction de la colonne qui marque les données comme les plus récentes? Des opérations d'E / S qui seront plus efficaces? car mon doute est que ce sera le même du point de vue IO dans les deux solutions.

— GAP

toute approche que vous adoptez a ses meilleures pratiques qui peuvent la rendre bonne ou mauvaise, je veux dire que si vous avez plusieurs tables, votre requête sera compliquée et difficile à maintenir, si vous avez une table et utilisez le partitionnement de table, il y a des considérations de différence comme votre édition sql devrait être une entreprise, etc., avoir de nombreux fichiers de données est recommandé pour de meilleures opérations d'E / S, mais il a également ses meilleures pratiques, pour les performances sql, il n'y a pas de méthode simple ...

— AmmarR

Peut-être qu'une vue partitionnée fonctionnerait.

À partir de l'article Utilisation de la vue partitionnée MSDN :

Les vues partitionnées permettent de diviser les données d'une grande table en tables membres plus petites. Les données sont partitionnées entre les tables membres en fonction de plages de valeurs de données dans l'une des colonnes. Les plages de données pour chaque table membre sont définies dans une contrainte CHECK spécifiée sur la colonne de partitionnement. Une vue qui utilise UNION ALL pour combiner les sélections de toutes les tables membres dans un seul jeu de résultats est ensuite définie. Lorsque les instructions SELECT référençant la vue spécifient une condition de recherche sur la colonne de partition, l'optimiseur de requête utilise les définitions de contrainte CHECK pour déterminer quelle table membre contient les lignes.

Je ne sais pas en quoi cela diffère d'une table partitionnée sur laquelle AmmarR a fourni des informations dans sa réponse.

— Adam Porad
source