Reprise du message précédent :
C'est vraiment étrange que ce soit aussi lent...
 
Tu peux me donner plus d'infos sur la base, histoire que j'en fasse un clône sur mon serveur ?
 
Genre, y'a combien de "dateserv" pour un "indrep" ?
Que contient "val" ?

Quelle est la véritable clé ?

Bon, je suis en train de me remplir une base de test avec ce script :
 

 
Tu me diras si c'est représentatif ou non de tes données

Bon, les tests que je suis en train de faire sont assez édifiants.
 
T'as REELLEMENT un souci avec ta machine, ou alors les SGBD utilisés sont particulièrement mauvais.
 
Première requête (chez moi : SELECT val, dateServ FROM Mesures WHERE dateServ >= 500 AND dateServ <= 1000 ORDER BY dateServ)
50100 lignes
Exécution: 10ms
Temps de charger toutes les lignes : 15 secondes
 
Seconde requête (chez moi : SELECT val, dateServ FROM Mesures WHERE dateServ = 500 ORDER BY dateServ)
100 lignes
Exécution : 3ms
Chargement des lignes : moins de 0.5 secondes
 
Troisième requête (chez moi : SELECT val, dateServ FROM Mesures WHERE dateServ = 150 AND indRep = 15 ORDER BY dateServ)
1 ligne
Execution : 50 ms
Temps de chargement des données : 1 seconde
 
Quatrième :
SELECT val, dateServ FROM Mesures WHERE indRep = 7 ORDER BY dateServ
Lignes : 100
Execution : 10ms
Temps de chargement des lignes : 1 seconde
 
OS : Windows NT4 Server Service Pack 6a
SGBD : SQL Server 2000 Entreprise Edition
Taille de la base : 8 Mo (bon, OK, faudrait que je mette plus de volume, mais vu ma brouette...)
Processeur : Pii 233 MHz (bah ouais...)
Mémoire : 384 Mo PC100
HD : 8 Go 4500 trm
 
Alors bon, OK, ma base est beaucoup plus petite que la tienne... Mais vu ma brouette, on peut s'attendre à des perfs meilleures avec une machine plus récente, même avec une base plus grosse.
 
Script de ma base :
 

 
PS: on notera l'absence de clé primaire ou d'index unique, car puisque je ne connais pas la structure de la table, je ne sais pas s'il y en a une.
 
PS²: Si t'as une PK sur un autre champ inutilisé dans tes requêtes, VIRE LA. Remplace-la par un simple index unique et une contrainte CHECK. En effet, l'index d'une PK étant obligatoirement clustered, cela t'empêche de faire l'index "IX_mesures" en cluster, hors c'est impératif qu'il le soit si tu veux que les requêtes soient rapide.

Waw, merci de te donner ce mal pour moi.
Alors voici la structure de ma base :
 

 
C'est vrai que ma clé primaire ne sert à rien... Je n'y avais pas encore réfléchi, je m'en suis rendu compte en essayant MySQL...
Je me demande même si le champ en lui-même sert à quelque chose.
 
Je remplis avec ça :
 

 
J'ai simplifié un peu...
Sinon, le truc des données binaires, t'emmerde pas avec, fous une chaine de 150-200 caractères à la place, ça ira très bien.
Pour les "flags", pareil, un entier 64 bits fait l'affaire (d'ailleurs c'est ce que j'ai mis, mais le truc foireux des bits et tt ça c t pour un petit test).
 
Voilà...

Ah oui au fait précision : bAjouterMesure() ça insère une ligne dans la table mesures, je pense que tu l'auras deviné.
Les paramètres ds l'ordre :
indRep, val, dateServ, dateSource, flagsTR, donBin, typeBin, lgBin.
Pour les autres champs, normalement c'est calculé dans bAjouterMesure(). T'y fous n'importe quoi, juste pour remplir quoi. Ce ne sont pas des critères de sélection.

OK, je lancerai une initialisation de la base avant d'aller manger (parceque je développe sur cette machine, et vu le processeur, je te laisse imaginer à quel point ça ramme quand j'insère un grand volume de données )

Euh, je viens de regarder ton truc mais... C'est pas super clair ton script.
 
Et surtout, il manque le "nbReperes".
 
Tu peux pas m'écrire en pseudo-code l'initialisation de la table "mesures" ? (et surtout, avec les valeurs, parceque sinon j'ai pas du tout la même volumétrie que toi, et ça biaise les résultats )

En attendant, je relance le script avec cette nouvelle config :
 
declare @dateserv as numeric  
declare @indrep as int  
 
set @indrep = 1  
while @indrep <= 500
begin  
    print 'Indrep ' + Cast(@indrep as varchar)  
 
    set @dateserv = 1  
    while @dateserv <= Cast(rand(@indrep) * 2000 as integer)
    begin  
        insert into mesures (dateserv, indrep, val, flag, bin)  
        values (@dateserv, @indrep, 'val ' + Cast(@indrep as varchar) + ' ' + Cast(@dateserv as varchar), @indrep * @dateserv, 'bin ' + Cast(@indrep * @dateserv as varchar))
        set @dateserv = @dateserv + 1  
    end  
    set @indrep = @indrep + 1  
end  
 
print 'Terminé'
 
=> Nombre aléatoire de mesures par indrep, comme ça, ça va déséquilibrer l'arbre des indexes
=> Les nouveaux champs, qui vont faire grossir la taille globale de la base
 
PS: Sinon, hier soir, en réinstallant mon serveur, j'ai pensé à un truc important quand on a une grosse base qui va être fortement solicitée : séparer les infos sur des disques physiques différents.
 
Voici l'architecture de mon serveur :
 
HDD1 U2W (8 Go) : Windows 2003 Server + Swap (2 Go)
HDD2 U3W (8 Go) : SQL Server 2000
HDD3 U3W (18 Go) : Fichier des données de la base
HDD4 U3W (18 Go) : Fichier des index de la base (TRES IMPORTANT !)
HDD5 U3W (18 Go) : Fichier log des transaction (ALORS LA, C'EST LE PLUS IMPORTANT, C'EST MEME STIPULE PENDANT L'INSTALL)
HDD6 U3W (18 Go) : Applicatif du logiciel
 
Ainsi, je n'ai pas de problèmes d'accès concurrents au disque. Notamment pour les écriture : 1 ligne écrite dans la base, c'est aussi une ligne écrite dans les index et une ligne écrite dans le journal des transactions. Sérialiser sur 3 disques est donc vital quand on a de gros volumes ou des données très solicitées.

Bon, ben ça insère tranquillement.
 
Je suis impressionné par la rapidité du truc, il en a déjà fait plus du quart en moins de 10 minutes.
C'est à croire que SQL Server se moque de la machine, parceque je suis habitué à ce que ce type de script d'insert soit extrêment lent !

Bon, je reviens.
 
Cette fois, ma base fait dans les 100 Mo (chais pas comment tu fais pour en avoir 500 Mo ), pour 717991 lignes dans la table mesures.
 
Explication des résultats.
Avec Query Analyser, lorsqu'on exécute une requête, il y a deux temps reconnaissables : le temps d'éxécution avant que la première ligne soit retournée (qui est le seul temps véritablement déterminant), et le temps que met l'ensemble des lignes à s'afficher. Ce dernier n'est pas déterminant, parceque lorsqu'on traîte le résultat dans un programme, logiquement, on va moins vite que la vitesse de chargement des lignes. Afin d'affiner le premier temps, je relance la requête en faisant un COUNT(*) afin de mesure le temps que met le serveur à retrouver en interne l'intégralité des lignes.
 
Résultats des requêtes :
 
1/
Résultat : 250500 lignes
Execution : Quasi instantané
Chargement des lignes : 1:19
Count : Moins de une seconde
 
2/
Résultat : 500 lignes
Execution : Instantané
Chargement des lignes : Moins de une seconde
Count : Instantané
 
3/ (attention, à la première éxécution, ça a mis 7 secondes !)
Résultat : 1 ligne
Execution : Instantané
Chargement des lignes : Instantané
Count : Instantané
 
4/
Résultat : 1427 lignes
Execution : Moins de 1 seconde
Chargement des lignes : 4 secondes
Count : Instantané
 
Pour la 3° requête, on notera un élément étrange : à la première exécution, il a mis 7 secondes avant de retourner quoi que ce soit. Par contre, lors d'une seconde execution, ce fut instantané.
 
Je pense que cela vient du fait que je n'avais pas encore utilisé l'index utilisé pour la requête, et que le SGBD a d'abors dû le charger en mémoire avant de l'interroger, ce qui ne dois plus arriver par la suite.
 
Bon, cette fois, vu mes résultats, avec bien plus de lignes que précédement, et des index déséquilibrés, et ma machine, je pense qu'il te reste deux solution :
1/ Potasse un maximum les docs du SGBD choisi, et optimise mieu ta base
2/ PostGre, et autres outils testés en sont encore au niveau "areuh areuh prout prout dans le bac à sable", et oriente-toi vers un SGBD connu et reconnu dans le domaine de la gestion de grosses base, tel que SQL Server ou Oracle. A noter notamment que SQL Server existe en version MSDE (totalement gratuite, et avec des limitation qui ne devraient pas t'impacter) et Personnal Edition (très peu chère, et moins de limitation que MSDE), donc leur coût n'est pas à prendre en compte.
Idem, Oracle, sous réserve d'un certain nombre de condition relativement contraignantes, PEUT être gratuit (mais bon, y'a peu de change que tu entres dans les clauses).
 
 
En tout cas, y'a pas à tortiller, vu la pièce de collection que j'utilise, si t'as pire, dans des conditions similaire avec une machine plus récente, c'est que le SGBD derrière ne suit vraiment pas.

Pour avoir plus de 500 Mo ? C'est simple : utilise ces valeurs : iNbReperes = 100 et iNbMesures = 86400    
Pas la peine de bordéliser l'index, il y aura toujours à peu près le même nombre de mesures par repère. Donc 86400 mesures pour 1 indRep.
Soit un total de 8640000 lignes...
Là j'essaie avec MySQL, et j'obtiens des perfs similaires à Postgres et SQLite.
Mais je n'ai pas encore optimisé comme il faut les index. Ya notamment un index "SPATIAL" avec MyISAM qui est tout nouveau, je vais ce que ça donne.

Ah j'avais pas vu l'histoire des disques différents. J'y avais pas pensé à ça... Mais c'est vrai que c'est évident ! Mildiou, faut que j'en parle aux autorités supérieures... Au moins sur un autre disque que l'OS quoi... Je pense que c'est le plus important.

En fait les index "spatial" c'est pour des formes géométriques apparemment.

Bon, je relance mon script ce soir avec tes valeurs, (et je vais quand même garder la bordélisation de mon index, histoire d'avoir un handicap )
 
Pour ce qui est des disques, au niveau de ma machine de tests, c'est pas le cas hein, j'ai toujours mon truc qui crépite 30 secondes avant d'ouvrir NotePad, et y'a qu'un disque. Donc j'ai pas triché pour mes tests
 
Sinon, c'est marrant, l'histoire des perfs pourries avec les index confirme un truc que j'imaginais pas aussi véritable : à quoi bon pouvoir paramètrer au millimètre un outils si ce dernier sait pas s'en sortir tout seul ? Avec SQL Server, y'a aucun paramètre (enfin, si, un ou deux quand même), auxquels j'ai jamais rien compris (et jamais cherché à rien comprendre) et ça marche très bien avec les valeurs par défaut.
 
Ce serait quand même intréressant que tu installes MSDE et que tu testes ta base dessus, parceque réellement, je suis intrigué par tes résultats !
T'as installé ta base sur le lecteur de D7, c'est pas possible

J'ai eu une idée tout à coup, que je vais expérimenter. J'ai décidé d'emmerder les conventions des bases de données (un peu, pas trop) et de fractionner ma table mesures : dès qu'il y a 1000000 de lignes, paf j'en crée une nouvelle. Je crée à côté une table contenant les dates de début et de fin de chaque table (de toute façon, les requetes arrivent dans l'ordre chronologique donc pas de pb).

Ouais, alors ça c'est goret quand même

M'en fous, faut que ça marche    

Ben utilise SQL Server

Le problème est que mon stage touche à sa fin (la semaine prochaine déjà, snif...), donc je ne sais pas si j'aurai réellement le temps de tester SQLServer. Mais il est question de rallonger le stage de deux semaines, donc si ça se fait, pourquoi pas, plutôt que de jouer les porcs avec mon système à 0.02€ .

Groumpf, ben pour mes tests, ce sera pour "courant de la semaine"
 
En effet, j'ai des légers soucis de mémoire, arrivé à 25 * 86400 lignes, y'a plus assez de mémoire virtuelle, et ça plante
 
Faut donc que je lance l'allimentation de la base en  trois fois (quand je dis que j'ai une charette, c'est pas pour de faux )
Faut d'ailleurs que je fasse de la place sur le disque dur, parceque j'ai plus de place non plus

lol ok, merci en tout cas

Mais j'y pense, la mémoire virtuelle n'intervient pas là dedans normalement !
La mémoire est libérée après chaque insertion, donc que t'en insères 3 ou 28 milliards, c'est pareil.
C'est sur que si la mémoire est pas libérée, ça peut poser problème, mais je vois pas pourquoi elle le serait pas.
Non ?

Ben...
 
Déjà, un procédure de ce type, c'est transactionnel, donc même si les lignes ne restent pas en mémoire, le SGBD doit conserver trace en mémoire de ces action, afin de faire un rollback.
 
Deplus, j'ai surtout un problème de place sur le disque. Et... plus la base grossi, et moins j'ai de place pour la mémoire virtuelle, donc... bah au bout d'un moment ça tiens plus

Ah wé Ok effectivement ton cas est grave lol.

arg fait chier j'obtiens plus les memes perfs qu'avant avec mysql ! c'est 10 fois plus lent sur certaines requêtes.
Je comprends plus rien... J'achète une corde ?
EDIT : ouf je suis sauvé, j'avais oublié que j'ai légèrement changé un détail : maintenant on fait 1000 repères, 8640 mesures par repère au lieu de 100/86400. Ca correspondrait apparemment plus à la réalité.
Ce qui explique peut-être la différence de perfs. Par contre, meilleures perfs sur la dernière requête, qui ne renvoie plus que 8640 lignes, mais bon, c'est pas encore la folie.
 
Faut que je refasse les tests avec SQLite.
Apparemment, Postgres ne leur plait pas trop selon ce que j'ai compris. Je pense qu'ils préfèrent un truc simple et connu comme MySQL.

Je m'aperçois d'un truc débile : je suis en train de faire les tests avec SQLite là et il ne bouffe quasiment aucune ressource ! Le CPU est même pas à 10% et la ram est très peu utilisée. On dirait qu'il se restreint, c'est bizarre. Quelqu'un connaîtrait pas un truc, un paramètre à régler pour lui dire "vas-y, fais toi plaisir, bouffe tout ce que tu veux" ?

achète un disque dur 15ktrm ?
 
ben ouais, ce qui prend le plus de temps, c'est pas les traîtements (parcourir un arbre, ça se fait avec un goupil asmhatique), mais plutôt aller copier les données du disque vers la mémoire... et ça, avec la normes SATA notamment, ça n'influe que très peu sur le CPU, mais ça n'en reste pas toujours limité par le débit du disque dur.
 
c'est pour ça que quand on a un serveur de BDD, on parle systématiquement d'array RAID 5 ou 50 en U3W minimum...

Ce que je trouve bizarre c'est que Postgres et MySQL occupent le CPU à 100% lors des insertions.

En effet, c'est un peu bizarre. Ceci dit, un INSERT est infiniment plus lourd à qu'un SELECT (la plupart des SGBD rament à mort lors de l'insertion), ne seraît-ce que parceque l'interface disque demande plus de CPU lors d'une écriture que lors d'une lecture, et surtout, il font plusieurs écritures pour chaque ligne (index + data) sans parler de l'alimentation des index, qui nécessitent rééquilibrage à interval régulier, mais aussi la vérification de l'unicité des clés...
 
SQLite prend que 10% de CPU à l'insertion aussi ?

ben oui c'est justement à l'insertion dont je parle, pour SQLite. Et quand je dis 10% c'est 10% du CPU pris au total, pas que pour SQLite. SQLite pousse à 4% maximum.
Ca part bien pour les 20000 premières lignes, et après ça rame comme c'est pas permis. Je comprends pas, j'ai pas touché au code depuis mes derniers essais.

c'est chelou
 
SQL Server c'est bien

Ouais ben je crois que j'essaierai ça d'ici peu parce que je commence à en avoir ras le bol de ces SGBD à la noix... Surtout SQLite avec ses transactions à 2 francs, que si tu les laisse par défaut ça ressemble à tout sauf à une transaction, ses performances aléatoires... Pas d'administration, certes, par contre, le programmeur qui s'en sert il en chie

Vive Oracle et puis c'est tout.

Ouais, mais Oracle, perso, je le préfère sur un serveur de type Sun. Sur du x86 ça pue

Nouvel essai avec SQLite : je repousse les limites de la dénormalisation      
Je crée une table mesures par repère. En fait, on s'en fout des sélections sur la date serveur, et au pire s'il y en a, ce sera associé avec une sélection sur un repère, donc on ne pénalise aucune requête en créant 1 table mesures / repère. Et on devrait donc avoir des performances pas mal du tout là...
Aurais-je trouvé la solution qu'il nous faut ? Suite au prochain numéro, les insertions sont en cours...

Un autre avantage de faire ça c'est qu'on peut supprimer tous les index a priori, ils ne devraient plus trop nous servir, voire même plus du tout.
Et ça c'est quand même un gros avantage : ça réduit la taille de la base, et ça nous permet de grossir : quand ça sera trop lent, on rajoutera les index et hop, miracle, ça rame plus .
Enfin on va bien voir mais à mon avis je tiens le bon bout là. Si ça se trouve, j'aurai même pas besoin de refaire les tests avec MySQL ou Postgres, ce qui serait je pense assez fantastique à deux semaines de la fin du stage.

Voici les requêtes que j'exécute.
La première : 16 sel/s
La deuxième : 116 sel/s
La troisième : 13.6 sel/s
 
Tout ça sans index... Je pense que c'est pas mal et que ça devrait leur convenir. La base ne fait plus que 364Mo.
Toujours 1000 repères et 8640 mesures par repère.
On se retrouve donc avec 1000 tables MesuresN qui contiennent chacune 8640 lignes.
On va voir ce qu'en pense le chef quand il arrivera.

oups j'ai oublié un 0 à la première requete :
BETWEEN 5 000 000 AND 350 000 000
au lieu de
BETWEEN 5 000 000 AND 35 000 000

bonjour,
j'ai installé postgresql 8.0.3, mais quand je clique sur le serveur pour me connecter, ça me donne :  
une erreur s'est produite : fe_sendauth: no password supplied
 
est ce que quelqu'un peut m'aider?
je vous remercie d'avance.
 

il n y a personne qui peut m'aider?