77
4.2 Partitionnement
SELECT 'babaluga', CAST('plein de choses à dire' as varbinary(max))
SELECT
nom,
CAST(document as varchar(max)) as document,
document.PathName()
FROM dbo.document
Volume de données
Attention au nombre de fichiers stockés dans les répertoires FILESTREAM. À partir de quelques
centaines de milliers de fichiers, des lenteurs sérieuses peuvent se faire sentir. La source du
problème peut être le scan du répertoire à chaque ajout de fichier, pour générer un nom en
format 8.3 lié. Vous pouvez désactiver ce comportement dans NTFS à l’aide de l’exécutable
fsutil :
fsutil behavior set disable8dot3 1
Vous devez redémarrer la machine pour que ceci soit pris en compte.
4.2 PARTITIONNEMENT
Mathématiquement, l’augmentation de la taille d’une base de données entraîne une
diminution de ses performances en lecture et en écriture. Grâce à la grande qualité
des techniques d’optimisation mises en œuvre dans les SGBDR modernes, et à
condition que votre modèle de données soit intelligemment construit, cette
augmentation de temps de réponse n’est en rien linéaire. SQL Server peut retrouver
avec une grande vélocité quelques lignes dans une table qui en compte des millions.
Toutefois, il n’y a pas de miracle : augmentation de taille signifie multiplication des
pages de données et d’index, donc plus de lectures et plus de temps pour parcourir les
objets.
Pour pallier cette inflation de taille, vous pouvez partitionner vos tables. Le partitionnement consiste à séparer physiquement des structures, soit pour en paralléliser le traitement, soit pour retirer des lectures une partie des données moins souvent
sollicitée. Le partitionnement peut soit porter sur des lignes (partitionnement horizontal), soit sur des colonnes (partitionnement vertical).
Le partitionnement horizontal est utile dans le cas de tables comportant un
attribut temporel, par exemple une table de journalisation, de mouvements comptables, de factures, d’actes ou d’opérations diverses. Les écritures portent très souvent sur des dates récentes, et la grande majorité des lectures concerne une période
limitée, par exemple les quelques dernières années. En SQL Server 2000, nous traitions ce problème en créant des tables supplémentaires qui dupliquaient la structure
de la table originale, par exemple à l’aide d’un ordre SELECT INTO, qui permet de
créer une table et d’y insérer le résultat d’un SELECT à la volée. Il est tout à fait possible de continuer à utiliser cette technique dans SQL Server 2005/2008. Voici un
4.2 Partitionnement
SELECT 'babaluga', CAST('plein de choses à dire' as varbinary(max))
SELECT
nom,
CAST(document as varchar(max)) as document,
document.PathName()
FROM dbo.document
Volume de données
Attention au nombre de fichiers stockés dans les répertoires FILESTREAM. À partir de quelques
centaines de milliers de fichiers, des lenteurs sérieuses peuvent se faire sentir. La source du
problème peut être le scan du répertoire à chaque ajout de fichier, pour générer un nom en
format 8.3 lié. Vous pouvez désactiver ce comportement dans NTFS à l’aide de l’exécutable
fsutil :
fsutil behavior set disable8dot3 1
Vous devez redémarrer la machine pour que ceci soit pris en compte.
4.2 PARTITIONNEMENT
Mathématiquement, l’augmentation de la taille d’une base de données entraîne une
diminution de ses performances en lecture et en écriture. Grâce à la grande qualité
des techniques d’optimisation mises en œuvre dans les SGBDR modernes, et à
condition que votre modèle de données soit intelligemment construit, cette
augmentation de temps de réponse n’est en rien linéaire. SQL Server peut retrouver
avec une grande vélocité quelques lignes dans une table qui en compte des millions.
Toutefois, il n’y a pas de miracle : augmentation de taille signifie multiplication des
pages de données et d’index, donc plus de lectures et plus de temps pour parcourir les
objets.
Pour pallier cette inflation de taille, vous pouvez partitionner vos tables. Le partitionnement consiste à séparer physiquement des structures, soit pour en paralléliser le traitement, soit pour retirer des lectures une partie des données moins souvent
sollicitée. Le partitionnement peut soit porter sur des lignes (partitionnement horizontal), soit sur des colonnes (partitionnement vertical).
Le partitionnement horizontal est utile dans le cas de tables comportant un
attribut temporel, par exemple une table de journalisation, de mouvements comptables, de factures, d’actes ou d’opérations diverses. Les écritures portent très souvent sur des dates récentes, et la grande majorité des lectures concerne une période
limitée, par exemple les quelques dernières années. En SQL Server 2000, nous traitions ce problème en créant des tables supplémentaires qui dupliquaient la structure
de la table originale, par exemple à l’aide d’un ordre SELECT INTO, qui permet de
créer une table et d’y insérer le résultat d’un SELECT à la volée. Il est tout à fait possible de continuer à utiliser cette technique dans SQL Server 2005/2008. Voici un