Question bête: Qu’est-ce qu’une grosse table ?

Il n’y a pas de question bête…

 

Il n’est pas rare d’entendre cette question concernant la taille d’une table (ou d’une base).  “La table est-elle trop grosse ?”

 

Pourquoi se poser la question ?

Taille maximale d’un objet

Il n’existe pas de taille maximale d’une table, en terme de ligne ou d’espace de stockage.

D’après le document des limitations de SQL Server 2016 :

• Une base est composée d’au maximum 32 767 fichiers
• Un fichier peut atteindre 16 Teraoctets.

Une table est donc limitée à 511 Petaoctets (511 millions de Gigaoctets). Concrètement, la seule limite aujourd’hui d’une table est l’espace disque total qui peut être alloué à la machine qui héberge la base…

Considérations de performance.

Nombre de lignes

Les principales opérations effectuées sur une table ( recherche de valeurs, jointure entre deux tables, tri des données, élimination des doublons) dépendent clairement du nombre de lignes de la table.

Par exemple, s’il faut une microseconde pour vérifier que la valeur d’une colonne correspond à une constante (WHERE colonne = ‘ABC’), il faudra une seconde pour vérifier cette valeur sur un million de lignes, et 100 secondes pour cette même opération sur 100 millions de lignes.

Volume de données

Lorsqu’il s’agit de manipuler les données, le temps de traitement dépend aussi clairement du volume de ces données. Balayer 100Go de données sera dans l’absolu 100 fois plus long que balayer 1Go de données.

La volumétrie totale dépend bien entendu de la taille d’une ligne. Une table de 100 millions de petites lignes (quelques colonnes de type entier, par exemple) pourra être bien moins volumineuse qu’une table de 1 millions de grosses lignes (plusieurs colonnes de type Text par exemple).

 

Donc, dans l’absolu, plus la table est “grosse”, en nombre de lignes et/ou en volumétrie totale, plus les traitements qui l’utilisent sont susceptibles de durer longtemps.

Fort heureusement, SQL Server dispose de nombreux moyens pour réduire les données brassées, et donc les temps de traitement. Les deux principaux sont les suivants:

Cache des pages en mémoire

Lorsqu’une page de données est lue depuis le disque, SQL Server va maintenir en mémoire une image de cette aussi longtemps que possible. Les lectures ultérieures de cette même page seront infiniment plus rapides.

Indexes

Le but principal de l’indexe est d’accélérer  l’accès aux données. Sans entrer dans les détails (par exemple disponibles ici), l’indexe permet de réduire considérablement le nombre de pages lues lors de recherche et de jointure impliquant la table. Une table disposant d’indexes pertinents (c-à-d d’indexes qui vont permettre d’accélérer les requêtes les plus couramment exécutées) ne devrait donc pas subir les problèmes évoquées ci-dessus, même lorsque sa volumétrie devient importante.

Et il existe bien entendu un grand nombre de moyens supplémentaires qui permettront de gérer une table de forte volumétrie: partitionnement, purge régulière de données, historisation de données dans des tables d’archive, compression de données, …

 

En conclusion, on peut dire qu’une table qui ne disposerait pas d’indexe pertinent ET qui ne pourrait bénéficier du mécanisme de cache des données (parce qu’elle ne peut être intégralement stockée en mémoire, par exemple)  pourrait poser des problèmes de performance lorsque sa taille devient “importante”. Dès que la volumétrie dépasse les quelques gigaoctets, les problèmes peuvent survenir. Mais cela signifie simplement qu’il est temps de s’intéresser à l’indexation de la table…

 

 

 

 

 

 

Continuez votre lecture sur le blog :

• Oracle et SQL Server: La Fragmentation (Benjamin VESAN) [OracleSQL Server]
• Limiter la PGA totale en 12c (Benjamin VESAN) [Oracle]
• Question bête: Faut-il créer des plans de maintenance avec Reconstruction ET Réorganisation ? (Benjamin VESAN) [SQL Server]
• Alter table rebuild (Benjamin VESAN) [SQL Server]
• MySQL et les tables temporaires internes (Benjamin VESAN) [MySQL]