Esistono implementazioni SPARQL filettate?

Stiamo costruendo un algoritmo iterativo usando una serie di query SPARQL per ogni iterazione. Questo algoritmo funziona alla grande, ma stiamo riscontrando un problema di utilizzo della CPU. I motori SPARQL come Fuseki non sono realmente multithread; consentono l'esecuzione di più query simultanee in più thread, ma ogni singola query è a thread singolo. Dall'osservazione di alcune note di Fuseki, ho l'impressione che Fuseki non sia thread-safe, quindi non è un problema banale.Esistono implementazioni SPARQL filettate?

Poiché il nostro algoritmo è intrinsecamente seriale in termini di query SPARQL e ci interessa una sola esecuzione alla volta, esiste un motore SPARQL che può sfruttare, ad esempio, 32 core?

fonte

2013-02-07 Adam

Fuseki è un filetto sicuro per progettazione. Se ci sono problemi, si prega di inviare una segnalazione di bug. – AndyS

@AndyS, da quello che ho capito è multithreaded nel senso che posso avere più thread ciascuno con la propria transazione. Tuttavia, non è possibile avere la stessa suddivisione della transazione tra più thread. Questo http://jena.apache.org/documentation/tdb/tdb_transactions.html dice che l'accesso multithread alla stessa transazione è limitato alla sola lettura (o un thread che fa le scritture), quindi il mio commento è che non è thread-safe (almeno per quello che voglio). Ho anche notato che il motore NON sfrutta più core per una singola query, che è quello che sto cercando, quindi la mia domanda. – Adam

sì, ci sono, BigData è un open source/esempio commerciale di questa.

mio progetto dotNetRDF inoltre usa multi-threaded pesantemente, nel mio caso ho levarage la funzione Net PLINQ per parallelizzare unisce, prodotti, FILTER e BIND operazioni se non sono sempre riconducibili a questo.

Sulla nota di Fuseki (Disclaimer Sono anch'io coinvolto nel progetto Apache Jena) come sottolinea AndyS Fuseki stesso è sicuro. Il problema è che il motore di query (ARQ) non è progettato per parallelizzare le operazioni, alcune idee su questo argomento sono state discusse in passato ma IMO implicherebbe una riscrittura abbastanza significativa.

fonte

2013-02-07 18:07:34 RobV

Controllerò BigData. La nostra macchina è una scatola Linux senza testa e preferirei evitare di dover capire come ottenere Windows se posso evitarlo, quindi prima di tutto verificherò le alternative. Ma sembra che dotNetRDF faccia quello che mi serve. – Adam

Dipende dalla vostra scala, mentre dotNetRDF ha un motore filettato è in scala solo a qualche milione di triple nella sua attuale incarnazione ed è un negozio non persistente (cioè è necessario caricare i dati ogni volta). BigData è probabilmente l'opzione migliore in particolare per gli scenari di produzione – RobV

Il motore Urika sviluppato e commercializzato da YarcData è altamente multithread (fino a diverse migliaia di thread simultanei) e viene eseguito in memoria molto grande. Probabilmente non adatto per un budget da hobbista però. :)

fonte

2014-04-07 21:23:14 spreinhardt

In realtà questa domanda era da quando stavamo lavorando su una voce alla Sfida YarcData che avevano fatto un po 'di tempo fa, quando abbiamo usato uRiKa. Ma volevamo qualcosa con A) per il debugging e tali e B) per confrontare uRiKa con una macchina classica. – Adam

Oh, e uRiKa è un intero apparecchio, non solo un software. La macchina usa i processori ThreadStorm (discendenti dai vecchi XMT se sei interessato) che fanno il loro threading in un modo radicalmente diverso dal modo in cui operano i chip x86. Quindi, anche se avessi il denaro, non potresti davvero usare il loro motore su una macchina standard. – Adam

Esistono implementazioni SPARQL filettate?

risposta

Problemi correlati