Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1491 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Quelle base pour 100 millions de lignes par jour

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Précédente
Auteur Sujet :

Quelle base pour 100 millions de lignes par jour

n°2228156
PierreC
Posté le 15-05-2014 à 19:03:01  profilanswer
 

Bonjour à tous,
 
  Je viens vers vous car je dois choisir une base de données pour accueillir un flux de données massif quotidien de l'ordre de 100 millions de ligne par jour.  
  Les données seront sous forme de CSV à intégré quotidiennement.
  Les données seront conservées sur 30 jours roulant, dont potentiellement 3 Milliard de ligne dans une table.
 
  Les requêtes sur cette table seront de type WHERE, GROUP BY, SUM, COUNT.  
 
  Que me conseillez vous ?
 
Pierre


Message édité par PierreC le 15-05-2014 à 19:03:32

---------------
Du tofu en Alsace : www.tofuhong.com
mood
Publicité
Posté le 15-05-2014 à 19:03:01  profilanswer
 

n°2228172
gpl73
Posté le 15-05-2014 à 21:13:20  profilanswer
 

wahoo :)  
aucune idée... je ne travaille pas dans le même "monde"...
par curiosité, c'est quoi comme appli? dans quel domaine? ça doit tourner sur quoi?
Guillaume


---------------
mieux vaut être un con au chaud, qu'un con gelé lol
n°2228175
lecbee
Posté le 15-05-2014 à 23:17:26  profilanswer
 

Bonsoir,
3 milliard de ligne ! Est-ce que tu pourrais estimer la quantité (en Go) que ça représente car ça peut influer sur le choix. Par exemple PostgreSQL a ces limitations :
Maximum size for a table? 32 TB
Maximum size for a row? 400 GB
Maximum size for a field? 1 GB
https://wiki.postgresql.org/wiki/FA [...] atabase.3F
 
Tu devras avoir une bonne machine aussi j'imagine pour supporter ça ?

n°2228176
flo850
moi je
Posté le 15-05-2014 à 23:20:03  profilanswer
 

là , je partirai sur du nosql : mongodb ou cassandra par exemple
 
ou un moteur de recherche type elastic search


---------------

n°2228177
Devil'sTig​er
Jee & Cee on the rock !
Posté le 15-05-2014 à 23:39:21  profilanswer
 

Ton CSV est variable ou reprend toujours les mêmes champs de données ?
 
Car de fait ca va dépendre de cela principalement, même du MySQL (via innoDB) peut servir cette quantité de données... C'est surtout l'opti de tes querys, quelque soit le moteur/type de BDD qui fera la différence ici...
 
Un article intéressant sur le sujet (facebook - mysql): http://gigaom.com/2011/12/06/faceb [...] sql-scale/
 
Maintenant j'ai jamais utilisé, mais on m'a toujours dit du bien de db2 et terradata sur de la grosse charge:
http://www-01.ibm.com/software/data/db2/
http://fr.teradata.com/?LangType=1036
 
 
Une autre solution, serait Redis, après tout, cette BDD a été créée pour répondre à une situation identique à la tienne (flot de données important et coulissant), donc a voir de ce côté aussi...
 
 
Dans un autre registre, l'externalisation n'est pas possible ? Car sur de gros volumes de données certaines solutions peuvent se révéler correcte voire avantageuse (surtout sur le cout de maintenance)...


---------------
JunZZi | Jee & Cee
n°2228184
PierreC
Posté le 16-05-2014 à 09:11:53  profilanswer
 

gpl73 a écrit :

wahoo :)  
aucune idée... je ne travaille pas dans le même "monde"...
par curiosité, c'est quoi comme appli? dans quel domaine? ça doit tourner sur quoi?
Guillaume


C'est pour un site d'actualité Français, nous allons devoir effectuer une analyse de navigation des abonnées et des visisteurs. Donc chaque évenement sera enregistrer


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228185
PierreC
Posté le 16-05-2014 à 09:14:22  profilanswer
 

lecbee a écrit :

Bonsoir,
3 milliard de ligne ! Est-ce que tu pourrais estimer la quantité (en Go) que ça représente car ça peut influer sur le choix. Par exemple PostgreSQL a ces limitations :
Maximum size for a table? 32 TB
Maximum size for a row? 400 GB
Maximum size for a field? 1 GB
https://wiki.postgresql.org/wiki/FA [...] atabase.3F
 
Tu devras avoir une bonne machine aussi j'imagine pour supporter ça ?


On devrait environ être à 100 Go pour la table, ce qui n'est pas si énorme que cela si on parle de Big Data.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228187
PierreC
Posté le 16-05-2014 à 09:21:43  profilanswer
 

Devil'sTiger a écrit :

Ton CSV est variable ou reprend toujours les mêmes champs de données ?
 
Car de fait ca va dépendre de cela principalement, même du MySQL (via innoDB) peut servir cette quantité de données... C'est surtout l'opti de tes querys, quelque soit le moteur/type de BDD qui fera la différence ici...
 
Un article intéressant sur le sujet (facebook - mysql): http://gigaom.com/2011/12/06/faceb [...] sql-scale/
 
