MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Grafico DB vs. DB documento vs. Triplestore

Non sono sicuro che sarei d'accordo con il sentimento che a molte persone non piace SPARQL. SPARQL 1.0 ha avuto alcune carenze, ma ha affrontato abbastanza bene ciò per cui era stato progettato e la nuova iterazione, SPARQL 1.1, si basa su di esso aggiungendo molti costrutti da SQL che le persone si aspettavano di vedere nelle specifiche originali, comprese sottoquery, aggregati &aggiorna la semantica. Penso che il fatto che sia standard e che puoi aspettarti di vedere la stessa analisi e semantica in ogni triple store, al contrario dei dialetti di SQL, sia una bella caratteristica.

Direi anche che tutti i triple store sono database di grafici; puoi inserire proprietà su bordi specifici in RDF, anche se non così bene come puoi con Neo4j. Ma i triple store hanno il vantaggio di un vero e proprio linguaggio di query, una rappresentazione dei dati standard del w3c che rende banale portare i dati in un altro triple store e, per un certo numero di triple store, la capacità di eseguire ragionamenti basati su OWL.

Non so nulla della scalabilità per la maggior parte dei db grafici, ma in generale i database RDF commerciali si adattano abbastanza bene. Tutti possono scalare fino a miliardi di triple, che gestiscono moltissimi casi d'uso. Anche se il modo in cui gestiscono la scala varia notevolmente da fornitore a fornitore rispetto alla scalabilità verticale o orizzontale, al clustering, ecc. Vedrai anche requisiti hardware e di memoria piuttosto diversi per soddisfare le implementazioni di ciascuno. Per quanto mi riguarda, ho avuto la tendenza a prendere un'istanza EC2, di solito una 2XL o 4XL, montare un EBS abbastanza grande da contenere i dati e sono abbastanza ben impostato.

Inoltre, alcuni triple store si integrano con Lucene o tecnologie simili per fornire indici invertiti sui dati e molti ora iniziano a includere indici geospaziali e temporali. Queste sono funzionalità molto utili di cui non sono sicuro che siano disponibili in qualcosa come Neo4j.

Detto questo, non si ridimensioneranno così come i database relazionali, semplicemente non sono così maturi. Ma non ti farai fregare nemmeno quando disponi di quantità "reali" di dati. Naturalmente, uno dei vantaggi dei triple store è il ragionamento, che è difficile da eseguire su larga scala, ma questo è in gran parte il motivo per cui sono stati creati i vari profili OWL. Ma puoi metterti in un angolo se non pensi al futuro.

Penso che i database dei grafici, in particolare i triple store, possano essere una buona corrispondenza per molte applicazioni in fase di creazione, ma non penso che ciò significhi che tutto dovrebbe essere fatto con loro. Come qualsiasi altra cosa, sono strumenti con i loro punti positivi e quelli negativi, quindi devi fare la scelta giusta in base alla tua applicazione. Ma probabilmente meritano sempre almeno una considerazione in questi giorni.