Requête sur table avec des centaines de millions de lignes

[kaka83185]

Bonjour,
Voila je travaille sur un projet de géolocalisation avec SqlServer2008 ,
j'ai une table "trame" qui contiendra tous les trames de tous les boitiers GPS qui sont au nombre de 1000 , un boitier envoie en moyenne 10 000 trames en un mois, donc ma table contiendra minimum 10 millions de lignes en un mois.

La clé de cette table est un entier auto incrément.

Ma question est que lorsque je fait un

select avec where =" identifiant du boitier que je veux avoir ses trames"

dans la table "trame", donc le SGBD va comparer la valeur du where avec chaque ligne de la table, combien de temps va prendre cette simple requête avec une table contenant des centaines de millions de lignes? et est-ce qu'il faut utiliser d'autres méthodes pour optimiser le temps de la requête?

et merci.

[elsuket]

Bonjour,

donc le SGBD va comparer la valeur du where avec chaque ligne de la table, combien de temps va prendre cette simple requête avec une table contenant des centaines de millions de lignes? et est-ce qu'il faut utiliser d'autres méthodes pour optimiser le temps de la requête?

Il est impossible de prédire le temps d'exécution d'une requête sans plus d'informations que ce que vous donnez; d'autre part cela dépend aussi de la configuration hardware de la machine hébergeant SQL Server et votre base de données.

Pour obtenir un temps de réponse raisonnable, il vous suffit pour cela d'indexer la colonne boitier_GPS_id de la table dbo.trame.

La clé de cette table est un entier auto incrément.

Vous voulez dire clé primaire ? si vous avez créé la clé primaire sans spécifier l'index, alors celui-ci est un index cluster

Cela dit même avec 1000 boîtiers je doute que cela soit assez sélectif pour vous retourner un résultat en quelques secondes lorsque la table aura atteint son véritable volume de production.
Je ne doute pas que la table contient une colonne probablement de type datetime ou même datetime2. Donc il est évident que vous allez filtrer la table par date et par boîtier.
En ce sens il vaudra donc mieux créer un index non-cluster composite sur ces deux colonnes ...
Peut-être même que ce devrait être une contrainte d'unicité ?
C'est à dire qu'à tout moment, le couple {date, boîtier} dans l'entité trame est unique.
A ce moment là c'est encore mieux puisque vous avez la meilleure sélectivité possible

Dans l'attente de vos réponses et de la structure exacte de la table (colonnes, leurs types, et les index).

@++

[kaka83185]

Salut Nicolas,

Je vous remercie pour votre explication, c'est vrai que je n'étais pas très précis, voila le format de la table trame:

Trame( Rang_Trame,HHMMSS, Date, Longitude, Latitude, Atitude, Vitesse, Cap, #Id_Boitier) ;

tel que:

Rang_trame: est la clé primaire unique (int auto increment),
HHMMSS: est l'heure+minutes+secondes //j'ai séparer l'heure de la date.
ID_Boitier: est une clé étrangére,

Je ne doute pas que la table contient une colonne probablement de type datetime ou même datetime2. Donc il est évident que vous allez filtrer la table par date et par boîtier.

Tout à fait, au niveau de l'application, lorsque le client veut géolocaliser le boiter, il selectionne le boitier (ID_Boitier) et puis l’intervalle de date : ( date début + date fin)

Donc mes sélections vont se faire sur ces deux colonnes: "ID_Boitier" et "Date".

Sachant que la colonne "Date" est déjà triée, donc il serait facile à mon avis de l'indexer même en cluster.



Voici un petit extrait de la table Trame :

Rang_Trame_______Date___________HHMMSS__….....______ID_Boitier
734651________04/01/2012________13 :25 :22_____________121
734652________04/01/2012________13 :25 :55_____________444
734653________04/01/2012________13 :25 :59_____________322
734654________04/01/2012________13 :26 :03_____________121
734655________04/01/2012________13 :26 :12_____________444
734656________04/01/2012________13 :26 :29_____________533
734657________04/01/2012________13 :26 :31_____________121

En ce sens il vaudra donc mieux créer un index non-cluster composite sur ces deux colonnes ...

Oui, mais sachant qu'un boitier envoie en moyenne 2 trames par minute, pour 1000 boitier on aura 2000 trames par minute !

Et pourquoi ne pas le faire comme Index Cluster (indexant les deux colonnes Date+ID_Boitier) ?

Peut-être même que ce devrait être une contrainte d'unicité ?

Oui c'est une contrainte d'unicité si on ajoute la colonne HHMMSS.

Une autre question : Est ce que les index fonctionnent avec les requetes contenant "Between" dans le where?

par exemple:

select * from Trame where ID_Balise=121 et Date=04/01/2012 et HHMMSS between 13 :25 :22 and 13 :27 :00

Je n'ai pas l'habitude de travailler avec des flux de données gigantesques , donc j'essaye de bien cerner les problèmes avant de commencer la programmation,

cordialement.

[Waldar]

Envoyé par kaka83185

HHMMSS: est l'heure+minutes+secondes //j'ai séparer l'heure de la date.

Je pense que c'est une erreur dès lors que vous ferez des requêtes sur plusieurs journées.
La requête pour récupérer les données entre le 4 janvier 23h30 et le 6 janvier 00h30 s'écrit ainsi :

Code :

1
2
3
4
5
6
SELECT *
  FROM Trame
 WHERE ID_Balise = 121 
   AND [Date] BETWEEN '2012-01-04' AND '2012-01-06'
   AND (   ([Date] = '2012-01-04' AND [HHMMSS] >= '23:30:00')
        OR ([Date] = '2012-01-06' AND [HHMMSS] <= '00:30:00')  )

Alors qu'avec un datetime :

Code :

1
2
3
4
 SELECT *
  FROM Trame
 WHERE ID_Balise = 121 
   AND [DateTime] BETWEEN '2012-01-04 23:30:00' AND '2012-01-06 00:30:00'

Envoyé par kaka83185

Oui, mais sachant qu'un boitier envoie en moyenne 2 trames par minute, pour 1000 boitier on aura 2000 trames par minute !

Vous devriez envisager très sérieusement de partitionner (horizontalement) votre table sur des plages de dates (à vous de voir pour le pas de partionnement)
http://technet.microsoft.com/en-us/l...(SQL.100).aspx