Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
2206 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
n°2306936
jeanmariec
Posté le 24-10-2017 à 15:10:00  profilanswer
 

J’étudie également le choix d'une base de données pour faire les types de requêtes que tu fais Pierre. Merci pour ton retour d'expérience.  
Pour ajouter un complément d'information voici un benchmark https://www.percona.com/blog/2017/0 [...] che-spark/

n°2306939
PierreC
Posté le 24-10-2017 à 15:40:40  profilanswer
 

article intéressant, j'avais pourtant bcp googlé, je ne l'avais pas vu ce Clickhouse.  
 
Il n'y a pas de test avec jointure par contre, c'est pour certaine base compliqué (cassandra par exemple, ou base noSql)
 
Affaire à suivre pour Clickhouse...


---------------
Du tofu en Alsace : www.tofuhong.com
n°2306945
jeanmariec
Posté le 25-10-2017 à 09:50:25  profilanswer
 

J'ajoute ce lien concernant une analyse entre les différentes bases de données (no)SQL pour souligner que le NoSql n'est pas valable pour tous les cas : http://www.guidescomparatifs.com/w [...] if-bdd.pdf

n°2306946
rufo
Pas me confondre avec Lycos!
Posté le 25-10-2017 à 14:25:52  profilanswer
 

Intéressant le comparatif en pdf :) Ca donne une bonne vision synthétique des avantages et inconvénients des différents systèmes de BD.


---------------
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°2306957
dj smelz
Posté le 26-10-2017 à 00:07:10  profilanswer
 

tres interssant ce pdf

n°2307040
jeanmariec
Posté le 27-10-2017 à 15:11:51  profilanswer
 

Aujourd'hui, j'ai trouvé un cours sur les jointures en NoSQL pour illustrer la problématique : https://chewbii.com/join_rel-vs-nosql/ et les correction https://chewbii.com/join_rel-vs-nosql-videos/ ( CNAM   :love:  )

n°2307146
PierreC
Posté le 31-10-2017 à 10:07:28  profilanswer
 

en effet, intéressant le dernier pdf de jeanmariec, mais il manque la catégorie qui me concerne le plus dans mon cas à savoir les bases de données sql orientées colonne.
 
Théorème intéressant, qui explique bien que la base parfaite n'existe pas : https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP


---------------
Du tofu en Alsace : www.tofuhong.com
n°2307421
jeanmariec
Posté le 08-11-2017 à 10:12:09  profilanswer
 

Merci pour ce lien, PierreC.
 
Et pourquoi pas utiliser elasticsearch dans ton cas (je ne connais pas trop cette techno) ?
Voici un podcast : https://lescastcodeurs.com/2016/12/ [...] id-pilato/

n°2307422
rufo
Pas me confondre avec Lycos!
Posté le 08-11-2017 à 10:21:23  profilanswer
 

PierreC a écrit :

en effet, intéressant le dernier pdf de jeanmariec, mais il manque la catégorie qui me concerne le plus dans mon cas à savoir les bases de données sql orientées colonne.
 
Théorème intéressant, qui explique bien que la base parfaite n'existe pas : https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP


Le paradigme CAP provient du big data. Dans un des bouquins que j'avais lu sur ce sujet (initiation au big data), c'était très bien expliqué et que c'était une question de compromis, d'équilibre à trouver entre ces "3 axes".


---------------
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°2307450
dadoonet
Posté le 08-11-2017 à 15:32:44  profilanswer
 

jeanmariec a écrit :

Merci pour ce lien, PierreC.
 
Et pourquoi pas utiliser elasticsearch dans ton cas (je ne connais pas trop cette techno) ?
Voici un podcast : https://lescastcodeurs.com/2016/12/ [...] id-pilato/


 
Héhé ! Merci d'avoir mis un lien vers ce Podcast. Je connais un peu le gars qui parle...  :lol:  
 
Pour information, nous avons des clients qui utilisent elasticsearch pour plus de mille milliards de logs.
Certains injectent jusqu'à 10 millions de documents par seconde dans leur cluster...
 

n°2307567
PierreC
Posté le 10-11-2017 à 08:57:00  profilanswer
 

jeanmariec a écrit :

Merci pour ce lien, PierreC.
 
Et pourquoi pas utiliser elasticsearch dans ton cas (je ne connais pas trop cette techno) ?
Voici un podcast : https://lescastcodeurs.com/2016/12/ [...] id-pilato/


Depuis la création de mon poste le besoin à évoluer, et j'ai appris aussi les différences entre les outils ce qui me permet de préciser ma question.
 
Si on injecte toujours un lot massif de données, celle ci se font d'un coup une fois pas jour et non pas au fil de l'eau. Je ne connais pas précisément elasticsearch là dessus, mais il me semble que c'est plutôt adapté à une injection de données au fil de l'eau (type log)
 
