2012-02-06 6 views
35

Mi chiedevo quali sono i vantaggi dell'utilizzo di Triple Stores su un database relazionale?Triple Stores vs Database relazionali

+1

Sono cose piuttosto diverse; Può essere più preciso? –

+0

È un po 'come chiedere dei vantaggi dell'uso di un cacciavite su una mela. Entrambe le cose utili, ma difficilmente intercambiabili. –

+0

@ MikeSherrill'CatRecall 'Quindi spiegare perché questo è il caso di un'ottima risposta? Io per primo, certamente non lo so. E dare il benvenuto a tre signori relazionali. – Benjohn

risposta

43

Il punto di vista del CTO di un'azienda che utilizza ampiamente RDF triplestore commercialmente: flessibilità

Schema - è possibile fare l'equivalente di una modifica dello schema di un negozio RDF vivo, e senza alcuna interruzione, o riprogettare - non è un pranzo gratis, devi stare attento a come funziona il tuo software, ma è una cosa abbastanza semplice da fare.

Più moderno: gli archivi RDF vengono generalmente interrogati su HTTP, è molto facile inserirli in architetture di servizio senza soluzioni di bridging di hacky o penalizzazioni delle prestazioni. Inoltre gestiscono i contenuti internazionalizzati meglio dei tipici database SQL - ad es. puoi avere più valori in diverse lingue.

Standardizzazione: il livello di standardizzazione delle implementazioni che utilizzano RDF e SPARQL è molto più alto di SQL. È possibile scambiare un triplestore con un altro, anche se bisogna stare attenti a non andare oltre gli standard. Spostare i dati tra i negozi è facile, poiché parlano tutti la stessa lingua.

Espressività: è molto più semplice modellare i dati complessi in RDF che in SQL, e il linguaggio di query rende più facile fare cose come LEFT JOIN (chiamate OPTIONAL in SPARQL). Viceversa, se i dati sono molto tabulari, SQL è molto più semplice.

Provenienza: SPARQL consente di monitorare da dove proviene ogni informazione e di memorizzarne i metadati, consentendo di eseguire facilmente query sofisticate, tenendo conto solo dei dati provenienti da determinate fonti o con un determinato livello di attendibilità, su da un certo intervallo di date ecc.

Tuttavia, ci sono degli svantaggi. I database SQL sono generalmente molto più maturi e hanno più funzionalità rispetto ai tipici database RDF. Cose come le transazioni sono spesso molto più rozze o inesistenti. Inoltre, il costo per unità di informazioni memorizzato nell'SQL di RDF è notevolmente più alto. È difficile generalizzare, ma può essere significativo se si dispone di molti dati, anche se, almeno nel nostro caso, si tratta di un beneficio complessivo dato dalla flessibilità e dalla potenza.

+2

+1 per tutti i punti di Steve relativi ai vantaggi dell'utilizzo di un negozio triplo (e degli svantaggi). Includerei il ragionamento come un vantaggio, anche se questa non è una caratteristica onnipresente, quindi forse questo è un mezzo vantaggio =) – Michael

7

Entrambi i commentatori sono corretti, soprattutto dal momento che Semantic Web non è un database, è un po 'più generale di quello.

Ma suppongo che si possa significare un triplo store, piuttosto che il Web semantico in generale, poiché il database relazionale triple store v. È un confronto un po 'più significativo. Prevedo il resto della mia risposta notando che non sono un esperto di sistemi di database relazionali, ma ho un po 'di conoscenza sui negozi tripli.

I negozi triple (o quad) sono fondamentalmente database per i dati sul web semantico, in particolare RDF. Questo è il punto in cui finisce la somiglianza tra i database relazionali &. Entrambi i dati del negozio, entrambi hanno linguaggi di query, entrambi possono essere utilizzati per creare applicazioni in aggiunta; quindi immagino che se ti strizzi gli occhi, sono piuttosto simili. Ma il tipo di dati di ogni negozio è abbastanza diverso, quindi le due tecnologie si ottimizzano per diversi casi d'uso e strutture dati, quindi non sono realmente intercambiabili.

Un sacco di persone hanno lavorato nella sovrapposizione di una vista a tripli del mondo su un database relazionale, e questo può funzionare, e sarà anche più lento di un sistema dedicato per l'archiviazione e il recupero delle triple. Parte dei problemi è che SPARQL, il linguaggio di query standard utilizzato dai negozi tripli, può richiedere un sacco di self join, per cui i database relazionali non sono ottimizzati. Se si considerano i benchmark, come ad esempio SP2B, è possibile vedere che Oracle, che sovrappone il supporto SPARQL sul proprio sistema relazionale, viene eseguito nel mezzo o sul retro del pacchetto rispetto ai sistemi che supportano in modo più nativo RDF.

Ovviamente, i sistemi RDF verrebbero probabilmente schiacciati da Oracle se facessero query SQL su dati relazionali. Ma questo è il punto, scegli lo strumento che è adatto per l'applicazione che vuoi costruire.

Quindi, se stai pensando di creare un'applicazione web semantica, o solo cercando di acquisire familiarità nell'area, ti consiglio di andare con un negozio dedicato dedicato.

Non mi dilungherò sul ragionamento e su come questo funzioni nella risposta alle query nei negozi tripli, poiché questa è un'altra discussione, ma è un'altra importante distinzione tra sistemi relazionali e negozi tripli che fanno ragionamenti.

7

Alcuni triplestores (Virtuoso, Jena SDB) sono basati su database relazionali e forniscono semplicemente un'interfaccia RDF/SPARQL. Quindi, per riformulare la domanda leggermente, i triplestores sono costruiti da zero come un triplestore più performante di quelli che non lo sono - @ steve-harris sicuramente conosce la risposta a questo;) ma scommetto un sì.

In secondo luogo, quali caratteristiche i triplestores non hanno RDBMS. La risposta semplice è il supporto per SPARQL, RDF, OWL ecc. (Ad esempio lo stack di Semantic Web Technology) e per renderlo equo, è meglio definire il valore di SPARQL basato su SPARQL 1.1 (ha molte più funzioni di 1.0) . Ciò fornisce il supporto per la federazione (quindi così interessante), le espressioni del percorso delle proprietà e i regimi di entailment insieme a una serie di protocolli di aggiornamento, protocolli di gestione dei grafi (che SPARQL 1.0 non ha avuto e gravemente carente). Inoltre @ steve-harris sottolinea che le transazioni non fanno parte dello standard (possibile di worm) sebbene molti fornitori forniscano meccanismi non standardizzati per le transazioni (Virtuoso supporta il pooling e la gestione delle connessioni JDBC e Hibernate insieme a tutte le funzionalità transazionali di Hibernate)

Il grosso inconveniente nella mia mente è che non molti triplestores supportano tutto SPARQL 1.1 (poiché non è ancora presente nella raccomandazione) e questo è il vero vantaggio.

Detto questo, sono e sono sempre stato un sostenitore della sostituzione di RDBMS con i triplestores e le piattaforme che distribuivo interamente gestito da triplestores (Volkswagen nel mio ultimo ruolo ne è stato un esempio), deprecando la necessità di RDBMS. Un ulteriore vantaggio è che la mappatura da Object a RDF è più flessibile e offre più opzioni e flessibilità rispetto all'ORM tradizionale (noto anche come mettere un piolo quadrato in un foro circolare).

+1

SPARQL 1.1 è nella raccomandazione ora, AFAIK. –

0

Inoltre è ancora possibile utilizzare un database ma utilizzare RDF come formato di scambio di dati molto flessibile.