Je dois développer une application qui fonctionnera à la façon de l'annuaire
de yahoo. En gros une hierarchie de catégorie auxquels sont associés un
ensemble de lien. Dés le démarrage nous avons environ 200 catégories et près
de 3 millions de liens.
Avec une relation classique (Categorie 1-n Liens) l'application est à la
ramasse dés que je fais un SELECT (j'ai mis un index sur l'id de la
catégorie pour optimiser un peu) pour obtenir tous les liens d'une catégorie
donnée (vu le nombre de data et mon serveur de prod c'est normal). J'ai
pensé découper ma base en autant de fichier XML qu'il y a de catégorie (vu
que le système ne sera jamais mis à jour c'est pas dérangeant) mais
j'aimerai tout de même savoir comme je pourrais structurer ça sous SQL
Server pour que ça fonctionne correctement. A noté que le nombre d'accès
n'est pas énorme, au pire on compte 10000 connexions sur la journée mais il
faut absolument que ça réponde vite...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Yanos El Guerilleros
Salut,
Voir le site de F. BROUARD sur les arbres intervallaires : http://sqlpro.developpez.com/cours/arborescence/
Pas forcément simple à aborder au départ, mais maintenant j'ai une représentation hiérarchique jusqu'a 17 niveaux, et ca fonctionne nickel en un select j'obtiens tout ce que je veux.
A++
Yanos
Jérôme Quintard a écrit :
Salut à tous,
Je dois développer une application qui fonctionnera à la façon de l'annuaire de yahoo. En gros une hierarchie de catégorie auxquels sont associés un ensemble de lien. Dés le démarrage nous avons environ 200 catégories et près de 3 millions de liens.
Avec une relation classique (Categorie 1-n Liens) l'application est à la ramasse dés que je fais un SELECT (j'ai mis un index sur l'id de la catégorie pour optimiser un peu) pour obtenir tous les liens d'une catégorie donnée (vu le nombre de data et mon serveur de prod c'est normal). J'ai pensé découper ma base en autant de fichier XML qu'il y a de catégorie (vu que le système ne sera jamais mis à jour c'est pas dérangeant) mais j'aimerai tout de même savoir comme je pourrais structurer ça sous SQL Server pour que ça fonctionne correctement. A noté que le nombre d'accès n'est pas énorme, au pire on compte 10000 connexions sur la journée mais il faut absolument que ça réponde vite...
Merci pour vos conseils...
Jérôme
Salut,
Voir le site de F. BROUARD sur les arbres intervallaires :
http://sqlpro.developpez.com/cours/arborescence/
Pas forcément simple à aborder au départ, mais maintenant j'ai une
représentation hiérarchique jusqu'a 17 niveaux, et ca fonctionne nickel
en un select j'obtiens tout ce que je veux.
A++
Yanos
Jérôme Quintard a écrit :
Salut à tous,
Je dois développer une application qui fonctionnera à la façon de l'annuaire
de yahoo. En gros une hierarchie de catégorie auxquels sont associés un
ensemble de lien. Dés le démarrage nous avons environ 200 catégories et près
de 3 millions de liens.
Avec une relation classique (Categorie 1-n Liens) l'application est à la
ramasse dés que je fais un SELECT (j'ai mis un index sur l'id de la
catégorie pour optimiser un peu) pour obtenir tous les liens d'une catégorie
donnée (vu le nombre de data et mon serveur de prod c'est normal). J'ai
pensé découper ma base en autant de fichier XML qu'il y a de catégorie (vu
que le système ne sera jamais mis à jour c'est pas dérangeant) mais
j'aimerai tout de même savoir comme je pourrais structurer ça sous SQL
Server pour que ça fonctionne correctement. A noté que le nombre d'accès
n'est pas énorme, au pire on compte 10000 connexions sur la journée mais il
faut absolument que ça réponde vite...
Voir le site de F. BROUARD sur les arbres intervallaires : http://sqlpro.developpez.com/cours/arborescence/
Pas forcément simple à aborder au départ, mais maintenant j'ai une représentation hiérarchique jusqu'a 17 niveaux, et ca fonctionne nickel en un select j'obtiens tout ce que je veux.
A++
Yanos
Jérôme Quintard a écrit :
Salut à tous,
Je dois développer une application qui fonctionnera à la façon de l'annuaire de yahoo. En gros une hierarchie de catégorie auxquels sont associés un ensemble de lien. Dés le démarrage nous avons environ 200 catégories et près de 3 millions de liens.
Avec une relation classique (Categorie 1-n Liens) l'application est à la ramasse dés que je fais un SELECT (j'ai mis un index sur l'id de la catégorie pour optimiser un peu) pour obtenir tous les liens d'une catégorie donnée (vu le nombre de data et mon serveur de prod c'est normal). J'ai pensé découper ma base en autant de fichier XML qu'il y a de catégorie (vu que le système ne sera jamais mis à jour c'est pas dérangeant) mais j'aimerai tout de même savoir comme je pourrais structurer ça sous SQL Server pour que ça fonctionne correctement. A noté que le nombre d'accès n'est pas énorme, au pire on compte 10000 connexions sur la journée mais il faut absolument que ça réponde vite...
Merci pour vos conseils...
Jérôme
llopht
Merci Yanos,
Je ne connaissais pas le principe des arbres intervallaires c'est génial et ça va m'arranger pour un autre projet mais dans le cas présent c'est pas les catégories qui me gène car il y a seulement un seul niveau hierarchique (et environ 200 catégories). Le problème se situe uniquement au niveau des liens et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant de la fin d'année). Le requête à un coùt élevé du fait du grand nombre d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter la table afin de rendre un SELECT presque instantanné...
Tiens par exemple, comment fait un moteur de recherche pour répondre si rapidement alors que ça base doit être consituté de milliards d'informations ??
Jérôme
Merci Yanos,
Je ne connaissais pas le principe des arbres intervallaires c'est génial et
ça va m'arranger pour un autre projet mais dans le cas présent c'est pas les
catégories qui me gène car il y a seulement un seul niveau hierarchique (et
environ 200 catégories). Le problème se situe uniquement au niveau des liens
et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant
de la fin d'année). Le requête à un coùt élevé du fait du grand nombre
d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter
la table afin de rendre un SELECT presque instantanné...
Tiens par exemple, comment fait un moteur de recherche pour répondre si
rapidement alors que ça base doit être consituté de milliards d'informations
??
Je ne connaissais pas le principe des arbres intervallaires c'est génial et ça va m'arranger pour un autre projet mais dans le cas présent c'est pas les catégories qui me gène car il y a seulement un seul niveau hierarchique (et environ 200 catégories). Le problème se situe uniquement au niveau des liens et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant de la fin d'année). Le requête à un coùt élevé du fait du grand nombre d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter la table afin de rendre un SELECT presque instantanné...
Tiens par exemple, comment fait un moteur de recherche pour répondre si rapidement alors que ça base doit être consituté de milliards d'informations ??
Jérôme
Pierre Goiffon
llopht wrote:
Le problème se situe uniquement au niveau des liens et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant de la fin d'année). Le requête à un coùt élevé du fait du grand nombre d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter la table afin de rendre un SELECT presque instantanné...
Est-ce que vos index sont bien positionnés ? En quoi consiste votre requête ? Est un = ou un LIKE ?
llopht wrote:
Le problème se situe uniquement au niveau des liens
et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant
de la fin d'année). Le requête à un coùt élevé du fait du grand nombre
d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter
la table afin de rendre un SELECT presque instantanné...
Est-ce que vos index sont bien positionnés ? En quoi consiste votre
requête ? Est un = ou un LIKE ?
Le problème se situe uniquement au niveau des liens et leur grand nombre (>3 millions aujourd'hui et qui risque de doubler avant de la fin d'année). Le requête à un coùt élevé du fait du grand nombre d'enregistrements donc ce qu'il me faudrait c'est un système pour segmenter la table afin de rendre un SELECT presque instantanné...
Est-ce que vos index sont bien positionnés ? En quoi consiste votre requête ? Est un = ou un LIKE ?
Jérôme Quintard
Hello pierre !
Est-ce que vos index sont bien positionnés ?
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
Un select avec un Jérôme
Hello pierre !
Est-ce que vos index sont bien positionnés ?
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
Un select avec un Jérôme
Jérôme Quintard
Aujourd'hui j'ai trois choix :
Faire une seule table avec les catégories et les liens. Avantage : recherche rapide Inconvénient : l'insertion est plus longue (vu qu'il y a ques millions de liens+catégories dans la table)
Faire une table avec les catégories gérés par arbres intervallaires et une table lien séparée. Avantage : si on rajoute des liens l'insertion est beaucoup plus rapide Inconvénient : la recherche de liens associés à un ensemble de catégorie est plus longue
Faire une table catégorie (en auto-jointure) et une table lien Avantage : recherche rapide Inconvénient : tout ce qu'apporte les arbres intervallaires
Que vaut il mieux ??
Jérôme
Aujourd'hui j'ai trois choix :
Faire une seule table avec les catégories et les liens.
Avantage : recherche rapide
Inconvénient : l'insertion est plus longue (vu qu'il y a ques millions de
liens+catégories dans la table)
Faire une table avec les catégories gérés par arbres intervallaires et une
table lien séparée.
Avantage : si on rajoute des liens l'insertion est beaucoup plus rapide
Inconvénient : la recherche de liens associés à un ensemble de catégorie est
plus longue
Faire une table catégorie (en auto-jointure) et une table lien
Avantage : recherche rapide
Inconvénient : tout ce qu'apporte les arbres intervallaires
Faire une seule table avec les catégories et les liens. Avantage : recherche rapide Inconvénient : l'insertion est plus longue (vu qu'il y a ques millions de liens+catégories dans la table)
Faire une table avec les catégories gérés par arbres intervallaires et une table lien séparée. Avantage : si on rajoute des liens l'insertion est beaucoup plus rapide Inconvénient : la recherche de liens associés à un ensemble de catégorie est plus longue
Faire une table catégorie (en auto-jointure) et une table lien Avantage : recherche rapide Inconvénient : tout ce qu'apporte les arbres intervallaires
Que vaut il mieux ??
Jérôme
Jérôme Quintard
Sinon je repense à une chose, est il possible de lier l'Id d'un lien à une catégorie (bien sûr sans avoir le soucis de la mise à jour des bordures).
Jérôme
Sinon je repense à une chose, est il possible de lier l'Id d'un lien à une
catégorie (bien sûr sans avoir le soucis de la mise à jour des bordures).
Sinon je repense à une chose, est il possible de lier l'Id d'un lien à une catégorie (bien sûr sans avoir le soucis de la mise à jour des bordures).
Jérôme
Pierre Goiffon
Jérôme Quintard wrote:
Est-ce que vos index sont bien positionnés ?
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
Un select avec un
(je n'ai pas le début du thread, ceci explique mes questions) Est-ce que la reuète utilise bien les index comme il faut ? Votre WHERE porte-t-il uniquement sur les colonnes indexées ? Que donne un affichage du coût de la requète dans l'analyseur ? etc etc
(3 millions de lignes, ça commence à faire costaud, mais ça ne devrait pas être plus long que ça si tout est bien optimisé)
Jérôme Quintard wrote:
Est-ce que vos index sont bien positionnés ?
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
Un select avec un
(je n'ai pas le début du thread, ceci explique mes questions)
Est-ce que la reuète utilise bien les index comme il faut ? Votre WHERE
porte-t-il uniquement sur les colonnes indexées ? Que donne un affichage
du coût de la requète dans l'analyseur ? etc etc
(3 millions de lignes, ça commence à faire costaud, mais ça ne devrait
pas être plus long que ça si tout est bien optimisé)
oui ils sont positionnés sur l'ID de la catégorie et la clé primaire..
En quoi consiste votre requête ? Est un = ou un LIKE ?
Un select avec un
(je n'ai pas le début du thread, ceci explique mes questions) Est-ce que la reuète utilise bien les index comme il faut ? Votre WHERE porte-t-il uniquement sur les colonnes indexées ? Que donne un affichage du coût de la requète dans l'analyseur ? etc etc
(3 millions de lignes, ça commence à faire costaud, mais ça ne devrait pas être plus long que ça si tout est bien optimisé)
