Version imprimable
bonjour,
je viens de calculer la volumétrie... et un de mes tables de relation (id1, id2, value) va contenir 690 milliards de lignes. Et je vais faire des jointures avec une table qui contient juste moitié moins de lignes... Est-ce que SQL Serveur va tenir le coup ou vais-je le faire exploser ?
Cela parait beaucoup... Mais avez-vous le choix ??? Le nombre de ligne n'est pas ce qu'il y a de plus significatif. C'est le volume qui importe...
Ce qui sera important c'est la structure de la table et la construction des index. Si la table est chrono ordonnée ou en série monotone, alors mettre un index cluster (soit avec un IDENTITY sur BIGINT, soit sur DATETIME).
Les index de la jointure seront aussi important, comme les index pour les requêtes (couvrants si possible).
Vous pouvez aussi penser au partitionnement de table ou aux vues partitionnées indexées.
Enfin, pour certaines requêtes d'agrégation, vous pouvez penser aux vues indexées
Bref il existe un panel d'outil largement suffisant en général pour répondre aux fortes volumétries.
A +
Hello !Citation:
Envoyé par SQLpro
Rajoutons une info : si sur du DATETIME, éviter l'index clustered non unique. SQL Server doit rajouter un unifiant, ce qui alourdit la colonne.
J'ai peut-être le choix si je trouve comment modéliser différement, mais de toutes façons, il restera de gros volumes. Et de toutes façons, le sujet est interressant pour ma culcure personnelle.Citation:
Cela parait beaucoup... Mais avez-vous le choix ???
D'ailleurs, j'ai aussi le choix dans le sens ou c'est un projet personnel, on ne me demande pas ça au boulot ^^ La seule fois où j'ai eu beaucoup de données, j'avais un datawarehouse Netezza pour le supporter. Mais je n'en ai pas à la maison, bien sur :D
Voici donc une nouvelle question :
Cluster :
Vaut-il mieux faire
table(id, fk1, fk2, value) avec un index cluster unique sur id
ou table(fk1, fk2, value) avec un index cluster unique sur fk1,fk2 ?
Le 1er cas rajoute du volume, non ? Cette table ne "bougera" plus une fois remplie avec la colonne "value" calculée, il s'agit d'un "cross join" entre 2 autres tables.
Je vais jeter un coup d'oeil au "partitionnement de table" et aux "vues partionnées indexées".
table(id, fk1, fk2, value) avec un index cluster unique sur id
ou table(fk1, fk2, value) avec un index cluster unique sur fk1,fk2 ?
Le cas 1 présente un avantage si tu accèdes à l'enregistrement de façon unitaire, dans une site web de gestion des tables de bases par exemple. Tu peux accèder aux informations de la ligne plus simplement sans te trimbaler toute ta clé composée... Je parle sur le plan fonctionnelle uniquement. L'usage d'un gridview et d'un formview en asp.net l'impose pratiquement...
le cas 2 est le cas universitaire, il est donc recommandé en matière de modélisation!
Es-tu sûr qu'il s'agit d'un CROSS JOIN ? Si oui, les performances risquent d'être horribles.
Par principe, essaie de maintenir des index clustered sur des valeurs uniques, et aussi petits que possible, et surtout pas sur des colonnes où les valeurs s'insèrent de façon aléatoire. La taille de la clé de l'index clustered influe sur la taille de tous les autres index de la table, puisqu'ils la contiennent.
Ce que je voulais dire, c'est que la table est le résultat d'un cross join. En fait, il s'agit d'un cross join et d'une valeur calculée (dépendant des 2 clefs), mais vu les volumes et la taille du calcul, je garde le résultat dans cette table (c'est un résultat intermédiaire...)
Concernant le type d'accès que je vais avoir sur cette table :
j'ai sur ma table 1 un select avec une clause where renvoyant environ 2500 lignes, je fais ma jointure sur la fk1 de la table relationnelle (la grosse là), puis un join avec la fk2 sur une troisième table. Je n'accède jamais à "une ligne", mais à l'ensemble des lignes de même fk1.