query s ($39) · Snippets

cest proche de la requette "la moins pire" que jai pu tester ce week end. par contre il te manque pas mal de chose dans cette version "refreshed" : Tu n'as pu les ?s ?p ?o (transformé en ?s a ?g) et tu n'as pas les "po" de ?sPointOfInterest. (cetait deja le cas avant le refresh)

ca en est a 18 minutes (pas ecnore terminé et cest les derniers triplets qui prennent le plus de temps) sur ma machine (que 16go de ram) 185Mo/250Mo avec "que 45M de solutions" la requette de base atteins les 100M de solutions en 42Mo/250Mo

refresh

J'ai coupé l'optimizer parce que ça me gonfle, et je l'oblige à calculer du coup ma subquery avec mon select. J'obtiens les premiers résultats après une quinzaine de seconde sur ma machine (avec 4Go attribué à bz)

par contre, j'ai pas trop d'idée sur le volume de données que cette requête est sensé générer, on a 3.8M de de triplets dans la base, l'idée et de pas en ramener 40 millions comme actuellement, mais j'ai la sensation que blazegraph met bcp de temps quand même à calculer ses réponses avec ma solution...

je la lance en l'état sur ma machine pour voir...

presque ;p Ton filtre il doit etre en not exists et il te manque encore les "po" de ?sPointOfInterest1

