SQL Server: le nombre maximal de lignes dans la table
Je développe des logiciels qui stockent beaucoup de données dans l'une de ses tables de base de données (SQL Server version 8, 9 ou 10). Disons qu'environ 100 000 enregistrements sont insérés dans cette table par jour. Cela représente environ 36 millions de disques par an. Craignant de perdre des performances, j'ai décidé de créer chaque jour une nouvelle table (une table avec la date actuelle dans son nom) afin de réduire le nombre d'enregistrements par table.
Pourriez-vous s'il vous plaît me dire si c'était une bonne idée? Existe-t-il une limite d'enregistrement pour les tables de serveur SQL? Ou savez-vous combien d'enregistrements (plus ou moins) peuvent être stockés dans une table avant que les performances ne soient réduites de manière significative?
Il est difficile de donner une réponse générique à cela. Cela dépend vraiment du nombre de facteurs:
- quelle est la taille de votre rangée
- quel type de données que vous stockez (chaînes, blobs, nombres)
- que faites-vous avec vos données (conservez-les simplement sous forme d'archives, interrogez-les régulièrement)
- avez-vous des index sur votre table - combien
- quelles sont les spécifications de votre serveur
etc.
Comme cela a été dit ailleurs ici, 100 000 par jour, et donc par table, est excessif - je suggérerais mensuelle ou hebdomadaire, voire trimestrielle Plus vous aurez de tables, plus le cauchemar de maintenance/requête sera important.
Voici certaines des Spécifications de capacité maximale pour SQL Server 2008 R2
- Taille de la base de données: 524 272 téraoctets
- Bases de données par instance de SQL Server: 32 767
- Groupes de fichiers par base de données: 32 767
- Fichiers par base de données: 32 767
- Taille du fichier (données): 16 téraoctets
- Taille du fichier (journal): 2 téraoctets
- Lignes par table: Limité par la mémoire disponible
- Tableaux par base de données: Limité par le nombre d'objets dans une base de données
J'ai une table de trois colonnes avec un peu plus de 6 milliards de lignes dans SQL Server 2008 R2.
Nous l'interrogeons tous les jours pour créer des graphiques d'analyse système à la minute près pour nos clients. Je n'ai pas remarqué de problèmes de performances de base de données (bien que le fait qu'elle augmente d'environ 1 Go par jour rend la gestion des sauvegardes un peu plus complexe que je ne l'aurais souhaité).
Mise à jour juillet 2016
Nous avons atteint environ 24,5 milliards de lignes avant que les sauvegardes ne deviennent suffisamment importantes pour que nous décidions de tronquer les enregistrements de plus de deux ans (environ 700 Go stockés dans plusieurs sauvegardes, y compris sur des bandes coûteuses). Il convient de noter que la performance n’est pas un facteur de motivation important dans cette décision (c’est-à-dire qu’elle fonctionnait toujours bien).
Pour ceux qui essaient de supprimer 20 milliards de lignes de SQL Server, je recommande fortement cet article . Code pertinent en cas de perte du lien (lisez l'article pour une explication complète):
ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO
BEGIN TRY
BEGIN TRANSACTION
-- Bulk logged
SELECT *
INTO dbo.bigtable_intermediate
FROM dbo.bigtable
WHERE Id % 2 = 0;
-- minimal logged because DDL-Operation
TRUNCATE TABLE dbo.bigtable;
-- Bulk logged because target table is exclusivly locked!
SET IDENTITY_INSERT dbo.bigTable ON;
INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
SET IDENTITY_INSERT dbo.bigtable OFF;
COMMIT
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0
ROLLBACK
END CATCH
ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO
Mise à jour novembre 2016
Si vous envisagez de stocker autant de données dans une seule table, ne le faites pas. Je vous recommande vivement d’envisager le partitionnement de table (manuellement ou avec les fonctions intégrées si vous utilisez Enterprise Edition). Cela permet de supprimer les anciennes données aussi facilement que de tronquer une table une fois par semaine (semaine/mois/etc.). Si vous n'avez pas Enterprise (ce qui n'est pas le cas), vous pouvez simplement écrire un script qui s'exécute une fois par mois, supprime les tables de plus de 2 ans, crée la table du mois prochain et régénère une vue dynamique qui joint toute la partition. tables ensemble pour une interrogation facile. De toute évidence, "une fois par mois" et "plus de 2 ans" doivent être définis par vous en fonction de ce qui a du sens pour votre cas d'utilisation. La suppression directe d'une table contenant des dizaines de milliards de lignes de données a) prendra énormément de temps et b) remplira le journal des transactions des centaines, voire des milliers de fois.
Je ne connais pas de limite de lignes, mais je connais des tables comportant plus de 170 millions de lignes. Vous pouvez l'accélérer à l'aide de tables partitionnées (2005+) ou de vues reliant plusieurs tables.
Je ne connais pas MSSQL de manière spécifique, mais 36 millions de lignes, ce n’est pas une grosse base de données d’entreprise. Travailler avec des bases de données mainframe, 100 000 lignes me semble une table de configuration :-).
Bien que je ne sois pas un grand fan de certains des logiciels Microsoft, nous ne parlons pas ici de Access. Je suppose qu'ils peuvent gérer des tailles de bases de données assez importantes avec leur SGBD d'entreprise.
Je soupçonne que les jours ont été une résolution trop fine pour le diviser, s’il faut le faire.
Nous avons des tables dans SQL Server 2005 et 2008 contenant plus d'un milliard de lignes (30 millions ajoutées par jour). Je ne peux pas imaginer descendre le nid des rats en divisant cela dans une nouvelle table chaque jour.
Beaucoup moins cher d'ajouter l'espace disque approprié (dont vous avez besoin de toute façon) et la RAM.
Cela dépend, mais je dirais qu'il est préférable de tout garder dans une seule table pour des raisons de simplicité.
100 000 lignes par jour ne représentent pas vraiment une quantité énorme. (Selon le matériel de votre serveur). J'ai personnellement vu MSSQL gérer jusqu'à 100 millions de lignes dans une seule table sans aucun problème. Tant que vous gardez vos index en ordre, tout devrait être bien. La clé consiste à disposer de tas de mémoire pour que les index ne soient pas échangés sur le disque.
D'autre part, cela dépend de la façon dont vous utilisez les données, si vous devez créer beaucoup de requêtes et que des données improbables seront nécessaires pendant plusieurs jours (pour que vous n'ayez pas besoin de joindre les tables), elles seront plus rapide de le séparer en plusieurs tables. Ceci est souvent utilisé dans des applications telles que le contrôle de processus industriels où vous pouvez lire la valeur de, par exemple, 50 000 instruments toutes les 10 secondes. Dans ce cas, la rapidité est extrêmement importante, mais la simplicité ne l’est pas.
Nous avons dépassé une fois la clé primaire d'un nombre entier (environ 2,4 milliards de lignes) sur une table. S'il y a une limite de lignes, il est peu probable que vous atteigniez 36 millions de lignes par an.
Vous pouvez remplir la table jusqu'à ce que vous disposiez de suffisamment d'espace disque ..__Pour obtenir de meilleures performances, essayez de migrer vers SQL Server 2005, puis partitionnez la table et placez des parties sur différents disques (si votre configuration RAID peut réellement vous aider). Le partitionnement est possible uniquement dans la version entreprise de SQL Server 2005. Vous pouvez consulter un exemple de partitionnement à ce lien: http://technet.Microsoft.com/en-us/magazine/cc162478.aspx
Vous pouvez également essayer de créer des vues pour la partie de données la plus utilisée. C’est également l’une des solutions.
J'espère que cela a aidé ...
La plus grande table que j'ai rencontrée sur SQL Server 8 sur Windows 2003 était de 799 millions avec 5 colonnes. Mais que ce soit la bonne volonté ou non, cela doit être comparé au SLA et au cas d'utilisation - par exemple charger 50-100,000,000 enregistrements et voir si cela fonctionne toujours.