Ensuite sur nos traitements : c'est l'utilisateur qui va choisir ce sur quoi il veut compter. On ne sait pas à l'avance quelles seront les requêtes qui seront exécutées, et celles ci peuvent être très complexe. Hors elasticsearch à besoin qu'on crée des index (il me semble) sur les champs sur lesquels on va compter. Dans notre cas cela reviendrait à créer un index sur plus de 300 champs, bof bof ...
 
On avait étudier 2 concurrents elasticsearch (mongodb et je-sais-plus-quoi), qui sur ces 2 besoins étaient très mauvais. Sur le papier elasticsearch semblait avoir les même défaut sur ces 2 besoins, on ne la donc pas étudié.
 
Enfin raisonnement très bête. Nous avons des données très structurées, et optimisées. Comment une base de données prévue pour stocker des données non structurées (elasticsearch), et où chaque ligne n'a pas forcément le même nombre de champs, pourrait être plus efficace qu'une base données utilisant un typage de données strict et où chaque ligne est cohérente l'une avec l'autre ?


---------------
Du tofu en Alsace : www.tofuhong.com
n°2307570
bosstime
H1N1 ready
Posté le 10-11-2017 à 09:48:32  profilanswer
 

Perso je ferai un test sur ElasticSearch avec ton jeu données pour voir. C'est dommage de l'avoir écarté sans l'avoir réellemment testé.
Il est vraiment très rapide et pas que sur de la recherche de texte ;)

 

Pour son côté non structuré, c'est à nuancer car la notion de mapping équivaut grosso modo à la structure d'une table dans un SGDB. C'est là où tu choisi si un champ est indexable (donc requêtable) ou non. On peut imaginer qu'il gère des documents avec des champs non présents comme un SGBD gère des lignes avec des colonnes NULL...
Tu peux même forcer le côté structuré en utilisant le mode strict qui va interdire l'introduction d'un document qui contient un champ non déclaré. La seule contrainte de mémoire est qu'il n'est pas possible de modifier le mapping, il faut détruire l'index pour ca (ca a peut être évolué avec les dernière version). Il est à mi chemin entre un SGBD et du nosql comme MongoDB sur ce point.

 

Pour la question des 300 champs, je ne pense pas que ca lui pose de soucis particuliers.

 

Pour l'insertion massive, il y a un mode bulk.

 