CONSTRUCT { ?sPointOfInterest1 http://www.w3.org/1999/02/22-rdf-syntax-ns#type urn:resource ; ?po ?oo. ?s ?p ?o . } WHERE {

?sPointOfInterest1 a <http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest> .

{ ?sPointOfInterest1 a http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest ; ?po ?oo # a ?p5a3124e8cb9cd # FILTER ( http://www.w3.org/2001/XMLSchema#string(?p5a3124e8cb9cd) = "http://www.datatourisme.fr/ontology/core/1.0#EntertainmentAndEvent" ) } UNION{ ?s ?p ?o. FILTER not exists { ?s a http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest } } ?sPointOfInterest1 (!<>)+ ?s . }

on est passé a 5M de tripplets pendant le week end ;p

ben écoute, je viens de la récupérer, j'ai 3.8 millions de triplets

mon filter "!=" ne fait pas le job ?

je miam et j'arrive, mais cf mon avant dernier commentaire il te manque des triplets dans ta requette (regarde la mienne) nop ton filter "enleve" le triplet qui type en POI des triplets de la solution mais n'enlève pas les triplets des "sous Resources" qui sont des POI cest un filter not exists qui lfo

20 minutes avec la derniere version, ce qui est pas mal mais pas encore ca

bien vu, exact

c'est pas tant le temps que ça prend que le nombre de triplets extraits

le problème que je cherche à résoudre, c'est de ne pas avoir 40M de triplets qui sortent de la base et qui vont être mangés par jena (ou le nouveau système de blaise) mais seulement les - au plus - 3.8M de triplets, ce qui limitera partout le volume de resources utilisées

à la limite, même si c'est un poil plus long, c'est moins grave vu que je ne consomme plus des ressources sur toute la chaine de production

et au passage, je sais que t'es un peu en difficulté face aux requêtes select donc : nawer@nawer-pc: $ curl -X POST http://localhost:9999/blazegraph/namespace/kb/sparql --data-urlencode "query=SELECT (count(*) as ?c) where {?s ?p ?o}" -H 'Accept:text/csv'

c
3808916

nawer@nawer-pc: $ curl -X POST http://producteur.dt.conjecto.com:9999/blazegraph/namespace/kb/sparql --data-urlencode "query=SELECT (count(*) as ?c) where {?s ?p ?o}" -H 'Accept:text/csv'

c
3809087

effectivement on a perdu 1K POI depuis vendredi soir ;p on est repasséa 50 780 et on a perdu 1M triplet

(au passage, t'as une requête de count qui tourne depuis 15 minutes sur le serveur de prod)

apres le pb cest pas le nombre de triplets, quelque soit la requête la reponse de blazegraph ne contient au max que 3.8M + 50K (les triplets crées a la volé avec urn:resource) Le problème cest le nombre de solution quil est obligé de produire pour "faire la cloture de la requête"

ah ? je pensais qu'il sortait l'intégralité de ses solutions vu qu'on a pas de filtre

dans ce cas, il est absolument inutile de chercher à l'optimiser, blazegraph met moins de 2 secondes à calculer ses réponses le problème ne vient donc absolument pas de la requête mais du traitement de blaise

non cest un contruct sans le query:hint qui dit envoie moi quand meme les triplets en doublons ill envoye pas de doublon

oué, le distinctspo à false

ok, alors next, cette requête est très bien en l'état, c'est le workflow de blaise qui doit être retravaillé

? heu non Blazegraph met pas 2 seconde a calculer

moi si

(je parle de la requête originelle)

?? Moi elle met plus d 'une heure pour ne pas finir (jai jamais laissé plus d une heur een fait)

CONSTRUCT { ?sPointOfInterest1 http://www.w3.org/1999/02/22-rdf-syntax-ns#type urn:resource. ?s ?p ?o } WHERE { ?sPointOfInterest1 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest. ?sPointOfInterest1 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest. ?sPointOfInterest1 (!<>)* ?s. ?s ?p ?o. }

CONSTRUCT { ?sPointOfInterest1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <urn:resource> . ?s ?p ?o . } WHERE { { ?sPointOfInterest1 a <http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest> ; a ?p5a3124e8cb9cd FILTER ( <http://www.w3.org/2001/XMLSchema#string>(?p5a3124e8cb9cd) = "http://www.datatourisme.fr/ontology/core/1.0#EntertainmentAndEvent" ) ?sPointOfInterest1 a <http://www.datatourisme.fr/ontology/core/1.0#PointOfInterest> } ?sPointOfInterest1 (!<>)* ?s . ?s ?p ?o }

ta version met moins d'une seconde chez moi

toi tu regardes le temps de téléchargement des données par le serveur, mais ça veut rien dire, c'est ton navigateur qui télécharge la solution, ça veut strictement rien dire. Il faut regarder combien de temps bz met pour calculer ses solutions, il met à peine une seconde, ensuite, le temps qu'il met pour transmettre la solution est limité par l'interface réseau, le disque dur ou le machin sur lequel t'envoie l'output de la requête, mais c'est pas blazegraph, c'est ce que j'appelle "le workflow de blaise"

je lui ai d'ailleurs évoqué ça tôt ce matin en lui disant que le problème ne venait pas de blazegraph là dessus mais bien de son traitement à lui. Il va regarder.

je fait mes test avec un blazegraph local

moi aussi

moi, pensant qu'on recevait 40 millions de données au lieu de 2 millions, je tentais de limiter la casse pour alléger son traitement mais là, blazegraph ne met qu'une seconde et tu m'assures qu'il ne sort que les 2 millions (enfin 3.8 maintenant) de résultats, donc le problème vient de Blaise, pas de blazegraph

J'arruve de sera plus simple a l oral mais ca veux peu etre dire que tu as un config de namespace plus performante que la mienne

(bon quand je dis que le problème vient de blaise, on s'entend hein, c'est évidemment pas à cause de blaise mais "dans la partie que gère blaise" )

ça, c'est évident

vivi ;p

mais ça me fait la même sur le serveur en prod

(enfin j'ai pas retesté aujourd'hui, le serveur en chie suffisamment comme ça, mais j'avais testé jeudi et j'avais déjà constaté que je recevais les données de suite, je te l'avais même dit)

bon bref, je te laisse arriver, je vais miam :)

cest quelle requête que tu as testée ? la requette originelle ou celle que jai mise dans les commentaire avec les union ?

bon ap ;p

CONSTRUCT {                          
  ?sPointOfInterest1 a <urn:resource>.
  ?s ?p ?o 
} WHERE
  {
    hint:Query hint:optimizer "None"
    {
      SELECT ?sPointOfInterest1 
      WHERE {?sPointOfInterest1 a dt:PointOfInterest}
   
    }.
  ?sPointOfInterest1 (!<>)* ?s. 
  ?s ?p ?o. 
}