Discussion :

[Mydriaze]

Bonjour à tous,

J'utilise mysql pour traiter une bdd à croissance exponentielle et qui stocke déjà des centaines de milliers d'entrées par table.

J'ai au départ des fichiers qui sont traites par un script.

Il tire les infos, les traite, puis les insère dans la bdd.

Mais le volume de fichiers à traiter devient problématique.

j'ai essayé de lancer plusieurs fois le même script en même temps, mais ils rentrent en conflit. Je ne peux en faire tourner que 3 en même temps.

Mysql n'est que sur un nœud mais 8 processeurs sont pourtant disponibles .

J'ai sous divisé les tables en faisant 5 catégories distinctes: Une même table en devient 5 de même structure mais ne pouvant pas avoir les mêmes entrées

(par exemple une table pour les moins de 18ans, une pour les 18-35ans ..etc , mais contenant les mêmes colonnes)

Malheureusement même en augmentant beaucoup les locks ça n'augmente pas la vitesse. Je ne peux faire tourner que 3 scripts simultanément

Donc je vais créer 25 bdd de structure identique mais ne pouvant pas contenir les mêmes entrées (par exemple : une pour les noms commençant par A, une pour les B ...etc)

Mais il faudra après traitement de tous les fichiers que je remette tout ds la même base de données
j'espère faire tourner ainsi d'avantage de script même si certains seront queued.

Mes tables sont en innodb;

Mes questions sont les suivantes:

Est-ce qu'il est possible de tout réunifier ds une même bdd?

comment gagner autrement de la vitesse de traitement ds mon cas de figure?

Est-ce-que postgre SQL pourrait faire augmenter la vitesse?

Est-ce compatible avec les table innodb?

Merci par avance pour votre aide!

[qi130]

Lors des insert, y a t'il des commits réguliers ?

[Mydriaze]

oui!
insert et update !
Il execute sa requete et il "commit" aussitôt apres...

[SQLpro]

MySQL n'est pas taillé ni pour les gros volumes ni pour le transactionnel intensif pour ce qui concerne les bases de données OLTP.

Si vous voulez faire cela correctement, vous devez vous tourner vers des SGBDR ayant des techniques de storage haut de gamme comme Oracle, IBM DB2 ou SQL Server.
PostGreSQL n'est actuellement pas encore à même de le faire, même si c'est généralement mieux que MySQL.

Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

Et bien entendu, une seule base de données, quelque soit le volume de données et le nombre d'utilisateurs et transactions est mieux que n bases !

Pour ma part je viens de faire passer la DDE du gard sous SQL Server (PostgreSQL avant) avec une base contenant quelques centaines de millions de ligne et en moyenne 20 000 transactions par minute sur un bipro quadri cœur avec 16 Go de RAM et 8 disques physiques
Les temps de réponse, même pour des SELECT d'agrégation portant sur des millions de ligne sont de moins de 100 ms après tuning.

A +

[StephaneC.]

MySQL n'est pas taillé ni pour les gros volumes ...

HAHAHAHAHAHA !!!!
C'est vrai que Facebook ou Yahoo ne gère que quelques dizaines de To...

PostGreSQL n'est actuellement pas encore à même de le faire, même si c'est généralement mieux que MySQL.

HAHAHAHAHAHA !!!! (bis)
Mais comment peut-on raconter de telles inepties ? Tes deux affirmations sont aussi fausses l'une que l'autre

Pour ma part je viens de faire passer la DDE du gard sous SQL Server (PostgreSQL avant) avec une base contenant quelques centaines de millions de ligne et en moyenne 20 000 transactions par minute sur un bipro quadri cœur avec 16 Go de RAM et 8 disques physiques

Bravo ! Bientôt tu seras prêt à t'attaquer à des VRAIES bases volumineuses

[Mydriaze]

Merci beaucoup SQLpro pour votre aide!

J'ai oublié de préciser un détail : Je suis restreinte à linux ...

Donc à part Oracle, apparement je ne vois plus bcp d'autre solutions...

Sinon, pourquoi est-ce une mauvaise idee d'éclater la bdd en plusieurs?

Je ne pourrais pas rapatrier les donnees en une seule bdd ensuite?

En fait la croissance de la bdd est exponentielle mais mon probleme immediat est de la remplir le plus rapidement possible avec des info préexistantes; ensuite je ne fairai que des mises à jour. La solution d'eclater le bdd en n bases etait temporaire , le temps de rentreer le gros de la base. Momentanément, les mises à jours ne sont pas aussi consequentes.

C'est difficile à expliquer sans rentrer ds les details.
On a un gros volume de fichiers preexistants à analyser et dont on stocke en bdd certaines infos.
On recupere ces fichiers maj sur un autre site tous les 2 mois.
Momentanement les maj ne sont pas aussi conséquentes que l'existant.
Mais les mises à jour changent des donnees qui sont deja stockees et apportent aussi des nouvelles données.

[SQLpro]

HAHAHAHAHAHA !!!!
C'est vrai que Facebook ou Yahoo ne gère que quelques dizaines de To...

Le volume de données n'est pas la chose le plus importante. Je me permet de vous signaler quand même que les plus grosses base se trouvent essentiellement sous Oracle et DB2 (environ 200 To de données, en base monolithiques).
Voici quelques références sur des bases plus solides que vos dires :
http://www.eweek.com/c/a/Database/Su...t-Databases/1/
http://www.businessintelligencelowdo..._largest_.html
http://www.information-management.co...01/8182-1.html

En france, c'est de loin France Telecom avec Oracle qui détient la palme : olus de 30 To dans une base Oracle, mais en tout 600 To dans l'ensemble des bases...

HAHAHAHAHAHA !!!! (bis)
Mais comment peut-on raconter de telles inepties ? Tes deux affirmations sont aussi fausses l'une que l'autre

Il est amusant que vous me traitiez de menteur alors que vous affimez n'importe quoi sans la moindre source pour prouver vos dire.
De plus dans les différents cas que vous citez vous ne dites pas ni de quel type de bases de données il s'agit ni de ce qu'elles font :
dataWarehouse, OLTP, fortement ou faiblement transactionelles...
Or Facebook ou Yahoo sont des bases de données très faiblement transactionnelles, pour ne pas dire read only. En effet les mises à jour sur facebook sont sans aucune concurrence (puisque seule l'utilisateur du compte peut ettre à jour) et en quantité inexistantes par rapport au lecture. Bref, c'est presque de la base de données statique. De même pour Yahoo.
Vos exemple sont donc totalement inapproprié !
Vous vous discréditez par de tels commentaires !

Bravo ! Bientôt tu seras prêt à t'attaquer à des VRAIES bases volumineuses

Sans doute travaillez vous pour Yahoo ou Facebook...
Moi je travaille avec de vrais clients qui ont de vraies bases avec plusieurs Téra octets de données et qui sont de réelles bases OLTP avec de la concurrence d'accès...

A +