¿Cuáles son las fortalezas y debilidades de una base de datos triplestore?

Question

¿Cuáles son las fortalezas y debilidades de una base de datos triplestore, como Mulgara? ¿En qué situaciones su funcionamiento sería significativamente diferente del de una base de datos relacional tradicional?

Estoy pensando en particular en situaciones en las que tiene datos en el formulario namespace:predicate=value. Parece que los almacenes triples mantienen los datos en su forma "natural", pero me gustaría saber si hay ventajas específicas más allá de eso.

Answer 1

Asumo que estás preguntando acerca de la persistencia de triples (y posiblemente a través de gráficos quads), donde el almacenamiento es un almacén de "nativo" triple (por ejemplo, TDB) o una base de datos relacional con una capa triple de tienda (como SDB)

Si un elaborado de sus requisitos, estoy seguro que los miembros de desbordamiento de pila pueden ofrecer una respuesta más dirigida, pero justo al lado de la parte superior de mi cabeza:

• tiendas triples nativos suelen tener un mejor rendimiento cuando el el tamaño del conjunto de datos es muy grande. Ver some numbers from the W3C.
• Las tiendas triple nativas pueden ofrecer razonamiento/inferencia en la tienda (como el juego de herramientas semántico de Oracle, aunque no es totalmente compatible con SPARQL).
• Las triples en un RDBMS pueden integrarse "fácilmente" en las herramientas de informes tradicionales (como los informes de Jasper) ya que puede consultarlas con SQL.

Answer 2

Soy el creador de Redland que incluye triple tiendas nativas en C plus He utilizado algunos de los sistemas Java como Jena y Sesame.

Es difícil decir más sin saber cuál es su problema, pero en general las tiendas triples nativas funcionan mejor si su patrón de espacio/consulta problema es más 'gráfico', en lugar de 'objetivo'. Objecty significa que usted tiende a manipular siempre - establecer/obtener el mismo patrón de datos cada vez - en ese caso también podría utilizar ORM u otro objeto relacional Mappping y un esquema fijo. Si su problema y esquema es más dinámico, 'Graphy', puede beneficiarse del enfoque de tienda triple donde es más fácil saltar a través de los datos de lo que suele ser en un mundo RDBMS (también conocido como join).

Por supuesto, también existe el enfoque de documento, como CouchDB, pero eso es difícil de saber a partir de la información que ha proporcionado.