2012-02-06 9 views
35

Me preguntaba ¿cuáles son las ventajas de usar Triple Stores en una base de datos relacional?Triple Stores vs bases de datos relacionales

+1

Son cosas bastante diferentes; ¿Puedes ser mas específico? –

+0

Eso es como preguntar sobre las ventajas de usar un destornillador sobre una manzana. Ambas cosas útiles, pero difícilmente intercambiables. –

+0

@ MikeSherrill'CatRecall 'Entonces, explicar _por qué_ ese es el caso es la clave de una respuesta excelente? Por mi parte, ciertamente no lo sé. Y bienvenidos triplemente señores relacionales. – Benjohn

Respuesta

43

El punto de vista del director de tecnología de una empresa que utiliza extensivamente RDF Triplestores comercialmente: la flexibilidad

esquema - es posible hacer el equivalente de un cambio de esquema a una tienda de RDF en vivo, y sin ningún tiempo de inactividad, o rediseñar - no es un almuerzo gratis, debe tener cuidado con la forma en que funciona su software, pero es algo bastante fácil de hacer.

Más moderno: las tiendas RDF generalmente se consultan a través de HTTP, es muy fácil adaptarlas a las Arquitecturas de servicios sin soluciones puente de hacky o penalizaciones de rendimiento. También manejan el contenido internacionalizado mejor que las bases de datos SQL típicas, p. puedes tener múltiples valores en diferentes idiomas.

Estandarización: el nivel de estandarización de las implementaciones que utilizan RDF y SPARQL es mucho mayor que SQL. Es posible intercambiar un almacén múltiple por otro, aunque debes tener cuidado de no superar los estándares. Mover datos entre tiendas es fácil, ya que todos hablan el mismo idioma.

Expresividad: es mucho más fácil modelar datos complejos en RDF que en SQL, y el lenguaje de consulta hace que sea más fácil hacer cosas como LEFT JOINs (llamado OPCIONAL en SPARQL). Por el contrario, si los datos son muy tabulares, entonces SQL es mucho más fácil.

Procedencia - SPARQL le permite rastrear de dónde vino cada información, y puede almacenar metadatos al respecto, lo que le permite hacer consultas sofisticadas, solo teniendo en cuenta datos de ciertas fuentes, o con un cierto nivel de confianza, en desde algún rango de fechas, etc.

Sin embargo, hay inconvenientes. Las bases de datos SQL generalmente son mucho más maduras y tienen más funciones que las bases de datos RDF típicas. Cosas como las transacciones a menudo son mucho más crudas o inexistentes. Además, el costo por unidad de información almacenada en el SQL de RDF v es notablemente mayor. Es difícil generalizar, pero puede ser significativo si tienes muchos datos, aunque al menos en nuestro caso se trata de un beneficio financiero global dada la flexibilidad y la potencia.

+2

+1 para todos los puntos de Steve wrt a las ventajas de utilizar una tienda triple (y las desventajas). Incluiría el razonamiento como una ventaja, aunque esa no es una característica omnipresente, así que tal vez eso sea la mitad de una ventaja =) – Michael

7

Ambos comentaristas son correctos, especialmente porque Semantic Web no es una base de datos, es un poco más general que eso.

Pero supongo que podría querer decir tienda triple, en lugar de Web semántica en general, como la base de datos relacional de la triple tienda v. Es una comparación algo más significativa. Prolocaré el resto de mi respuesta al señalar que no soy un experto en sistemas de bases de datos relacionales, pero tengo un poco de conocimiento acerca de las tiendas triples.

Las tiendas triples (o cuádruples) son básicamente bases de datos para la web semántica, particularmente RDF. Eso es donde termina la similitud entre las tiendas triples &. Ambos almacenan datos, ambos tienen lenguajes de consulta, ambos se pueden usar para construir aplicaciones además de; así que supongo que si entorna los ojos, son bastante similares. Pero el tipo de datos que almacena cada uno es bastante diferente, por lo que las dos tecnologías se optimizan para diferentes casos de uso y estructuras de datos, por lo que no son realmente intercambiables.

Mucha gente ha trabajado para superponer una vista del mundo triples sobre una base de datos relacional, y eso puede funcionar, y también será más lento que un sistema dedicado para almacenar y recuperar triples. Parte de los problemas es que SPARQL, el lenguaje de consulta estándar utilizado por las tiendas triples, puede requerir muchas uniones propias, algo que las bases de datos relacionales no están optimizadas. Si observa puntos de referencia, como SP2B, puede ver que Oracle, que simplemente superpone el soporte de SPARQL en su sistema relacional, se ejecuta en el medio o en la parte posterior del paquete en comparación con los sistemas que admiten RDF de forma más nativa.

Por supuesto, los sistemas RDF probablemente serían aplastados por Oracle si estuvieran haciendo consultas SQL sobre datos relacionales. Pero ese es el punto, eliges la herramienta adecuada para la aplicación que deseas construir.

Así que si estás pensando en construir una aplicación web semántica, o simplemente tratando de familiarizarte con el área, te recomiendo que vayas con una tienda triple dedicada.

No profundizaré en el razonamiento ni en la respuesta a consultas en tiendas triples, ya que es otra discusión más, pero es otra distinción importante entre sistemas relacionales y almacenes triples que hacen el razonamiento.

7

Algunos triplestores (Virtuoso, Jena SDB) se basan en bases de datos relacionales y simplemente proporcionan una interfaz RDF/SPARQL. Así que para reformular la pregunta un poco, los triplestores construidos desde cero son más rentables que aquellos que no lo son - @ steve-harris definitivamente sabe la respuesta a eso;) pero apuesto a que sí.

En segundo lugar, ¿qué funciones tienen los almacenes triples que los RDBMS no tienen? La respuesta simple es soporte para SPARQL, RDF, OWL, etc. (es decir, la pila de Tecnología de la Web Semántica) y para que sea una pelea justa, es mejor definir el valor de SPARQL basado en SPARQL 1.1 (tiene considerablemente más funciones que la 1.0) . Esto proporciona soporte para federación (tan genial), expresiones de ruta de propiedad y regímenes de vinculación junto con un conjunto de estándares de protocolos de actualización, protocolos de administración de gráficos (que SPARQL 1.0 no tenía y que le faltaba). También @ steve-harris señala que las transacciones no son parte del estándar (lata de gusanos) aunque muchos proveedores proporcionan mecanismos no estandarizados para las transacciones (Virtuoso admite la agrupación y administración de conexiones compatibles con JDBC e Hibernate junto con todas las funciones transaccionales de Hibernate)

El gran inconveniente en mi mente es que no hay muchos triplestores compatibles con todos los SPARQL 1.1 (ya que todavía no está en la recomendación) y aquí es donde radican los verdaderos beneficios.

Habiendo dicho eso, soy y siempre he sido un defensor de sustituir RDBMS con triplestores y plataformas que entrego corren completamente fuera de triplestores (Volkswagen en mi último papel fue un ejemplo de esto), despreciando la necesidad de RDBMS. Una ventaja adicional es que el mapeo de Object to RDF es más flexible y proporciona más opciones y flexibilidad que ORM tradicional (también conocido como poner una clavija cuadrada en un agujero redondo).

+1

SPARQL 1.1 está en la recomendación ahora, AFAIK. –

0

También puede usar una base de datos pero use RDF como un formato de intercambio de datos que es muy flexible.

Cuestiones relacionadas