Base de données ENORME !!!

[cox1505]

Bonjour,
j'ai une base de données avec :
- 1 million de lignes par jour (environ)
- 10 champs par ligne (environ)
à partir de cela, j'aimerais calculer des valeurs sur :
- 15 min
- 1 heure
- 1 jour (jusque là, ça devrait aller)
- 1 semaine
- 1 mois
- 1 an
- 3 an (c'est le maximum)

Quelqu'un aurait-il une solution pour pas que les calculs durent 2 ou 3 heures ?

Merci d'avance

[qi130]

c'est quoi le sgbd (environ) ? l'OS hôte (environ) ?

T'es sûr que la table fait pas 11 champs (environ) ?

Peux-tu (environ) fournir la définition de cette table ?


Et tout autre renseignement permettant aux nombreux (environ) forumeurs de pouvoir fournir des réponses circonstanciées...

Et quels genres de calculs ?

Car vraiment là, sans boule de cristal, on aura du mal

[orafrance]

alors moi je ne dirais que 2 mots : partitionnement et snapshot... sans ça t'es mort

Pour Oracle bien entendu

[cox1505]

Je répond un peu tardivement mais j'avais pas trop le temps...

Le sgbd est SQL Server, l'OS est Windows 2000 ou NT
Les champs ne sont pas encore bien définis mais leur nombre peut-être de 10...
Les champs correspondent aux valeurs récupérées dans des logs (HTTP par exemple)
Il y a (environ ) 1 millions de lignes dans un log et on veut faire des calculs sur ces lignes, du genre :
-Temps total passé dans le serveur HTTP
-Temps mini, maxi passé dans le serveur HTTP
-Et d'autres calculs pas encore très bien définis...

Je pense avoir éclairé vos "boules de cristal"

Merci d'avance

[titides]

1 millions de lignes = 1 Millions d'enregistrements créés par jour ???

[cox1505]

oui, c'est ça, enfin presque...
il y a 1 millions de lignes sur 10h donc on peut faire 10 enregistrements de 100 000 lignes...

C'est un des problème qu'il faut résoudre...

[Barbibulle]

Je sais pas si ma proposition va aider mais je réfléchirai à votre place à une tout autre solution :

Plutot que de créer une usine a gaz qui va recalculer laborieusement à chaque requete vos statistiques, je n'enregistrerai dans la base que la synthése de vos log.

Si j'ai bien compris vous voulez lires vos logs pour les intégrer dans une base pour ensuite lancer des requetes de statistiques.

Ma solution est que le programme qui lit les log fasse lui même les calculs statistiques, que vous enregistrez dans la base. (Celà ne vous empéche pas de sauver vos log dans la base pour des calculs futurs non encore définis)

Donc si votre unité de stat la plus petite est le quart d'heure vous n'avez plus que 24*4=(environ )96 enregistrements par jours, ce qui est à la porté de n'importe quel SGBD.

Je ne sais pas si j'ai été clair en cette fin de semaine ?

[Danny]

Salut,

J'ai été éditeur d'un soft d'analyse de logs, spécialisé dans le clickstream et le data-mining. Un cas classique était par exemple :
* récupération des logs HTTP, des logs applicatives BroadVision, des données de pub
* création du clickstream
* intégration du référentiel client (p=212 => c'est du Poisson, ça vaut 10E, je fais 1E de marge dessus)
* génération de rapports synthétiques
* possibilité de requêtage avec BO
* algos de data-mining pour faire du clustering/profiling ou des associations.

1 million de lignes par jour, c'est pas ENORME, c'est même pas grand chose. Par contre :
1. Il faut avoir le hardware qui tient la route par derrière (pour un bon site on prenait un serveur Sun 4 CPU sous Oracle)
2. Il faut BIEN MODELISER la base avant de tout charger
3. Il faut faire un preprocessing des données ou utiliser un ETL : monter ça directement en base, c'est suicidaire
4. Il faut calculer des agrégats et les historiser : stocker tout cela n'a aucun sens. Par exemple, qu'est-ce que j'en ai à faire qu'il il a 6 mois un internaute a fait un hit sur monlogo.jpg ? Là aussi, il y a une phase de prétraitement.
5. 1 table avec 10 ou 20 champs : ça ne marchera pas ou ça marchera au début, puis moins bien puis plus du tout.

Deux exemples bêtes :
http://www.monsite.com/catalogue.jsp?prod=212&idcs=123456789
http://www.monsite.com/catalogue.jsp?prod=212&idcs=451254774
=> Même page vue deux fois mais passage du cookie de session dans l'URL => Je vais devoir faire un SELECT COUNT(*) ... LIKE 'http://www.monsite.com/catalogue.jsp?prod=212%'
=> Je suis mort...

Autre problème :
Quand je stocke du texte, un index sur les dix premièrs caractères est en général suffisant. Si je te donne un dico et une suite de dix lettres, tu vas tomber sur trois ou quatre mots au plus. Donc c'est efficace.
Là c'est l'inverse :
Tu auras tout le temps : "http://www.monsite.com/" = 23 caractères.
Il faudrait donc un index sur au moins les 50 premiers caractères pour que ça serve à quelques chose, mais un index sur autant de data, ça ne sert plus à rien...

Alors tu fais comment ? Il faut bien réfléchir à ça...

Et si c'est pour sortir des stats de base, autant prendre un open source comme AW Stat, mais monter des URL en base, c'est pas du tout modélisé, c'est suicidaire...

Ce n'est pas le nombre de lignes qui pose problème dans ton cas, mais la manière dont tu vas structurer ton info.

Si c'est bien fait, tu peux faire une requête :
* est venu de Google en utilisant banque comme mot clef
* a vu au moins un produit de placement
* n'a pas vu de produit d'épargne
* a vu le formulaire d'inscription
* a été au moins à l'étape 2 mais pas jusqu'à la 5/confirmation
* Est en ADSL sur Free
* A passé plus de 3 minutes sur le site
* A vu plus de 10 pages lors de sa session
=> Temps de réponse de quelques secondes

Si tu n'a pas ça, c'est que c'est mal modélisé...

[cox1505]

Voilà en détails ce que je veux calculer à partir des logs, ce qui correspond à mes indicateurs :
-Temps de réponse
-Nombre d'appels
-Taille question
-Taille réponse
-Nb requêtes par secondes
-Nb requêtes simultanées
-Taux d'occupation

Ensuite, voilà comment je veux pouvoir les classer, ce qui correspond à mes aggrégations :
-Code retour
-Temps (jour,heure)
-La requête
-Le demandeur

C'est le détail de ce que je veux avoir au final...

Si vous pouvez toujours m'aider
Merci d'avance