Bonjour à tous !
Je viens vous présenter un nouveau bloggeur de chez nous... Alors gare aux blagues carambar - il est expert en la matière - et bonne lecture à tous !!!
Au fait, il est fan de DELEGATE anonymes... Surtout quand ça ne sert à rien ;-)
Vous trouverez donc le blog de Matthieu Mezil en cliquant ici... Ou dans le bandeau sur la droite ;-)
vendredi 26 janvier 2007
mercredi 17 janvier 2007
Les colonnes calculées persistantes... Une bonne idée ?
Bonsoir !
Les colonnes calculées sont supportées par SQL Server depuis la version 7... En revanche, SQL Server 2005 permet désormais de rendre ces colonnes persistantes.
En effet, jusque là, les colonnes calculées étaient des colonnes virtuelles, c'est à dire que ces colonnes n'étaient pas écrites sur le disque. Le fait de pouvoir rendre une colonne calculée persistante, c'est le fait de rendre cette colonne physique, et donc de stocker les données inhérentes à cette colonne sur le disque de données.
SQL Server 2000 avait déjà apporté la possibilité de créer des index sur les colonnes calculées, permettant ainsi d'améliorer grandement les performances de certaines applications, en particulier dans le domaine de la consolidation de données. L'exemple type qui reste gravé dans la mémoire collective est la consolidation du chiffre d'affaire mois par mois.
En effet, examinons la table suivante :
CREATE TABLE dbo.Vente
(
VenteID INT IDENTITY (1, 1) NOT NULL
CONSTRAINT PK_Vente PRIMARY KEY CLUSTERED,
DateVente SMALLDATETIME NOT NULL,
MontantVente MONEY NOT NULL
)
Une requête pour consolider ces résultats sur le mois de janvier serait :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
DATEPART(MONTH, DateVente) = 1
Cependant, si la volumétrie est importante, cette requête peut rapidement s'avérer très coûteuse. Si la solution d'indexer la colonne DateVente n'apporte rien dans notre cas, il peut être très utile d'employer une colonne calculée :
ALTER TABLE dbo.Vente
ADD MoisVente AS DATEPART(MONTH, DateVente)
Cette colonne n'utilisant qu'une fonction déterministe, il est possible d'y ajouter un index. A cet effet, un certain nombre d'options doivent être correctement positionnées :
SET ANSI_NULL ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF
Puis, il est possible de créer l'index :
CREATE NONCLUSTERED INDEX IX_MoisVente ON dbo.Vente
(
MoisVente
)
Avant d'effectuer notre requête optimisée :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
MoisVente = 1
Le résultat est assez probant, et peut s'avérer extrêmement intéressant.
La question qui se pose donc est ce que peut bien apporter la persistance d'une telle colonne calculée. En effet, l'argument régulièrement évoqué de l'indexation de la colonne semble bien tomber à l'eau... Quant aux conditions d'utilisation des index sur les colonnes calculées, elles s'avèrent identiques que la valeur soit persistée ou non, à l'exception du déterminisme de la fonction employée...
Pourquoi donc encombrer les disques de données visiblement inutiles ?
La première piste serait donc l'utilisation de fonctions non déterministes, ou dont il serait difficile de savoir si elles le sont, en particulier en ce qui concerne les fonctions CLR.
Mais il faut également se tourner vers des cas plus gourmands en calculs : la persistance prend tout son intérêt lors de calculs complexes nécessitant des ressources CPU importantes, en particulier lorsque la volumétrie de modifications est faible.
Dans ces cas là, le calcul à la volée de notre colonne entraine nécessairement un ralentissement du système, et justifie la persistance de ce calcul.
Soit, voici donc les applications de ces colonnes calculées persistantes...
Les colonnes calculées sont supportées par SQL Server depuis la version 7... En revanche, SQL Server 2005 permet désormais de rendre ces colonnes persistantes.
En effet, jusque là, les colonnes calculées étaient des colonnes virtuelles, c'est à dire que ces colonnes n'étaient pas écrites sur le disque. Le fait de pouvoir rendre une colonne calculée persistante, c'est le fait de rendre cette colonne physique, et donc de stocker les données inhérentes à cette colonne sur le disque de données.
SQL Server 2000 avait déjà apporté la possibilité de créer des index sur les colonnes calculées, permettant ainsi d'améliorer grandement les performances de certaines applications, en particulier dans le domaine de la consolidation de données. L'exemple type qui reste gravé dans la mémoire collective est la consolidation du chiffre d'affaire mois par mois.
En effet, examinons la table suivante :
CREATE TABLE dbo.Vente
(
VenteID INT IDENTITY (1, 1) NOT NULL
CONSTRAINT PK_Vente PRIMARY KEY CLUSTERED,
DateVente SMALLDATETIME NOT NULL,
MontantVente MONEY NOT NULL
)
Une requête pour consolider ces résultats sur le mois de janvier serait :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
DATEPART(MONTH, DateVente) = 1
Cependant, si la volumétrie est importante, cette requête peut rapidement s'avérer très coûteuse. Si la solution d'indexer la colonne DateVente n'apporte rien dans notre cas, il peut être très utile d'employer une colonne calculée :
ALTER TABLE dbo.Vente
ADD MoisVente AS DATEPART(MONTH, DateVente)
Cette colonne n'utilisant qu'une fonction déterministe, il est possible d'y ajouter un index. A cet effet, un certain nombre d'options doivent être correctement positionnées :
SET ANSI_NULL ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF
Puis, il est possible de créer l'index :
CREATE NONCLUSTERED INDEX IX_MoisVente ON dbo.Vente
(
MoisVente
)
Avant d'effectuer notre requête optimisée :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
MoisVente = 1
Le résultat est assez probant, et peut s'avérer extrêmement intéressant.
La question qui se pose donc est ce que peut bien apporter la persistance d'une telle colonne calculée. En effet, l'argument régulièrement évoqué de l'indexation de la colonne semble bien tomber à l'eau... Quant aux conditions d'utilisation des index sur les colonnes calculées, elles s'avèrent identiques que la valeur soit persistée ou non, à l'exception du déterminisme de la fonction employée...
Pourquoi donc encombrer les disques de données visiblement inutiles ?
La première piste serait donc l'utilisation de fonctions non déterministes, ou dont il serait difficile de savoir si elles le sont, en particulier en ce qui concerne les fonctions CLR.
Mais il faut également se tourner vers des cas plus gourmands en calculs : la persistance prend tout son intérêt lors de calculs complexes nécessitant des ressources CPU importantes, en particulier lorsque la volumétrie de modifications est faible.
Dans ces cas là, le calcul à la volée de notre colonne entraine nécessairement un ralentissement du système, et justifie la persistance de ce calcul.
Soit, voici donc les applications de ces colonnes calculées persistantes...
Visiteurs du jour...
Bonjour à tous !
Suite à un grand nombre de témoignages de mécontentement, je vais effectuer des essais de couleurs sur le blog... Alors, titulaires d'un compte Google - oui, je sais, il faut un compte Google pour envoyer un commentaire, et je dois dire qu'il faut un compte Developpeur.org sur Developpeur.org, mais ça n'est qu'un détail - merci de me donner votre avis !
Histoire de savoir à l'avenir si mon site abandonnera son fond noir - pour l'instant, 4 avis pour le noir, 5 contre... - et arborera de nouvelles couleurs !
Pour ceux qui douteraient de mon intention de venir rejoindre leur gentille communauté, vous trouverez ici et là des explications concernant mes choix...
Suite à un grand nombre de témoignages de mécontentement, je vais effectuer des essais de couleurs sur le blog... Alors, titulaires d'un compte Google - oui, je sais, il faut un compte Google pour envoyer un commentaire, et je dois dire qu'il faut un compte Developpeur.org sur Developpeur.org, mais ça n'est qu'un détail - merci de me donner votre avis !
Histoire de savoir à l'avenir si mon site abandonnera son fond noir - pour l'instant, 4 avis pour le noir, 5 contre... - et arborera de nouvelles couleurs !
Pour ceux qui douteraient de mon intention de venir rejoindre leur gentille communauté, vous trouverez ici et là des explications concernant mes choix...
vendredi 12 janvier 2007
Comment choisir le nombre de grappes de disques...
Bonjour à tous !
Voici quelques conseils indémodables sur la séparation des fichiers de bases de données sur des grappes de disques - idéalement sur des contrôleurs - séparés...
Nous noterons tout d'abord que les différentes configurations adaptées aux bases de données isolent systématiquement les journaux de transactions sur un jeu de disques séparé, et cela pour deux raisons :
- Concernant la sécurité des données, la perte totale des disques de données peut être récupérée à l’aide des journaux de transactions, et inversement ;
- L’isolation des journaux de transactions assure de meilleures performances globales du système en limitant les files d’attentes sur les différents disques.
Ensuite, pour des raisons de performance générale de la base de données, il est primordial d'installer la base TempDB sur un jeu de disques isolé... En effet, toutes les bases de données du SGBD utilisent cette base pour créer des objets temporaires aux cours des différentes requêtes. Ceci est particulièrement important dans SQL Server 2005 !
Toujours pour des raisons d'optimisation des performances, il est souhaitable d'isoler les index non ordonnés (NONCLUSTERED) sur un jeu de disque séparé et ainsi accroitre les performances de recherche par ces index. En revanche, séparer les index CLUSTERED est totalement inutile, car cela reviendrait à déplacer la totalité des données...
Il est également recommandé de déplacer les données volumineuses - souvent baptisées BLOB pour Binary Large OBjects - sur un jeu de disques séparés afin de limiter le fractionnement des données... Pour cela, le partitionnement horizontal des données est nécessaire.
De plus en plus de bases de données présentent des volumes de données extrêmement important, ce qui peut grever grandement les performances. La solution du partitionnement vertical assure que les données soient séparées sur des espaces de données différents... Il est souvent intéressant d'isoler ces filegroups sur des jeux de disques séparés.
Enfin, il est important de rappeler que :
- Les disques systèmes ne sont pas des disques de données, et doivent être réservés à l'usage du système d'exploitation et des exécutables,
- Les disques servant de stockage de fichiers de backup lorsque cela s'applique doivent également être des disques dédiés pour éviter toute dégradation des performances de la base de données,
- Et que pour mettre en place ce type d'architecture, rien ne vaut le RAID... Alors bonne lecture !
Voici quelques conseils indémodables sur la séparation des fichiers de bases de données sur des grappes de disques - idéalement sur des contrôleurs - séparés...
Nous noterons tout d'abord que les différentes configurations adaptées aux bases de données isolent systématiquement les journaux de transactions sur un jeu de disques séparé, et cela pour deux raisons :
- Concernant la sécurité des données, la perte totale des disques de données peut être récupérée à l’aide des journaux de transactions, et inversement ;
- L’isolation des journaux de transactions assure de meilleures performances globales du système en limitant les files d’attentes sur les différents disques.
Ensuite, pour des raisons de performance générale de la base de données, il est primordial d'installer la base TempDB sur un jeu de disques isolé... En effet, toutes les bases de données du SGBD utilisent cette base pour créer des objets temporaires aux cours des différentes requêtes. Ceci est particulièrement important dans SQL Server 2005 !
Toujours pour des raisons d'optimisation des performances, il est souhaitable d'isoler les index non ordonnés (NONCLUSTERED) sur un jeu de disque séparé et ainsi accroitre les performances de recherche par ces index. En revanche, séparer les index CLUSTERED est totalement inutile, car cela reviendrait à déplacer la totalité des données...
Il est également recommandé de déplacer les données volumineuses - souvent baptisées BLOB pour Binary Large OBjects - sur un jeu de disques séparés afin de limiter le fractionnement des données... Pour cela, le partitionnement horizontal des données est nécessaire.
De plus en plus de bases de données présentent des volumes de données extrêmement important, ce qui peut grever grandement les performances. La solution du partitionnement vertical assure que les données soient séparées sur des espaces de données différents... Il est souvent intéressant d'isoler ces filegroups sur des jeux de disques séparés.
Enfin, il est important de rappeler que :
- Les disques systèmes ne sont pas des disques de données, et doivent être réservés à l'usage du système d'exploitation et des exécutables,
- Les disques servant de stockage de fichiers de backup lorsque cela s'applique doivent également être des disques dédiés pour éviter toute dégradation des performances de la base de données,
- Et que pour mettre en place ce type d'architecture, rien ne vaut le RAID... Alors bonne lecture !
Le RAID : les conclusions...
Il est donc temps pour moi d’en venir aux conclusions…
Si les différents niveaux de RAID sont si nombreux, la raison en est bien simple : chaque système possède des points forts et des points faibles à mettre en avant en fonction des besoins de chacun.
Cependant, il faut bien reconnaitre qu’un compromis est souvent nécessaire.
En la matière, le RAID 5 s'impose souvent comme le maître incontesté du rapport performance/coût... En revanche, les difficultés de sizing des bandes grevent les performances en écriture dans la majorité des systèmes de bases de données, entrainant de fait son rejet par les DBA puristes...
Qui eux, sans aucun doute feront le choix du RAID 10, certes plus coûteux, mais assurant des performances constantes quelques soient les modes d'accès. Un avantage indéniable, quand on peut aisément lui associer une meilleure vitesse de reconstruction des données, une dégradation des performances inférieure en cas de panne, une meilleure tolérance de panne... Et une installation plus simple à réaliser !
Enfin, il ne faut pas négliger les disques destinés au système d'exploitation, qui mérite sans aucun doute de bénéficier d'un bon RAID 1, peu coûteux, et répondant idéalement aux prérequis de disponibilité du système.
Alors, à vos marques... Configurez !
Si les différents niveaux de RAID sont si nombreux, la raison en est bien simple : chaque système possède des points forts et des points faibles à mettre en avant en fonction des besoins de chacun.
Cependant, il faut bien reconnaitre qu’un compromis est souvent nécessaire.
En la matière, le RAID 5 s'impose souvent comme le maître incontesté du rapport performance/coût... En revanche, les difficultés de sizing des bandes grevent les performances en écriture dans la majorité des systèmes de bases de données, entrainant de fait son rejet par les DBA puristes...
Qui eux, sans aucun doute feront le choix du RAID 10, certes plus coûteux, mais assurant des performances constantes quelques soient les modes d'accès. Un avantage indéniable, quand on peut aisément lui associer une meilleure vitesse de reconstruction des données, une dégradation des performances inférieure en cas de panne, une meilleure tolérance de panne... Et une installation plus simple à réaliser !
Enfin, il ne faut pas négliger les disques destinés au système d'exploitation, qui mérite sans aucun doute de bénéficier d'un bon RAID 1, peu coûteux, et répondant idéalement aux prérequis de disponibilité du système.
Alors, à vos marques... Configurez !
RAID 103, 105 et les autres...
Actuellement, bon nombre de sociétés sont à la recherche d’une solution permettant d’améliorer les performances en écriture du RAID 10, son point faible. Ces solutions intègrent également des niveaux de sécurité extrêmement importants.
Des solutions complexes du type RAID 103 et RAID 105 sont actuellement à l’étude. Si leur mise en œuvre parait extrêmement complexe, les performances obtenues n’en demeurent pas moins très prometteuses.
Aucune carte contrôleur disponible sur le marché ne permet actuellement de gérer de telles configurations physiquement qui sont uniquement du domaine de la recherche pour l’instant… A suivre ;-)
Des solutions complexes du type RAID 103 et RAID 105 sont actuellement à l’étude. Si leur mise en œuvre parait extrêmement complexe, les performances obtenues n’en demeurent pas moins très prometteuses.
Aucune carte contrôleur disponible sur le marché ne permet actuellement de gérer de telles configurations physiquement qui sont uniquement du domaine de la recherche pour l’instant… A suivre ;-)
RAID 15 et 51...
L’intérêt majeur de mutualiser ces deux types de RAID réside dans la robustesse de ce modèle en termes de sécurité des données ; la tolérance de panne ainsi obtenue s’avère impressionnante. On peut ainsi perdre la plupart des disques sur un RAID 15 (7/9 disques par exemple). C’est le meilleur niveau de RAID en termes de tolérance de panne et en termes de disponibilité. Mais c’est un RAID très coûteux, en raison du coût important des cartes contrôleurs qui lui sont adaptées d’une part, et en raison d’une capacité de stockage très fortement réduite – présentant des pertes de plus de 70% de l’espace disque total dans certaines de configurations – d’autre part. Les performances de ces types de RAID ne sont jamais exceptionnelles, mais ne s’avèrent jamais catastrophiques pour autant. Il s’agit d’un excellent compromis pour des cas où la sécurité est primordiale.
Toutefois, la plupart du temps, les RAID 15 et 51 peuvent avantageusement être remplacés par du RAID 10. En effet, un système nécessitant un tel niveau de sécurité pose toujours la question de la fiabilité de ses équipements.
Toutefois, la plupart du temps, les RAID 15 et 51 peuvent avantageusement être remplacés par du RAID 10. En effet, un système nécessitant un tel niveau de sécurité pose toujours la question de la fiabilité de ses équipements.
Inscription à :
Articles (Atom)