Tu as aussi la possibilité de faire une requête multi index, donc par exemple on peut très bien imaginer créer un index par jour (couplé à un cron qui rebuild l'index de la journée précédante pour optimiser son espace sur le disque). L'avantage est de pouvoir faire des purges faciles, restreindre la recherche si tu connais l'intervalle des dates, etc...

 

PS: C'est la même problématique que ton problème de requête dynamique ? :D


Message édité par bosstime le 10-11-2017 à 09:50:56
n°2307571
souk
Tourist
Posté le 10-11-2017 à 09:49:58  profilanswer
 

PierreC a écrit :


Depuis la création de mon poste le besoin à évoluer, et j'ai appris aussi les différences entre les outils ce qui me permet de préciser ma question.

 

Si on injecte toujours un lot massif de données, celle ci se font d'un coup une fois pas jour et non pas au fil de l'eau. Je ne connais pas précisément elasticsearch là dessus, mais il me semble que c'est plutôt adapté à une injection de données au fil de l'eau (type log)

 

Ensuite sur nos traitements : c'est l'utilisateur qui va choisir ce sur quoi il veut compter. On ne sait pas à l'avance quelles seront les requêtes qui seront exécutées, et celles ci peuvent être très complexe. Hors elasticsearch à besoin qu'on crée des index (il me semble) sur les champs sur lesquels on va compter. Dans notre cas cela reviendrait à créer un index sur plus de 300 champs, bof bof ...

 

On avait étudier 2 concurrents elasticsearch (mongodb et je-sais-plus-quoi), qui sur ces 2 besoins étaient très mauvais. Sur le papier elasticsearch semblait avoir les même défaut sur ces 2 besoins, on ne la donc pas étudié.

 

Enfin raisonnement très bête. Nous avons des données très structurées, et optimisées. Comment une base de données prévue pour stocker des données non structurées (elasticsearch), et où chaque ligne n'a pas forcément le même nombre de champs, pourrait être plus efficace qu'une base données utilisant un typage de données strict et où chaque ligne est cohérente l'une avec l'autre ?


Si vous avez pas a priori quelles requêtes vous allez faire ça devient chaud. Peut-être qu'une solution flat file au format parquet et du Apache drill ça conviendrait mieux ?


---------------
L'inventeur de la cédille est un certain monsieur Groçon .
n°2307572
PierreC
Posté le 10-11-2017 à 10:03:50  profilanswer
 

souk a écrit :


Si vous avez pas a priori quelles requêtes vous allez faire ça devient chaud. Peut-être qu'une solution flat file au format parquet et du Apache drill ça conviendrait mieux ?


maintenant j'ajoute une contrainte de jointure entre table :)


---------------
Du tofu en Alsace : www.tofuhong.com
n°2307610
souk
Tourist
Posté le 11-11-2017 à 09:02:15  profilanswer
 

PierreC a écrit :


maintenant j'ajoute une contrainte de jointure entre table :)


Drill peut faire des joins


---------------
L'inventeur de la cédille est un certain monsieur Groçon .
n°2307664
dadoonet
Posté le 12-11-2017 à 22:19:12  profilanswer
 

PierreC a écrit :


Si on injecte toujours un lot massif de données, celle ci se font d'un coup une fois pas jour et non pas au fil de l'eau. Je ne connais pas précisément elasticsearch là dessus, mais il me semble que c'est plutôt adapté à une injection de données au fil de l'eau (type log)


 
Non. C'est adapté à la fois aux scénarios temps-réel et aux scénarios stables.
 

PierreC a écrit :


Ensuite sur nos traitements : c'est l'utilisateur qui va choisir ce sur quoi il veut compter. On ne sait pas à l'avance quelles seront les requêtes qui seront exécutées, et celles ci peuvent être très complexe.  


 
Génial. C'est justement le but d'elasticsearch. Tu y mets tes documents, et le jour où tu te poses une question, tu requêtes et c'est tout. Pas de trucs à précalculer. L'objectif d'elasticsearch est de "libérer les données".
 

PierreC a écrit :


Hors elasticsearch à besoin qu'on crée des index (il me semble) sur les champs sur lesquels on va compter. Dans notre cas cela reviendrait à créer un index sur plus de 300 champs, bof bof ...


 
Elasticsearch est un index. Par défaut il indexe tout et il le fait bien. Il est hyper optimisé pour ça.
 

PierreC a écrit :


On avait étudier 2 concurrents elasticsearch (mongodb et je-sais-plus-quoi), qui sur ces 2 besoins étaient très mauvais. Sur le papier elasticsearch semblait avoir les même défaut sur ces 2 besoins, on ne la donc pas étudié.


 
Dommage. Un simple POC d'une demi-journée vous aurait permis de comprendre ce que c'est et sa puissance.
Je pense que je me souviendrais toute ma vie du jour où j'ai finalement décidé de lancer le

bin/elasticsearch

sur mon poste et que je me suis pris la claque informatique de ma vie.  :pt1cable:  
 

PierreC a écrit :


Enfin raisonnement très bête. Nous avons des données très structurées, et optimisées. Comment une base de données prévue pour stocker des données non structurées (elasticsearch), et où chaque ligne n'a pas forcément le même nombre de champs, pourrait être plus efficace qu'une base données utilisant un typage de données strict et où chaque ligne est cohérente l'une avec l'autre ?


 
Elasticsearch index des documents structurés. Il y a un schéma. Le contenu de ces champs peut être de la donnée structurée (codes texte, numérique, geo points, dates, polygones...) ou du contenu non structurée (recherche full text).
L'intérêt est que tu combines très facilement les deux. Genre:
 
Donne moi les documents les plus pertinents qui parlent de "Un chien blanc", dont la date de publication est du dernier mois, localisés dans un rayon de 10km autour de notre dame de paris et sur le résultat, calcule moi également la répartition des documents par quartier de Paris et la distribution par jour.
 
Tout ça en une requête, en quelques millisecondes même sur des millions de documents...
 

n°2307668
PierreC
Posté le 12-11-2017 à 23:04:24  profilanswer
 

humm, je crois que je me ferais une R&D pour nous dans mon entreprise.  
 
Dommage que mon client n'est jamais accepté qu'on étudie ES.


---------------
Du tofu en Alsace : www.tofuhong.com
n°2307677
dadoonet
Posté le 13-11-2017 à 10:43:14  profilanswer
 

PierreC a écrit :

humm, je crois que je me ferais une R&D pour nous dans mon entreprise.

 

Dommage que mon client n'est jamais accepté qu'on étudie ES.

 

Faut m’inviter à manger ! Regarde  https://www.elastic.co/blog/free-lu [...] -engineers


Message édité par dadoonet le 13-11-2017 à 10:45:04
n°2307693
PierreC
Posté le 13-11-2017 à 19:48:30  profilanswer
 

si tu est sur Paris ou Strasbourg, banco, je t'invite


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