Travail sur grosse BDD, des expériences (transfert, requêtes)

Travail sur grosse BDD, des expériences (transfert, requêtes) - SQL/NoSQL - Programmation

Marsh Posté le 07-06-2008 à 13:31:09    

Bonjour à tous!
 
Voilà il y a une question qui m'interroge, mais je vais d'abord commencer par vous expliquer un peu le schmilblick, pour que ce soit plus clair.
Imaginez 2 sites différents, que j'appellerai "site 1" et "site 2" (notez l'originalité  :D )
Sur le site 1, les utilisateurs s'inscrivent et passent un test. Les réponses données ne doivent absolument pas rester et être stockées sur le serveur du site 1. Donc les données doivent être envoyées et enregistrées directement dans la base de données du site 2. Déjà, première question, est ce possible ? à priori, je pense que oui.
Ensuite, lorsque les réponses sont dans la base du site 2, elles vont servir d'input à une petite moulinette, qui va recracher... des outputs!
et ces outputs, seront exploitées par le site 1 (ca va vous suivez?! je suis pas sur d'être très clair  :pt1cable: )
 
en gros, je ne veux pas que le site pour lequel je vais travailler conserve les données de l'utilisateur et n'ai pas connaissance du script de calcul.
 
sauf que pour un utilisateur, je vais avoir environ 80Ko (absolument impossible de descendre plus bas!) à transférer. Ce qui peut faire une BDD très vite importante a transférer d'un site à l'autre, étant donné qu'il sur le site 1, il y a potentiellement entre 10 000 et 30 000 utilisateurs/jour (sur une base de 300 000 inscrits sur le site 1). donc le nombre de calculs et de données à transférer va augmenter de jours en jours, au fur et à mesure que les utilisateurs vont passer le test (et donc potentiellement atteindre le nombre d'inscrits sur le site 1!).  
et ce transfert doit être fait tous les jours!
Donc ma question est, est ce qu'il est envisageable, de transférer une BDD de plusieurs Giga (centaine de Giga?), quotidiennement ? quels sont les risques ? limites? (les données ne sont pas forcément à risque, dans le sens où, il n'y a pas de données directement exploitables par un tiers, et ne contiennent pas de données confidentielles) est ce que vous savez si c'est quelques chose de fréquent ? des sites font des choses similaires ? vos avez déjà eu des expériences de ce genre la ?
 
question annexe :
 
quelle est la limite de taille de la BDD, pour qu'une requête de type "select champ 1, champ2 from table 1 where condition" passe du temps réel au "il faut plus de 2 secondes"? est ce que une requête de ce type peut être faite en temps réel sur une base de 1Go, 10Go, 100Go ?
 
Voilà, si vous avez des infos, des expériences, la dessus, merci de m'éclairer un peu!
Merci  :hello:  


---------------
Si vous ne faites pas aujourd'hui ce que vous avez dans la tête, demain, vous l'aurez dans le cul -- Coluche --
Reply

Marsh Posté le 07-06-2008 à 13:31:09   

Reply

Marsh Posté le 07-06-2008 à 19:06:05    

ca fait quand même beaucoup de choses vagues, n'espère donc pas avoir de réponses autre que vagues...
 
Pour la 1ère question => oui c'est possible, soit par des outils en natifs (mais cela dépend des bases de données) soit en codant son truc soi-même, mais bon vu la tronche de la question la réponse était forcément floue....
 
2ème question : tu vas aimer la réponse (qui sera floue) => oui c'est envisageable, tout dépend de la manière de transférer... si les sites sont reliés via un lien de 56Kbps ce sera ptet pas envisageable
Mais ca se trouve pour ton client, un transfert de disques durs entre les deux sites tous les soirs via un pigeon voyageur est viable... au moins c'est sûr que 100Go par jour ca sera la meme chose que 100Mo par jour
 
