Bonjour à tous
 
J'ai une énorme base de données à gérer (environ 2 Millions d'entrées par jour, pendant 3 ans).
Est-ce que vous savez si Mysql est capable de supporter une telle taille (~2 Milliards de lignes) ?
J'ai déjà consulté quelques spécialistes en bases de données, et personnes n'a été capable de me répondre.  
Je n'ai pas de problèmes de capacité (j'ai 500 Go à ma disposition), je me pose juste des questions concernant les performances.
Est-ce qu'il vaut mieux utiliser Oracle, SQL-server, DB2 ?
 
Et pour améliorer les performances, est-ce que vous connaissez un moyen (logiciel, algorithme, idée) pour diminuer le nombre de données ? J'avais pensé spontanément à la moyenne, mais la perte d'informations est trop importante...
 
Merci pour toutes vos éventuelles réponses !

Pour ce qui est de réduire les données, tout dépend de ce que tu en fais  
Elles sont toutes dans la même table, les "anciennes" sont elles moins utilisées que les "récentes", est-il possible faire du ménage régulièrement ou faut-il tout garder ... ?
 
C'est vrai que pour une telle volumétrie, j'hésiterais aussi à utiliser MySQL

Whoua ca fait beaucoup non ?  
 
Ca veut dire 2 millions de requetes !  
As-tu penser a utiliser des technologie de load-balancing, car la le serveur va vite saturé non ?
 
C'est sur 24h ou 12h par jour car
ca fait quand même  
 
pour 24h  
83333,33333 requete/heure  
1388,888889 requete/minute  
23,14814815 requete/seconde
 
Pour 12h
166666,6667 requete/heure
2777,777778 requete/minute  
46,2962963 requete/seconde
 
ENorme quoi ! ENfin je trouve j'aimerai bien avoir des infos aussi dessus à titre personnel
 
donc drapal
 
 

tu peux regarder au niveau des techniques de Data Mining pour faire de la reduction de données
mais sans savoir ce que tu y stocke il va etre dur de t'aiguiller
 
ensuite, 500Go pour une table qui au bout de 3 ans comportera plus de 2 milliards de lignes, ca risque d'etre juste

Les données seront simplement en lecture, et stockées sur la même table : chaque donnée est constituée d'indices, et les correspondances sont faites dans d'autres multiples petites tables.
J'ai donc une seule table qui va recueillir les données. Pour répondre à toastbeman, les requêtes sont effectuées par un programme qui insère environ 100 000 lignes 20 fois par jour : chaque insertion prends à peu près 10 minutes car il faut faire la correspondance entre les données et les indices.
 
mrbebert, effectivement, je souhaite regrouper les données, faire le ménage, quite à perdre en précision, pour gagner de la place.
Mais je n'arrive pas à trouver, d'une part le terme qui qualifie ce regroupement (délestage ?), et d'autre part, la façon de faire ce regroupement, j'ai juste pensé à une moyenne.

 
AH oui c'est encore pire quand le serveur va se prendre  
10000requete/min soit 166,66666 requete/seconde, j'espere que ton serveur et ton OS tiendrons le choque !
 
Enfin je connais pas trop ! Mais ca va être chaud non ?
 
En tout cas j'espere que quelqu'un qui s'y connait bien va nous raconter comment mettre cela en service ca m'intéresse !

Voici la ligne type que je peux insérer dans mes données :
(123; 7896; 45642; 45; 2; 5; 121111369; 0; 4899; 879; 879)
En tout, j'ai une quinzaine de champs.
Chaque champ peut changer, et je n'ai pas deux lignes égales.

Déja, bien dimensionner les champs. En fonction des valeurs possibles (et envisageables dans le futur), prend la taille minimale pour chaque champ. Chaque octet gagné sur la longueur d'une ligne représente quand même 2 Go à terme

Une petite question: tu parles d'un "programme qui insère environ 100 000 lignes 20 fois par jour", mais ces données ne sont jamais consultées?
C'est juste pour faire de l'archivage d'informations?

En fait les données sont consultées tous les jours, à peu près 100 requêtes par jour...
Donc ma base sert pour de l'archivage et pour faire des stats.
Chaque champ a été optimisé (par ex. utilisation du type ENUM), et donc la taille de la ligne élémentaire est optimale.
Je cherche le moyen d'éliminer physiquement des données, par exemple en faisant la moyenne, ce qui me semble pas adapté.

Si tu n'as que 100 requêtes par jour pour des "accès statistiques", personellement je me poserais la question de l'interet de tout mettre dans la base.
Dans ta base, tu n'inserts que les données nécessaires aux stats(on va avoir du mal a te dire lesquelles sans connaitre la base et les stats demandées) et tu stockes tout le reste(comme tu veux mais en dehors de la base, genre fichier taré).
 
Par contre oublie mysql c'est pas fait pour ça...

Je me suis dit la même chose. Mais il y a un gros problème : comme tu as pu le lire, j'ai une quinzaine de champs, et donc à peu près 100^15 possibilités de requêtes différentes. Les données stockées sont au strict minimum.
Je m'explique :
Voici un aperçu de ma table :
12; 459; 4564; 8; 9; 0; 78; 45698; 1563
1; 546; 789; 369; 45; 69; 789; 1; 1236
...x 2 Millions
 
L'utilisateur pourrait demander : "Sort moi toutes les lignes où le champ 4 est 8 et le champ 7 est compris entre 45 et 89"  
Il ya tellement de critères statistiques que je ne peux me permettre de ne pas tout stocker... enfin, c'est l'impression que j'ai...

Qu'est ce que je dois utiliser ?

Et ça remontera 3 millions de ligne quand ta base sera pleine et sera inutilisable par l'utilisateur    
Reste qui si tu peux être amené à ramener l'intégralité des données de toutes les lignes selon 10.000 critères possibles, tu vas pas avoir d'autres choix que de tout mettre
 
Quand au SGBD, il te faut quelque chose avec des vrai options d'administration, de gestion de table space et toussa. Moi j'ai l'habitude de bosser sur DB2 mais les volumes n'ont rien de comparables ( environ 20 fois moins / jour et encore sur toute la base).
Quoi qu'il en soit pour gérer un tel bouzin tu vas avoir besoin d'un vrai DBA qui connaitra par coeur le SGBD choisi.
Perso je le prendrais meme avant qu'il choississe egalement la machine kivabien, parce que tu as des conneries genre sur db2, la 1ere des The "Top 10" performance boosters c'est:

Non en fait les requêtes sont assez spécifiques, et ne remontent "que" de 1000 à 1 000 000 de lignes.
Ces lignes sont à 99% des SUM() ou des COUNT().
Donc chaque requête va me retourner fnallement une valeur.
Merci pour les tuyaux concernant les BD

J'en suis pas à autant de données mais un postgresql bien configuré avec plusieurs Gio de RAM, ça dépote bien. Ensuite y a pas de miracles : des disques rapides (10k tours/min) avec un RAID qui va bien.
 
Pour améliorer les performances, les méthodes faciles et classiques sont :
- type de données adaptées (au niveau des colonnes)
- procédures stockées / vues / prepared statements

euh juste comme ça, quand ton disque est plein tu fais quoi ...

 
Le coup des procedures stockées; ca m'etonnerait que ca améliore les performances de la DB; je dirais plutot que ca decharge l'applicatif (ex: apache, IIS..)

ben pourtant ... c'est quoi le point comment entre ces 3 éléments ? le SGBD analyse et optimise la requête une bonne fois pour toutes. Si tu fais 2 millions de fois la même requête par jour, t'y gagnes sacrément.

 
Une procédure stockée construit en quelques sortes la/les requetes suivant les parametres que tu lui files; y'a donc ostensiblement un peu plus de CPU a utiliser qu'une requete simple (mais neanmoins optimisée) balancée a la bd. Tu vois mon raisonnement ou pas ?

Alors ca avance ?

 
Euh, je dis peut être une bêtise, mais une procédure stockée ne contient elle pas plutot des requêtes/plans d'exécution préparés à l'avance, quels que soient les paramètres fournis, si bien sûr ceux ci restent de la même forme?

A mon avis meme avec un super modele ce genre de requete va prendre un temps fou, car une fois filtré les données selon l'un des critere (en utilisant son index, donc rapide) il faudra scanner tout pour trancher les autresz citeres!
Ce genre de requete multidimensionnelle est super couteuse pour une base de donnée.
A mon avis vu l'ampleur des données et leur apparente simplicité tu devrais essayer de te faire ton propre systeme de données optimisé pour ce modele, et oublié toutes les SGBD "generiques" existantes.
En fait si tu considere chaque champ de ta ligne comme une dimension tu peux regarder du coté des modeles genre R-Tree ou M-Tree, ou tous les trucs genre courbe de hilbert et compagnie.
 
Voila par exemple un module perl (mais en C derriere) qui gere des M Tree avec un modele de stockage adaptés (je ne sais pas ce qu'il vaud en pratique) :
http://search.cpan.org/~mlehmann/Tree-M-0.031/M.pm
 
et, du meme auteur, un module qui va transformer tes valeur multidimensionnelles en une seule clé sur laquelle tu peut mettre ton index de SGBD :
http://search.cpan.org/~mlehmann/D [...] tialKey.pm
 
ce second module est plus generique (mais sans doute pas aussi efficace, mais au moins tu peux utiliser la base de donnée que tu veux derriere)

La procédure stockée, si son code ne change pas, n'est compilée qu'une et une seule fois.  
Son plan d'execution est gardée en mémoire, ce qui améliore grandement les performances de la base de données.  
Donc oui, fais un maximum de procédures stockées, et en plus ca te simplifie la gestion de la sécurité !
 
Quand à savoir si MySQL va tenir ou pas...personnellement je m'orienterais vers un Oracle / SQL Server / PostgreSQL en fonction des tes ressources/budgets/compétences...
 
Maintenant ce que dit pospos n'est pas faux ! De telles requêtes vont être plutot balèse pour ton SGBD !  
 
Concernant ton idée de prendre une moyenne, si tu inseres 2M de lignes par jour, je suis sur que tu peux en enlever une bonne partie de façon aléatoire sans que cela influe beaucoup sur tes statistiques finales...au lieu d'en garder 2 millions, gardes-en 500 000 (aléatoirement toujours) et regarde si le résultat te convient...

J'ai un doute sur le fait que postgresql tiennent le choque ! enfin il tiendra pas mieux que MySql !
 
Mais personne à fait d'etude dessus genre un systeme compet (Os / Sgbd) qui se prend 10000req/min arrive à tenir? Ca m'intérésserai une telle étude !

Plutot que de stocker une moyenne, ou de supprimer des lignes, j'essayerais plutot de ne pas stocker de doublons et donc de mémoriser quelque part le nombre d'occurence de chacun d'eux.
Même si tu tes 2 millions de ligne la 1ere fois tu as 2millions d'enregistrement identiques, plus tu feras d'insert plus la probabilité de tomber sur un enregistrement existant sera important.
Par contre ceci n'est réalisable que si tu n'as pas besoin de la date d'insertion de chaque enregistrement.

Au vu du ceci, je dirais qu'il pourrait avaler les 10000req/min sans que ça lui pose de souci, même sur un machine moins puissante.
http://www.sitening.com/tools/postgresql-benchmark/
 
Bien sûr, s'il y a moyen de lui fournir un CSV plutôt que x insert, ça ira encore plus facilement.

Oracle avec le partitionning peut-être une excellente solution (par contre, l'option de partitionning n'est pas donnée )... SQL Server est aussi très robuste
 
2M de lignes/j c'est loin d'être énorme surtout en le faisant en 20 fois
 
pour info : http://fadace.developpez.com/sgbdcmp/

postgres est surtout très costaud niveau accès concurrents.

100 requetes en une fois ou un peu n'importe quand?
Quel serait un temps maximum "acceptable" de reponse à une requete?

 
 
Merci excellent !

ouais enfin tu vois ça comme inconvénients pour postgres, c'est que c'est que les gars ils ont même pas lu la documentation. Et la sauvegarde sous postgresql, c'est autre chose que sous mysql !

peut-être mais ça n'atteinds pas le niveau des ténors du genre (quid de la sauvegarde incrémentale par exemple )... sinon, les rôles n'existent pas et les groupes ne peuvent pas avoir de sous-groupe... donc ça me parait plutôt juste

 
 
Ben oui j'ai un doute, bon qui s'estompe ! Car il y a 1-2ans j'avais entendu pas beaucoup de bien au niveau perf de prostgre !
 
DOnc voilà c'est pour cela que ce topic m'intéresse pour voir ce qui s'est passé et ce qu'on est capable de faire niveau sgbd !
 
DOnc pas de roulement de tambour, mais une bonne explication aurait suffit avec un exemple

bah c'est connu que postgres tient mieux la charge que mysql, on trouve beaucoup d'articles dans ce sens.

PostgreSQL 8.x, "Point In Time Recovery", les fichiers WAL générés sont des backups incrémentaux.

Niveau perfs maximales il est équivalent aux autres SGBD ACID, c'est à dire plus lent que MySQL + MyISAM (non compatible ACID) mais largement comparable à MySQL + InnoDB ou aux autres DBs du marché.
 
Sinon, ben tu ne te rendras jamais mieux compte qu'en lisant les docs et en le testant
(et tu découvriras qu'avec PG on est pas limité au PL/PgSQL, ils ont aussi inclus du PL/Python, PL/Perl, PL/Ruby, PL/Java, PL/PHP, PL/R, PL/SH)
 
Une autre DB intéressante est Firebird

ha oui... je ne connaissais pas
 
pour les ignorants comme moi : http://www.postgresql.org/docs/8.0 [...] nline.html

Bon j'ai pas tout lu, l'info a peu être déjà été donnée :
SqlServer2005 intégre une fonctionnalité de 'partitionnage' des tables qui est apparemment très efficace sur les tables volumineuses.
Malheureusement cette fonctionnalité n'est dispo que sur la version Entreprise, je n'ai donc pas pu la tester car on tourne avec des versions Standard.
On gére des bases volumineuses, mais pas à ce point ; on n'en est qu'à 400.000 enregistrements / jour
Clair qu'il faut oublier mySql.
Une bonne bécane avec du SCSI 15.000rpm en RAID et de la ram devrait faire l'affaire ...
Ns on tourne avec du BI Xeon 3GHz / 4Go de ram / SCSI 15.000rpm RAID5, çà marche bien

dommage que l'auteur du topic ne poste plus, c'etait un sujet interessant...