Maintenant j'ai jamais utilisé, mais on m'a toujours dit du bien de db2 et terradata sur de la grosse charge:
http://www-01.ibm.com/software/data/db2/
http://fr.teradata.com/?LangType=1036
 
 
Une autre solution, serait Redis, après tout, cette BDD a été créée pour répondre à une situation identique à la tienne (flot de données important et coulissant), donc a voir de ce côté aussi...
 
 
Dans un autre registre, l'externalisation n'est pas possible ? Car sur de gros volumes de données certaines solutions peuvent se révéler correcte voire avantageuse (surtout sur le cout de maintenance)...


Le CSV sera constant, toujours les même colonne.
On est actuellement sur du Mysql, mais sur des requête avec des GROUP BY il souffre bcp, même sur un serveur puissant et bien tuné.
Les requêtes peuvent être radicalement différentes, car nous allons développer un outil de requête pour le client. Il pourra donc choisir les différents paramètre (col1=val AND col2=val2 , puis 5 minutes après ca sera un OR à la place) -> Soucis pour les index donc.
Pour les bases ont souhaites rester dans le monde de l'openSource, et si possible du gratuit. Au mieux qu'il y ait directement le paquet pour debian.
Pour l'externalisation, pas vraiment. On pourrait avoir d'autre projet avec des données sensible (genre banque), il faut donc qu'on gère nous même le système.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228188
flo850
moi je
Posté le 16-05-2014 à 09:26:45  profilanswer
 

essaye elasticsearch + kibana : je pense que tu as les groupements ( facettes) et l'interface quasiment clé en main


---------------

n°2228189
PierreC
Posté le 16-05-2014 à 09:30:33  profilanswer
 

flo850 a écrit :

là , je partirai sur du nosql : mongodb ou cassandra par exemple
 
ou un moteur de recherche type elastic search


On est arrivé à LA même question.
 
Cassandra ou Mongodb ?  
 
Comment choisir entre les deux ?


---------------
Du tofu en Alsace : www.tofuhong.com
mood
Publicité
Posté le 16-05-2014 à 09:30:33  profilanswer
 

n°2228193
gilou
Modérateur
Modzilla
Posté le 16-05-2014 à 12:03:07  profilanswer
 

http://www.googlefight.com/index.p [...] d2=Mongodb  :whistle:  
(en remplaçant Cassandra par Cassandra db dans le fight, c'est toujours en tête, mais d'assez peu)
A+,


Message édité par gilou le 16-05-2014 à 12:04:56

---------------
Samantha Fish Rulez!     --    Iyashikei Anime Forever!    --    In umbra igitur pugnabimus. --
n°2228199
el muchach​o
Comfortably Numb
Posté le 16-05-2014 à 13:22:28  profilanswer
 

PierreC a écrit :


On est arrivé à LA même question.

 

Cassandra ou Mongodb ?

 

Comment choisir entre les deux ?


Cassandra est plus scalable, je pense. La scalabilité est linéaire sur des dizaines de serveurs. Et l'autre très gros point fort de Cassandra est la résilience de la base face à des pannes. Si le système est très critique, ça peut être un avantage déterminant.

 

Le modèle de données est très différent, sensiblement plus limitant et difficile à exploiter avec Cassandra qu'avec MongoDB si tes données sont irrégulières.

 

Tu peux aussi voir le mode NoSQL de PotgreSQL, et RethinkDB.


Message édité par el muchacho le 16-05-2014 à 13:30:10
n°2228204
rufo
Pas me confondre avec Lycos!
Posté le 16-05-2014 à 13:28:59  profilanswer
 

Du NoSQL aurait du sens dans ce cas présent.
 
Cependant, si tu veux rester sur un truc proche de Mysql, il y a MariaDB : http://fr.wikipedia.org/wiki/MariaDB
Apparemment, les perfs auraient été bien améliorées par rapport à Mysql.
 
Au passage, les limites de Mysql :  
http://www.fromdual.com/mysql-limitations#limits51
http://forums.mysql.com/read.php?21,25724,224521
 
En surfant, je suis tombé sur ce recueil d'astuces pour Mysql : http://mysql.rjweb.org/doc.php/ricksrots
 
Y'a aussi un truc NoSql dans Myql : http://fr.wikipedia.org/wiki/Mysql [...] eur_InnoDB
 
Après, au niveau hardware, passer les HDD en SSD si c'est pas déjà le cas : ça devrait améliorer les temps d'accès. Et prévoir beaucoup de RAM :D


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2228207
PierreC
Posté le 16-05-2014 à 14:24:25  profilanswer
 

humm.... je viens de voir qu'on peut pas faire de GROUP BY sur cassandra, cassandra me semble vraiment limité en langage interrogation de données.
Elastic search me semble un peu pareil.
 
MongoDb semble vraiment plus souple à ce niveau
 
Mais j'aimais bien l'idée de rester sur une base colonne, plutôt qu'une base orienté document, je trouvais cela plus propre.
 
De plus je m'inquiète de l'effet buzz de mongodb, ca serait pas la première techno ultra populaire qui s'effondre en un rien de temps.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228209
rufo
Pas me confondre avec Lycos!
Posté le 16-05-2014 à 15:14:00  profilanswer
 

C'est pour ça que du MariaDB me paraissait pas mal. Ca limite les modifs à faire car l'archi Mysql et MariaDB sont compatibles et il aura un gain de perfs juste en changeant de SGBD.
 
Et comme précisé, voir si au niveau hardware, y'a pas des choses à faire.
 
Autre point à pas négliger : si c'est pour de l'analyse de consultations de pages par des utilisateurs, y'a sans doute pas besoin de temps de traitement courts. Le travail d'analyse peut sans doute se faire de nuit. Du coup, que le traitement soit fait en 3h au lieu de 5h ne présente pas un gros intérêt...
 
Ca me rappelle un gros algo d'analyse sémantique : il tournait la nuit; je faisais une partie du traitement (le parsing de textes) en php + BD Mysql. La partie calcul matriciel, je le faisais via un extract de ma BD en CSV, utilisé par un .exe codé en C et reposant sur une lib mathématique libre (la GSL, il me semble). L'exe sortait le résultat dans un CSV que je chargeait dans ma BD et je finissais le traitement dans Mysql.
J'avais bien essayé de coder le calcul matriciel direct dans Mysql avec une requête SQL (c'était le calcul du produit de la transposée d'une matrice par la matrice elle-même) mais ça mettait 20 mins pour une table qui contenant environ 12 millions d'enregistrements. Alors que l'extract en CSV, calcul par l'exe puis recharge dans Mysql, ça prenait 4 mins. :)
 
Edit : en journée, mon appli exploitait le résultat du traitement effectué la nuit.

Message cité 1 fois
Message édité par rufo le 16-05-2014 à 15:14:48

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2228210
flo850
moi je
Posté le 16-05-2014 à 15:16:58  profilanswer
 

PierreC a écrit :

humm.... je viens de voir qu'on peut pas faire de GROUP BY sur cassandra, cassandra me semble vraiment limité en langage interrogation de données.
Elastic search me semble un peu pareil.
 
MongoDb semble vraiment plus souple à ce niveau
 
Mais j'aimais bien l'idée de rester sur une base colonne, plutôt qu'une base orienté document, je trouvais cela plus propre.
 
De plus je m'inquiète de l'effet buzz de mongodb, ca serait pas la première techno ultra populaire qui s'effondre en un rien de temps.


Je n'ai pas utilisé mongo en prod, mais je t'assure qu'avec elastic search, les comptages sont triviaux à faire ( ils s'appellent facette ) , les filtrages aussi


---------------

n°2228241
PierreC
Posté le 16-05-2014 à 18:28:24  profilanswer
 

rufo a écrit :

C'est pour ça que du MariaDB me paraissait pas mal. Ca limite les modifs à faire car l'archi Mysql et MariaDB sont compatibles et il aura un gain de perfs juste en changeant de SGBD.
 
Et comme précisé, voir si au niveau hardware, y'a pas des choses à faire.
 
Autre point à pas négliger : si c'est pour de l'analyse de consultations de pages par des utilisateurs, y'a sans doute pas besoin de temps de traitement courts. Le travail d'analyse peut sans doute se faire de nuit. Du coup, que le traitement soit fait en 3h au lieu de 5h ne présente pas un gros intérêt...
 
Ca me rappelle un gros algo d'analyse sémantique : il tournait la nuit; je faisais une partie du traitement (le parsing de textes) en php + BD Mysql. La partie calcul matriciel, je le faisais via un extract de ma BD en CSV, utilisé par un .exe codé en C et reposant sur une lib mathématique libre (la GSL, il me semble). L'exe sortait le résultat dans un CSV que je chargeait dans ma BD et je finissais le traitement dans Mysql.
J'avais bien essayé de coder le calcul matriciel direct dans Mysql avec une requête SQL (c'était le calcul du produit de la transposée d'une matrice par la matrice elle-même) mais ça mettait 20 mins pour une table qui contenant environ 12 millions d'enregistrements. Alors que l'extract en CSV, calcul par l'exe puis recharge dans Mysql, ça prenait 4 mins. :)
 
Edit : en journée, mon appli exploitait le résultat du traitement effectué la nuit.


Sur mysql on à déjà bcp tunné autant la base que le systeme, mais on pourrait en effet tester MariaDb ou bien Innodb (on utilise MyIsam). Mais l'objectif etait d'avoir un gain en lecture de 5 à 10 . Je pense pas que cela suffise. Et puis il reste le problème des index, vu que les where peuvent se faire sur des colonnes aléatoire, on ne peut pas faire d'index.
De plus une base relationnel quel quelle soit, va s'écrouler si on à des jointures. Et si pas de jointures et qu'on choisit de tout agréger c'est le nombre de ligne qui explosent.
Nous considérons que nos volumes sont trop important pour une base relationnel, bien que nous avons encore des volumes faible pour dire que nous sommes entré pleinement dans le big data.
 
Pour le SSD on n'y pense bcp, car l'access disque est souvent le point limitant. Mais actuellement on tourne sur des serveurs avec 12 disques SATA en Raid, sur des lectures ou écritures en continu (pas aléatoire) ca va très vite. Avec les SSD on va trop manqué d'espace disque, on bien cela va coûter très chere. Mais on y viendra, c'est obligé (24 disques SSD en raid ca doit être cool)
 
Sur les traitements de jour / de nuit, nous avons des besoins de 2 cotés. Sur tout nos projets nous pré-calculons une partie des données la nuit, mais sur certain projet la nuit est trop courte. Ensuite la journée le client peut requeter sur ces données pré-calculé, mais le nombre de ligne et leur complexité peut rester parfois très important. Nos serveurs sont d'ailleurs bcp plus chargé la nuit que le jour :-)
 
PS : Je me souviens de ton pseudo, j'ai souvenir d'avoir eu de très bon échange avec toi déjà  :)


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228242
PierreC
Posté le 16-05-2014 à 18:29:24  profilanswer
 

flo850 a écrit :


Je n'ai pas utilisé mongo en prod, mais je t'assure qu'avec elastic search, les comptages sont triviaux à faire ( ils s'appellent facette ) , les filtrages aussi


Bon je vais retirer Cassandra de mon étude et y ajouter Elastic Search. Tu n'est pas le premier en m'en dire du bien.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228303
rufo
Pas me confondre avec Lycos!
Posté le 17-05-2014 à 21:10:11  profilanswer
 

PierreC a écrit :


Sur mysql on à déjà bcp tunné autant la base que le systeme, mais on pourrait en effet tester MariaDb ou bien Innodb (on utilise MyIsam). Mais l'objectif etait d'avoir un gain en lecture de 5 à 10 . Je pense pas que cela suffise. Et puis il reste le problème des index, vu que les where peuvent se faire sur des colonnes aléatoire, on ne peut pas faire d'index.
De plus une base relationnel quel quelle soit, va s'écrouler si on à des jointures. Et si pas de jointures et qu'on choisit de tout agréger c'est le nombre de ligne qui explosent.
Nous considérons que nos volumes sont trop important pour une base relationnel, bien que nous avons encore des volumes faible pour dire que nous sommes entré pleinement dans le big data.
 
Pour le SSD on n'y pense bcp, car l'access disque est souvent le point limitant. Mais actuellement on tourne sur des serveurs avec 12 disques SATA en Raid, sur des lectures ou écritures en continu (pas aléatoire) ca va très vite. Avec les SSD on va trop manqué d'espace disque, on bien cela va coûter très chere. Mais on y viendra, c'est obligé (24 disques SSD en raid ca doit être cool)
 
Sur les traitements de jour / de nuit, nous avons des besoins de 2 cotés. Sur tout nos projets nous pré-calculons une partie des données la nuit, mais sur certain projet la nuit est trop courte. Ensuite la journée le client peut requeter sur ces données pré-calculé, mais le nombre de ligne et leur complexité peut rester parfois très important. Nos serveurs sont d'ailleurs bcp plus chargé la nuit que le jour :-)
 
PS : Je me souviens de ton pseudo, j'ai souvenir d'avoir eu de très bon échange avec toi déjà  :)


Merci :jap:
 
Précision : MariaDB est un SGBD au même titre que Mysql (du reste, ils ont le même père, My est le prénom de la première fille du créateur, Maria, le prénom de sa 2ème fille;) ). InnoDB est un moteur de stockage de Mysql, au même titre que Mysql. Y'a pas encore très longtemps, il était admis que InnoDB était plus efficace por les accès en écriture et MyIsam pour les accès en lecture. Mais j'ai lu qq articles dernièrement qui indiquaient qu'InnoDB avait bien progressé.
Par contre, effectivement, passer à du MariaDB ne te fera pas un gain de 5 à 10 :(  
En revanche, pour rester sur du Mysql ou MariaDB, il y a le partitionnement de grosses tables qui pourrait être intéressant. Dans ton cas, ça serait du partitionnement sur des colonnes.
 
Et regardes si le moteur de stockage MEMORY de mysql et MariaDB ne pourrait pas t'être utile. Je me doute que vous n'avez pas assez de ram pour charger de telles tables. Par contre, peut-être que vous pourriez créer une sorte d'index un peu sur le style des BD noSQL : clé/valeur. Pourquoi pas une table de hash avec les ID des enregistrements correspondants dans d'autres tables.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2228305
Devil'sTig​er
Jee & Cee on the rock !
Posté le 17-05-2014 à 22:45:47  profilanswer
 

Dans ce cas si c'est la lecture sur lequel tu cherches a améliorer les choses, effectivement Mongo va pouvoir te servir via les replicaset (un point d'écriture, plusieurs points de lecture + tolérance aux pannes):
 
http://docs.mongodb.org/manual/tut [...] plica-set/
 
Fait attention à quelques points importants (vu que je suis passé par là sur un projet - au pire ca t'aidera a faire ton choix):
- l'ajout d'une donnée n'est pas automatiquement répliqué à l'instant même sur les slaves comme sur d'autres SGBD, donc tu peux avoir un truc du genre:

Code :
  1. var id = document.insert({});
  2. var item = document.get(id);


item n'existe pas, car sur document.insert il a pris le master, et sur le get il est allé cherché un slave -qui en interne ne trouvera pas l'id fraichement créé-... Ils se sont pas encore passé l'info...
 
- Mongodb est réputé pour glaner de la ram, et... Ben c'est vrai, il pompe le max possible sans faire crasher la machine of course, mais ca grimpe quand même plus vite qu'une instance MySQL (j'ai plus les chiffres en tête sorry :/)...
 
- par défault, on créé un ObjectID pour chaque entrée créée, renseigne toi bien sur cet objet, c'est une mine d'or (genre la date de création, d'id du process qui l'a généré, ..., bref une mine d'or :o)
 
- Toujours sur l'ObjectID, c'est toujours bon à lire sur un système d'une taille raisonnable: http://stackoverflow.com/questions [...] rent-colle
=> Concrètement parlant, si tu as deux serveurs qui utilisent la même bdd, il y a un risque de collision -mineur mais existant- sur l'unicité des ids...


---------------
JunZZi | Jee & Cee
n°2228324
PierreC
Posté le 18-05-2014 à 14:56:56  profilanswer
 

rufo a écrit :


Merci :jap:
 
Précision : MariaDB est un SGBD au même titre que Mysql (du reste, ils ont le même père, My est le prénom de la première fille du créateur, Maria, le prénom de sa 2ème fille;) ). InnoDB est un moteur de stockage de Mysql, au même titre que Mysql. Y'a pas encore très longtemps, il était admis que InnoDB était plus efficace por les accès en écriture et MyIsam pour les accès en lecture. Mais j'ai lu qq articles dernièrement qui indiquaient qu'InnoDB avait bien progressé.
Par contre, effectivement, passer à du MariaDB ne te fera pas un gain de 5 à 10 :(  
En revanche, pour rester sur du Mysql ou MariaDB, il y a le partitionnement de grosses tables qui pourrait être intéressant. Dans ton cas, ça serait du partitionnement sur des colonnes.
 
Et regardes si le moteur de stockage MEMORY de mysql et MariaDB ne pourrait pas t'être utile. Je me doute que vous n'avez pas assez de ram pour charger de telles tables. Par contre, peut-être que vous pourriez créer une sorte d'index un peu sur le style des BD noSQL : clé/valeur. Pourquoi pas une table de hash avec les ID des enregistrements correspondants dans d'autres tables.


"COLUMNS partitioning [...] that were introduced in        MySQL 5.5.0" > J'avais beaucoup étudié mysql 5.1, j'étais donc passé à coté de cette info. Intéressant.
Pour le moteur MEMORY sur mysql 5.1, c'etait bizarrement pas si extraordinaire. Je pense que l'interpréteur de requête de mysql n'est pas très optimisé pour ce moteur. De plus on arriverait pas à faire rentrer tout en RAM.
Pour l'idée de clef valeur, oui on à déja crée une table de ce genre (table transposée), car elle risquait potentiellement d'avoir 500 colonnes et pret de 20 millions de lignes. Pour gagner en perf on à utiliser uniquement du INT (ou plus petit quand on pouvait). La table fait à présent 1,7 milliard de ligne, avec un fichier de data de 60 Go, et un fichier d'index de 60 Go aussi. Le temps de requête en select est correct, mais c'est le temps de maintenance de la table qui est catastrophique. Pour faire un petit update ca prend presque 10 heures, et il faut presque 20 heures pour reconstruire la table de zéro.
 
Pour info dans notre étude on va ajouter infinidb, qui à fait évoluer sa licence open source (On October 16, 2013, the company announced that InfiniDB would be licensed under the General Public License v. 2) En effet il n'y a plus de limitation sur les update ou insert, alors que c'etait le cas il y a quelques années. En as tu entendu parlé ? gros avantages : c'est un moteur de mysql. 2eme gros avantage : on reste sur du langage SQL. J'avais fait des bench il y a 3 ans j'avais un gain de 5 à 50.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2228329
rufo
Pas me confondre avec Lycos!
Posté le 18-05-2014 à 19:35:38  profilanswer
 

Non, je connaissais pas infinidb. Je regarderai ce que ça apporte.
 
Au passage, ton coup du 60 Go de data et 60 Go d'index m'interpelle. J'ai lu par-ci par-là que si l'index d'une table fait plus de 20% du contenu de la table, il zappe l'index et préfère faire un scan complet de la table :/
J'imagine que t'as dû faire des EXPLAIN pour voir si le moteur de Mysql prenait bien des index ?


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2228330
PierreC
Posté le 18-05-2014 à 20:43:42  profilanswer
 

rufo a écrit :

Non, je connaissais pas infinidb. Je regarderai ce que ça apporte.
 
Au passage, ton coup du 60 Go de data et 60 Go d'index m'interpelle. J'ai lu par-ci par-là que si l'index d'une table fait plus de 20% du contenu de la table, il zappe l'index et préfère faire un scan complet de la table :/
J'imagine que t'as dû faire des EXPLAIN pour voir si le moteur de Mysql prenait bien des index ?


Ca faisait longtemps que j'avais pas regardé précisément la taille de cette table :-)
154 Go de data, fichier d'index de 51 Go
On est au dessus de 20%, l'index est qd même utilisé.
 

# ls -lh /var/lib/mysql/my_bo/source_qualif_myisam.*
-rw-rw---- 1 mysql mysql 8,7K avril  3 11:00 /var/lib/mysql/my_bo/source_qualif_myisam.frm
-rw-rw---- 1 mysql mysql  51G avril  3 11:53 /var/lib/mysql/my_bo/source_qualif_myisam.MYD
-rw-rw---- 1 mysql mysql 154G avril  3 22:59 /var/lib/mysql/my_bo/source_qualif_myisam.MYI
 
 # mysql 20:42:23 > desc source_qualif_myisam;
+-----------------+-------------+------+-----+---------+-------+
| Field           | Type        | Null | Key | Default | Extra |
+-----------------+-------------+------+-----+---------+-------+
| id_portefeuille | smallint(5) | YES  | MUL | NULL    |       |
| id_client_inbox | int(10)     | YES  |     | NULL    |       |
| id_p            | int(10)     | YES  | MUL | NULL    |       |
| id_f            | int(10)     | YES  |     | NULL    |       |
| id_qualif       | smallint(5) | YES  | MUL | NULL    |       |
| contenu_qualif  | int(10)     | YES  | MUL | NULL    |       |
| f_rang          | smallint(3) | YES  |     | NULL    |       |
+-----------------+-------------+------+-----+---------+-------+
7 rows in set (0.00 sec)
 
 # mysql 20:42:39 > EXPLAIN SELECT count(*) FROM source_qualif_myisam WHERE id_portefeuille=42;
+----+-------------+----------------------+------+-----------------------------------+-----------------+---------+-------+--------+--------------------------+
| id | select_type | table                | type | possible_keys                     | key             | key_len | ref   | rows   | Extra                    |
+----+-------------+----------------------+------+-----------------------------------+-----------------+---------+-------+--------+--------------------------+
|  1 | SIMPLE      | source_qualif_myisam | ref  | id_portefeuille,id_portefeuille_2 | id_portefeuille | 3       | const | 224453 | Using where; Using index |
+----+-------------+----------------------+------+-----------------------------------+-----------------+---------+-------+--------+--------------------------+
 
 
 
 
 


Message édité par PierreC le 18-05-2014 à 20:45:29

---------------
Du tofu en Alsace : www.tofuhong.com
n°2228337
dreameddea​th
Posté le 18-05-2014 à 23:48:23  profilanswer
 

Normalement en BDD, ce n'est pas la taille de l'index complet en Go qui compte pour l'utilisation ou non de celui-ci, c'est son côté "discriminatoire" (le ratio nombre de valeur unique/nombre total de ligne).  
 
Je pense que le 20% vient plutôt d'un règle du type : si la requête cherche dans plus de 20% des lignes de la table, alors le full scan est plus efficace que la recherche indexée.
 
De plus, la plupart des SGBDs maintiennent des stats sur la colonne indexée (nombre de valeurs uniques, nombre de NULL, parfois même un histogramme, ...) pour "estimer" l'intérêt d'un index. Ainsi il est possible d'estimer le pourcentage de ligne que va retourner une requête avec un critère sur une colonne indexée et donc "choisir" ou non d'utiliser l'index. Exemple si le nombre de valeurs uniques est 100 et qu'il y a 1000 lignes, la requête "WHERE C1 IN (V1,V2)" va statistiquement retourner 20% des lignes (j'ai bien dit statistiquement).
 
De tête, je dirais qu'un index :

  • est forcément "bon" (95% de chance) quand il discrimine avec un facteur supérieur à 10 (<10% des lignes retournées pour une valeur)
  • entre un facteur 5 et 10 (en 10% et 20% des lignes retournées) : un test s'impose pour "savoir" si ça sert (ça dépend des structures de tables, ...)
  • En dessous d'un facteur 5, normalement une recherche indexée est moins performante qu'un full scan.


En effet, un index marche très bien pour des valeurs "bien distribuées" et très discriminantes (tel un Unique id).
 
Mais même ce fonctionnement à base de stats et d'heuristiques peut donner des cas tordus.
 
Exemple, dans un progiciel, j'avais une table des périodes de facturation (logique abonnement) de plusieurs millions de lignes avec pleins de colonnes et 2 colonnes indexées (entre autres):

  • une colonne "NUMFACTURE" avec un numéro de facture : 25% de ligne avec des 0 (pas encore facturé), le reste avec une valeur > 1 (ces valeurs étant uniques). Cette colonne permet de retrouver le numéro de facture d'un période donnée (0 signifiant "période en cours de facturation" et il y a un historique de 3 périodes de facturation : soit 4 périodes au max par client)
  • une colonne "CLIENT" avec un id externe (clé de client) avec environ 4 lignes par clients dans la table (assez bien distribuée)


En Oracle 10g la requête du type "je veux la période non facturée pour le client 123 (soit qq chose du stype "WHERE NUMCLIENT = 123 AND NUMFACTURE=0" ) était horriblement longue (pire qu'un full scan) pour récupérer 1 pauvre ligne. En fait, il parcourrait 25% de la table et pire il le faisait via l'index sur NUMFACTURE (argghhh !!! : vive les I/O).
 
En fait l'optimiseur forçait l'utilisation de l'index sur NUMFACTURE à cause d'un pb de stats (qui étaient à jour). En effet, les stats ne portaient en 10g que sur le nombre de null (il n'y en a pas) et le nombre de valeurs distinctes (qui est statistiquement plus intéressant sur NUMFACTURE car ramène entre 0 et 1 ligne alors que numclient ramène 4 lignes). En 11g, l'histogramme (arrivé en 11g) aurait montré ce déséquilibre et aurait permis de "bypasser" l'index pour la valeur 0 (et de l'utiliser pour les autres).
 
J'ai du utiliser un hint pour forcer l'utilisation de l'index sur NUMCLIENT (l'ideal aurait été d'avoir un NULL à la place du 0, mais le progiciel ne fonctionnait pas comme ça).
 
Tout ça pour dire, qu'un index, ça ne s'utilise pas à la légère,et qu'il peut même poser des soucis là où l'on si attend le moins. C'est pas pour rien qu'il faut des (bons :) ) DBAs (et ce n'est pas mon métier)
 
++


Message édité par dreameddeath le 18-05-2014 à 23:54:28
n°2228351
rufo
Pas me confondre avec Lycos!
Posté le 19-05-2014 à 10:38:40  profilanswer
 

Intéressant ce retour d'expé :)


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2228362
Oliiii
Posté le 19-05-2014 à 12:00:23  profilanswer
 

Tu as aussi pensé a regarder du coté du BI? Genre SQL Server Analysis Service (bon c'est pas gratuit mais ça coûte pas un pont non plus).
 
Ça se prête en général assez bien a ce genre de query avec pleins de SUM, COUNT, GROUP BY. Par contre tu dois prévoir une bonne analyse pour pas faire un cube qui explose tout (ou qui retourne des conneries).

n°2228364
el muchach​o
Comfortably Numb
Posté le 19-05-2014 à 12:18:46  profilanswer
 

PierreC a écrit :

humm.... je viens de voir qu'on peut pas faire de GROUP BY sur cassandra, cassandra me semble vraiment limité en langage interrogation de données.
Elastic search me semble un peu pareil.


Avec Cassandra, je pense qu'il faut mettre un maximum de compteurs à jour au moment de l'insertion des données. Sinon, si tu fais les traitements a postériori, tu devras complémenter Cassandra avec Apache Hive ou Solr ou faire du map-reduce (Hadoop) dans pas mal de cas, ce qui est plus lourd qu'une requête SQL.


Message édité par el muchacho le 19-05-2014 à 13:12:33
n°2228374
rufo
Pas me confondre avec Lycos!
Posté le 19-05-2014 à 14:11:55  profilanswer
 

Oliiii a écrit :

Tu as aussi pensé a regarder du coté du BI? Genre SQL Server Analysis Service (bon c'est pas gratuit mais ça coûte pas un pont non plus).
 
Ça se prête en général assez bien a ce genre de query avec pleins de SUM, COUNT, GROUP BY. Par contre tu dois prévoir une bonne analyse pour pas faire un cube qui explose tout (ou qui retourne des conneries).


Dans ce cas, y'a Pentaho comme outil et il est gratuit ;) Mais je doute que ça réponde à son besoin de perfs. Ces outils sont basés sur des SGBD relationnels et servent plutôt pour de l'exploitation différée. Or d'après ce que j'ai compris PierreC a besoin d'un système autorisant l'exploitation en direct puisque les utilisateurs peuvent effectuer des recherches à base de filtres personnalisés. je doute qu'un outil de type BI arrive à proposer autant de vues que de filtres disponibles...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2274923
PierreC
Posté le 02-02-2016 à 18:25:27  profilanswer
 

Petit up de ce post afin de le mettre à jour après plus d'un an de mise en prod.
 
On à fait de monetdb, base peu connu, ne pas confondre avec mongodb.
 
Les performance sont TRES impressionnante. Gain de 5 à 100 fois plus rapide qu'un mysql très bien tunné.
 
Avantage :  
- la base respecte plutôt bien la norme SQL en particulier les jointures (au contraire de cassandra).  
- Pas besoin de créer d'index, d'où un gain de temps très important à leur construction ou recalcul.
- supporte le langage R
- performance TRES élevé (sur 300 million de ligne : SELECT count(*), champ FROM table group by champ , en moins de 10 secondes)
- paquet debian, et redhat avec repository et MAJ tout les 3 mois environ
- facile à prendre en main par les admin et les développeurs
- Aucun tunning à effectuer (c'est troublant même)
 
Point négatif :  
- Parfois des comportements bizarre, tel que des tables en doublon, mais certainement du à de mauvaise pratique car beaucoup de DROP TABLE / CREATE TABLE / LOAD DATA . Dans notre process la base est entièrement dropé puis recrée, car on est dans un logique de calcul pure sur 24 heures. Ce n'est pas indispensable, mais cela nous allait bien.
- Petite communauté de développeurs, mais très actif (on m'a déjà proposé des patch et une version a recompiler en moins de 48 heures)
- Il faut accepter le fonctionnement open source (support, développement)
 
 
Pierre

Message cité 1 fois
Message édité par PierreC le 02-02-2016 à 18:47:52

---------------
Du tofu en Alsace : www.tofuhong.com
n°2274976
rufo
Pas me confondre avec Lycos!
Posté le 03-02-2016 à 15:48:58  profilanswer
 

Je regarderai Monetdb.
 
En ce moment, je lis qq bouquin sur le big data :
- http://www.amazon.fr/Big-Data-Mach [...] 100720740/  -> très bien pour se faire un tour d'horizon des différentes technos existantes. Je l'ai terminé
- http://www.amazon.fr/gp/product/2212142439  -> pas encore commencé, il semble détailler quelques études de cas concrets. Ca devrait t'intéresser.
- http://www.amazon.fr/gp/product/2212141556  -> comme son nom l'indique, plutôt focalisé sur les produits NoSql. Je viens de le débuter.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2274981
PierreC
Posté le 03-02-2016 à 16:54:21  profilanswer
 

Machine learning, le nouveau mot à la mode semble t-il ...
 
Pour l'instant je suis en mode test en réel des bases, quand j'en aurais marre je repasserais en mode lecture.
 
Après hadoop et mongodb, je vais approndir postgres


---------------
Du tofu en Alsace : www.tofuhong.com
n°2274999
rufo
Pas me confondre avec Lycos!
Posté le 03-02-2016 à 21:13:30  profilanswer
 

Comme big data : c'est juste le nouveau mot pour data mining (avec un volume plus important de données).


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2278313
eclaireur
Posté le 24-03-2016 à 16:12:08  profilanswer
 

PierreC a écrit :

Petit up de ce post afin de le mettre à jour après plus d'un an de mise en prod.
 
On à fait de monetdb, base peu connu, ne pas confondre avec mongodb.
 
Les performance sont TRES impressionnante. Gain de 5 à 100 fois plus rapide qu'un mysql très bien tunné.
 
Avantage :  
- la base respecte plutôt bien la norme SQL en particulier les jointures (au contraire de cassandra).  
- Pas besoin de créer d'index, d'où un gain de temps très important à leur construction ou recalcul.
- supporte le langage R
- performance TRES élevé (sur 300 million de ligne : SELECT count(*), champ FROM table group by champ , en moins de 10 secondes)
- paquet debian, et redhat avec repository et MAJ tout les 3 mois environ
- facile à prendre en main par les admin et les développeurs
- Aucun tunning à effectuer (c'est troublant même)
 
Point négatif :  
- Parfois des comportements bizarre, tel que des tables en doublon, mais certainement du à de mauvaise pratique car beaucoup de DROP TABLE / CREATE TABLE / LOAD DATA . Dans notre process la base est entièrement dropé puis recrée, car on est dans un logique de calcul pure sur 24 heures. Ce n'est pas indispensable, mais cela nous allait bien.
- Petite communauté de développeurs, mais très actif (on m'a déjà proposé des patch et une version a recompiler en moins de 48 heures)
- Il faut accepter le fonctionnement open source (support, développement)
 
 
Pierre


 
J'ai regardé un peu leur site officiel.
 
Par curiosité, le stockage de base est en colonne ? (feature révolutionnaire vendue par M$ en 2012 puis 2014 en version enhanced :o )

n°2278316
souk
Tourist
Posté le 24-03-2016 à 16:31:16  profilanswer
 

eclaireur a écrit :


 
J'ai regardé un peu leur site officiel.
 
Par curiosité, le stockage de base est en colonne ? (feature révolutionnaire vendue par M$ en 2012 puis 2014 en version enhanced :o )


 
T'as du rater le titre de leur page d'accueil alors [:dawao]
 
"The column-store pioneer"
 
Donc oui j'imagine [:dawa]

n°2278325
PierreC
Posté le 24-03-2016 à 17:27:50  profilanswer
 

Oui c'est une base colonne. Chaque colonne est rangées dans plusieurs fichiers, qui sont dé-dupliqué . Quand une requête veut accéder à une colonne il charge le ou les fichiers en RAM et requête dessus. Si le système gère bien le cache, il n'y a même pas d'accès disque car la requete est déjà en RAM.
 

n°2278334
eclaireur
Posté le 24-03-2016 à 18:42:13  profilanswer
 

C'est semblable au Parralel DataWareHouse + column stored index chez M$ du coup :o
 
J'ai mis en place ça pour ma c0gip dans le cadre d'un projet BI, c'était le jour et la nuit.

n°2278336
PierreC
Posté le 24-03-2016 à 18:46:56  profilanswer
 

Tu as des chiffres en performance et en € ?


---------------
Du tofu en Alsace : www.tofuhong.com
n°2278341
eclaireur
Posté le 24-03-2016 à 19:06:05  profilanswer
 

PierreC a écrit :

Tu as des chiffres en performance et en € ?


 
Plus en tête mais je peux te sortir Ca demain :jap:

n°2278554
PierreC
Posté le 29-03-2016 à 11:37:59  profilanswer
 

Ok cool, car dans ce domaine les prix sont chère et un peu secret.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2279869
kiwilol34
Posté le 21-04-2016 à 09:40:17  profilanswer
 

Pourquoi pas du NOSQL, essaye de regarder du coté de MongoDB :)

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Quelle base pour 100 millions de lignes par jour

 

Sujets relatifs
SQL et les Update multi lignesBase de données ou fichier de données ?
Wordpress, récupérer une base de donnée ?base de données d'utilisateurs pour assurer la sécurité du service.
Base SQL et VB Excelaccès à une base de donnée distante
supprimer des lignes contenant une valeur donnéePervasive SQL Mettre a jour une Table
Quelle solution pour créer une base de données ?Convertir une base Access 2.0 en version récente
Plus de sujets relatifs à : Quelle base pour 100 millions de lignes par jour



Copyright © 1997-2016 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR