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

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

Quelle base pour 100 millions de lignes par jour

n°2279869
kiwilol34
Posté le 21-04-2016 à 09:40:17  profilanswer
 

Reprise du message précédent :
Pourquoi pas du NOSQL, essaye de regarder du coté de MongoDB :)

mood
Publicité
Posté le 21-04-2016 à 09:40:17  profilanswer
 

n°2279875
PierreC
Posté le 21-04-2016 à 10:21:49  profilanswer
 

grand débat le nosql. J'y croyais pas vraiment avant la R&D de mon client, j'y crois encore moins après.
 
Cela demande d'apprendre un nouveau langage, différent dur chaque base nosql, c'est pas plus rapide que monetdb, chargement de CSV TRES lent, pas adapté à du comptage, mais surtout à du where.
 
Point positif, pas de lock sur des accès concurrents en lecture / écriture. Produits très utilisé donc beaucoup de ressource web.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2283827
giigii
Posté le 18-06-2016 à 16:09:52  profilanswer
 

Donc vous êtes passé d'une base OLTP à un base OLAP
Et vous construisez des projets BI custom par dessus
 
100Go pour 100M de lignes ça me paraît pas trop méchant.
Vous avez des stats sur vos requêtes ? temps d'accès ? utilisation des caches ? etc ... ?
 
Next steps C'est progiciel de BI et DB in-memory :)
Je pense ça vous permettrait de créer de la BI as a service à vos clients avec obtention de rapports ou de données pré-calculées de façon industriel
 

n°2283862
PierreC
Posté le 20-06-2016 à 09:30:11  profilanswer
 

marrant que ce sujet remonte à ce moment là car je peu y apporter des news.
 
C'est plus que certain au niveau du NoSQL, c'est absolument pas fait pour du comptage. Si les recherches peuvent être rapide (à condition qu'on est des Index), le count est très lent.
La raison est assez simple, pour compter les bases NoSQL font next, next, next .... jusqu'à la fin. Pour mongodb par exemple, je comptais 6 Millions de ligne par seconde. Ma R&D se basait sur 500 M de ligne (et oui déjà 5 fois plus qu'au début de ce Topic), donc si une requête me retournait 300 Millions, la réponse prenait au minimum 50 secondes (300 M / 6 M)
Si ensuite on calcul sur des couples de colonnes non indexé, les temps deviennent abominable.
 
La R&D à porté sur marklogic, couchbase, et mongodb. Pour du comptage elles se valent toutes, et donc mauvaise.
 
Je n'ai pas étudié ElasticSearch qui à peut être un fonctionnement différent pour le comptage.
 
Sinon entre temps une nouvelle base est arrivé, ou plutôt une ancienne base qui est en train d'avoir une nouvelle vie. Il s'agit de Columnstore anciennement InfiniDB.
InfiniDB était une base qui pouvait se positionner comme un moteur de Mysql. La société Calpont à fait faillite et avant cela à mis son code en OpenSource ( :love: ) et à travaillé avec Mariadb pour devenir un moteur standard de Mariadb.
 
Il y a 3 ans j'avais déjà étudié InfiniDB et les résultats était intéressant, mais je n'avais pas eu confiance dans la pérennité de la société (à juste titre).
 
La version Alpha de Columnstore est sortie le 14 Juin, j'ai commencé les tests le 15 Juin, et je devrais les terminer dans la semaine.
 
Les performances sont très impressionnante (Tester sur 1 seul nœud, 8 CPU, raid 0 de 2 SSD, 64 Go de Ram)
- Load de 500 Millions de lignes (38 Go) en 380 secondes
 
Puis suite de requêtes exécutées immédiatement après, sans création d'index :
- SELECT count(*) FROM ticket WHERE operateur_receveur='MTN';   6 sec
- SELECT count(*) FROM ticket WHERE duree_appel > 42;  3 sec
- SELECT count(*) FROM ticket WHERE operateur_receveur='MTN' AND duree_appel > 42; 4 sec
- SELECT count(*) FROM ticket WHERE operateur_receveur IN ('AROBASE','CIT','CAFE'); 6 sec
- SELECT count(*) FROM ticket WHERE duree_appel*NBR_APPELS > 98; 12 sec
- SELECT count(*),OPERATEUR_EMETTEUR FROM ticket GROUP BY OPERATEUR_EMETTEUR;  15 sec
- ALTER TABLE ticket ADD COLUMN temps_total FLOAT;  18 sec
- UPDATE ticket SET temps_total=NBR_APPELS*DUREE_APPEL;   --> Echec après plusieurs minutes. Cela reste une version alpha
- SELECT count(DISTINCT OPERATEUR_EMETTEUR) FROM ticket ; 15 sec
- SELECT sum(DUREE_APPEL) FROM ticket; 5 sec
- SELECT AVG(duree_appel) FROM ticket; 5 sec
- SELECT count(*) FROM ticket INNER JOIN profil WHERE MSISDN=MSISDN_EMETTEUR; 80 sec
- SELECT count(*) FROM ticket INNER JOIN profil WHERE MSISDN=MSISDN_EMETTEUR AND duree_appel > 120;  : 20 sec
- UPDATE profil SET STATUT_REGION=CONCAT(STATUT_LIGNE,REGION); : 10 sec
- SELECT count(*),CONCAT(REGION,STATUT_REGION) FROM profil GROUP BY CONCAT(REGION,STATUT_REGION)  2 sec
 
 
J'ai encore d'autre test à effectuer, test avec des OR, sous requête, et surtout exécuter plusieurs requête simultanément (pas plus de 5, pas besoin de plus). sachant qu'une requete utilise très souvent tout les CPU, très probable que le temps d'exécution augmente.
 
 
Par contre ne testr pas sur debian (Jessie), la version alpha n'arrive pas à s'y installer, à tester sur redhat ou Centos.
 
Pierre


---------------
Du tofu en Alsace : www.tofuhong.com
n°2284038
dadoonet
Posté le 23-06-2016 à 09:29:21  profilanswer
 

DISCLAIMER: Je bosse pour elastic... :)  
 

PierreC a écrit :


Je n'ai pas étudié ElasticSearch qui à peut être un fonctionnement différent pour le comptage.


 
Tu devrais définitivement tester !
 
Tu auras notamment :
 
* Recherche en temps réel dans tes data
* Analytics en temps réel sur tes data avec des temps de réponse époustouflants...
* Scalabilité "infinie" (en fait on ne connait pas la limite aujourd'hui). Un des gros clusters que nous avons est de 700 milliards de documents avec 1 million de documents par seconde...  
 
Met au dessus de tout ça un Kibana et whooooaaaa...  
 
PS: On écrit Elasticsearch ou elasticsearch mais pas ElasticSearch :p  
 

n°2284040
PierreC
Posté le 23-06-2016 à 10:10:17  profilanswer
 

dadoonet, qu'elle temps de réponse pour des requetes du genre que j'ai montré ? count(*) , sum(..) et where sur des colonnes non indexé ?


---------------
Du tofu en Alsace : www.tofuhong.com
n°2284041
dadoonet
Posté le 23-06-2016 à 10:15:38  profilanswer
 

PierreC a écrit :

dadoonet, qu'elle temps de réponse pour des requetes du genre que j'ai montré ? count(*) , sum(..) et where sur des colonnes non indexé ?


 
Tout d'abord, elasticsearch indexe tout ! Si ce n'est pas indexé ça n'est pas requetable.
 
A titre d'exemple (c'est un exemple hein ! A ne pas prendre comme argent comptant):
 
J'indexe sur mon laptop 1 million de documents générés aléatoirement (personnes physiques).
Pendant qu'il injecte (rythme d'environ 12-15kdocs par seconde), je fais des recherches et des agrégations.
 
Par exemple une agrégation multi-niveau du type :
 
- répartition des individus par année de naissance
  - répartition pour chaque année par sexe (H/F)
    - calcul du nombre moyen d'enfants par année et par sexe
 
Se fait sur 1 million de documents en environ 100ms.
 
Mais vraiment teste toi même pour te faire une idée !  
 

n°2284042
PierreC
Posté le 23-06-2016 à 10:21:33  profilanswer
 

ok je testerai mais 100ms pour 1 Million de document ca ferai 50 secondes pour 500 Millions de document :-)
 
Mais je testerais, promis :-)


---------------
Du tofu en Alsace : www.tofuhong.com
n°2284043
dadoonet
Posté le 23-06-2016 à 10:29:45  profilanswer
 

PierreC a écrit :

ok je testerai mais 100ms pour 1 Million de document ca ferai 50 secondes pour 500 Millions de document :-)
 
Mais je testerais, promis :-)


 
Hahaha! Ce n'est pas du tout linéaire !
 
Non pour 500m de documents analogues (avec le hardware qui va bien : genre plusieurs noeuds plutôt qu'une seule machine), tu devrais rester dans des ordres de grandeur raisonnables : genre bien en dessous de la seconde !

n°2284302
kao98
...
Posté le 27-06-2016 à 12:01:15  profilanswer
 

dadoonet a écrit :


 
Hahaha! Ce n'est pas du tout linéaire !
 
Non pour 500m de documents analogues (avec le hardware qui va bien : genre plusieurs noeuds plutôt qu'une seule machine), tu devrais rester dans des ordres de grandeur raisonnables : genre bien en dessous de la seconde !


Voilà, il est là le trick! :o


---------------
Kao ..98 - Uplay (R6S) : kao98.7.62x39 - Origin (BF4, BF1) : kntkao98
mood
Publicité
Posté le 27-06-2016 à 12:01:15  profilanswer
 

n°2284305
dadoonet
Posté le 27-06-2016 à 12:12:24  profilanswer
 

kao98 a écrit :


Voilà, il est là le trick! :o


 
Encore une fois: ça dépend. Et le mieux est de tester.  :p  
 
Si tu veux de la réplication, du failover... Il te faudra au minimum 2 data nodes et un node tie-breaker (master only).
 
38 Go de data peut très bien tenir sur une seule machine. Un index avec deux shards devrait aller je pense.
 
Bref: teste !  
 

n°2284307
kao98
...
Posté le 27-06-2016 à 12:19:38  profilanswer
 

dadoonet a écrit :


 
(...)
Bref: teste !  
 


Je suis pas PierreC, juste un Lurker que tu as fais sortir de sa léthargie :jap:
 
Effectivement, j'aimerais bien un petit test avec CR de la part de PierreC, il a fait ça bien jusqu'ici ;)


---------------
Kao ..98 - Uplay (R6S) : kao98.7.62x39 - Origin (BF4, BF1) : kntkao98
n°2284308
dadoonet
Posté le 27-06-2016 à 12:20:32  profilanswer
 

kao98 a écrit :


Je suis pas PierreC, juste un Lurker que tu as fais sortir de sa léthargie :jap:
 
Effectivement, j'aimerais bien un petit test avec CR de la part de PierreC, il a fait ça bien jusqu'ici ;)


 
Haha!
 
Pardon. J'avais pas vu :)

n°2305479
PierreC
Posté le 08-09-2017 à 09:49:12  profilanswer
 

petite news sur ce sujet.
 
On à passé notre projet en columnStore en prod il y a 2 semaines.
 
Produit vraiment très impressionnant. Pour du bigdata orienté BI (j'entends par là base mis à jour 1 fois par jour, et requete de calcul), columnStore est très impressionnant.
 
En sachant que derrière c'est mariadb, ca donne confiance.


---------------
Du tofu en Alsace : www.tofuhong.com
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

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