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

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

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 ?

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

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)...

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

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

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.

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

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

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

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.

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

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.

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.

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

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à  

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.

Merci
 
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.

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:

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 )
 
- 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...

"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.

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é.
 

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)
 
++

Intéressant ce retour d'expé

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).

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.

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...

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

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.

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

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

 
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 )

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

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.
 

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

Tu as des chiffres en performance et en € ?

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

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

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