Question annexe : ca dépend de ta base de données, de la machine, de la requête, des données, de la structure de la base, et les chiffres que tu donnes ne sont absolument pas significatifs
Tu peux avoir une base de données de 1Mo qui tourne sur un 386 avec FoxPro tu mettrais sûrement plus 2 sec à faire un "SELECT *" qu'une base Oracle de 100Go optimisé aux petits oignons tournant sur une machine avec 16 CPU et dont les réponses à la requête sont déjà dans le cache....
 
Enfin bref tout ca pour dire que tes questions sont vagues et non pertinentes

Reply

Marsh Posté le 07-06-2008 à 20:32:26    

couak a écrit :

ca fait quand même beaucoup de choses vagues, n'espère donc pas avoir de réponses autre que vagues...
 
Pour la 1ère question => oui c'est possible, soit par des outils en natifs (mais cela dépend des bases de données) soit en codant son truc soi-même, mais bon vu la tronche de la question la réponse était forcément floue....
 
2ème question : tu vas aimer la réponse (qui sera floue) => oui c'est envisageable, tout dépend de la manière de transférer... si les sites sont reliés via un lien de 56Kbps ce sera ptet pas envisageable
Mais ca se trouve pour ton client, un transfert de disques durs entre les deux sites tous les soirs via un pigeon voyageur est viable... au moins c'est sûr que 100Go par jour ca sera la meme chose que 100Mo par jour
 
Question annexe : ca dépend de ta base de données, de la machine, de la requête, des données, de la structure de la base, et les chiffres que tu donnes ne sont absolument pas significatifs
Tu peux avoir une base de données de 1Mo qui tourne sur un 386 avec FoxPro tu mettrais sûrement plus 2 sec à faire un "SELECT *" qu'une base Oracle de 100Go optimisé aux petits oignons tournant sur une machine avec 16 CPU et dont les réponses à la requête sont déjà dans le cache....
 
Enfin bref tout ca pour dire que tes questions sont vagues et non pertinentes


 
Comme tu l'aura compris, les BDD c'est pas mon fort, mais merci pour ta réponse.
Pour un peut plus de précision, évidemment on aura pas un 56K! pour le moment rien n'est fait, mais le jour venu on prendra le serveur et l'hébergement qu'il faut. D'ailleur au passage, comment peut on évaluer (pour quelqu'un qui n'y connait pas grand chose, comme moi), s'il faut un serveur avec des quadri coeur ou un sempron ?! j'espère que les conseiller ovh & co, donnent de bons conseils  :D  
Disons que ma base, ca ne sera pas un truc très compliqué, juste une table avec 2 identifiants, et une vingtaine d'attributs (entier), et les requêtes qui seront faites dessus, ca sera du style "Select * from table where condition_portant_sur_un_des_attributs". c'est tout. le seul truc embêtant, c'est qu'il y aura potentiellement plusieurs millions d'enregistrements ; d'où une base conséquente.


---------------
Si vous ne faites pas aujourd'hui ce que vous avez dans la tête, demain, vous l'aurez dans le cul -- Coluche --
Reply

Marsh Posté le 08-06-2008 à 00:31:45    

Bon, si tu arrêtais de tourner autour du pot et nous disais un peu de quoi il en retourne, parce que là, tes pseudo explications sont totalement inutiles. Tout ce que l'on voit, c'est que tu ne sais pas de quoi tu parles.


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 08-06-2008 à 12:59:55    

de manière générale, vu ce que tu annonces tu n'auras pas besoin d'énormément de puissance CPU pour du simple select sans calcul ni agrégats
par contre si la volumétrie est conséquente tu as tout intérêt à avoir quelque chose qui assure au niveau I/O si ca doit répondre vite
et suffisamment de ram pour avoir pas mal de choses en cache (ce qui présuppose aussi une modélisation correcte, 3e forme normale au moins)
 
plusieurs millions de lignes pour un sgbd moderne c'est peanuts...

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed