График Базы данных против Triple Store - когда использовать какой?

Я знаю, что в Stackoverflow есть похожие вопросы, но я не чувствую, что они отвечают на следующее.

График Базы данных в моем понимании хранят данные, следуя главным образом этой схеме:

Table/Collection 1: store nodes with UID
Table/Collection 2: store relations referencing nodes via UID

Это позволяет хранить произвольные типы графиков. Теперь, поскольку я понимаю, что в трех магазинах нет ничего, кроме троек:

Triple/Collection 1: store triples (2 nodes, 1 relation)

Теперь я бы увидел следующее различие в отношении случаев использования:

График Базы данных: когда вы знаете, статические соединения
Тройные магазины: когда у вас слабо связаны узлы и вы часто ищете новые соединения

Меня смущает тот факт, что люди, похоже, не обсуждают, какой из них следует использовать в соответствии с этими критериями. Большинство статей, которые я нахожу, говорят о таких аргументах, как скорость или совместимость. Но разве это не самый важный момент?

Поверните в другую сторону:

Представьте, что у вас есть четко связанный, определенный пользователем график. Почему бы вам захотеть сохранить это только в тройках, потеряв всю информацию о связях? Или нужно реализовать некоторые пользовательские решения, хранящие идентификаторы в тройной subject.
Представьте, что вы свободно собирали узлы, которые хотите запросить для неизвестных отношений, используя SPARQL. Графические базы данных поддерживают это. Но для этого им нужно построить еще один индекс, который я предполагаю и будет медленнее?

EDIT: Я вижу, что "потеря информации о связях" - это неправильный способ ее поместить. Если вы сделаете так, как показано в принятом ответе, и вставьте несколько троек для 2 узлов + 1 отношение, вы сохраните всю информацию и, в частности, информацию о том, какие точные узлы подключены.

Ответ 1

Основное различие между базами данных графов и тройными магазинами заключается в том, как они моделируют график. В тройном хранилище (или квадранте) данные имеют тенденцию быть очень атомарными. Я имею в виду, что "узлы" в графе имеют тенденцию быть примитивными типами данных, такими как string, integer, date и т.д. Связи связывают примитивы вместе, и поэтому "единица дискурса" в тройном магазине является тройной, а не a node или отношения, как правило.

В отличие от этого другие базы данных графов часто называют "хранилищами свойств", поскольку узлы представляют собой контейнеры данных, которые соответствуют объектам в домене. A node выступает за объект и имеет свойства; они действуют как богатые типы данных, заданные графическими модельерами, а не только примитивные типы данных. В этих графовых базах данных узлы и отношения являются "единицей дискурса".

Скажем, у меня есть человек по имени "Боб", который знает "Сьюзан". В RDF это будет примерно так:

<http://example.org/person/1> :hasName "Bob".
<http://example.org/person/1> foaf:knows <http://example.org/person/2>.
<http://example.org/person/2> :hasName "Susan".

В такой базе данных, как neo4j, это будет следующим:

(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})

Обратите внимание, что в RDF это 3 отношения, но только одно из этих отношений фактически выражает семантику между двумя объектами. Другие два отношения - это просто отслеживание свойств одного объекта более высокого уровня (человека). В neo4j это отношение 1 между двумя узлами, причем каждый node имеет свойство. В RDF вы будете склонны идентифицировать вещи по URI, в neo4j это объект базы данных, который автоматически получает идентификатор базы данных. Это то, что я имею в виду о различии между более атомарным/примитивным хранилищем (тройными хранилищами) и более богатым графиком свойств.

RDF и тройные магазины в основном построены для тех архитектурных задач, с которыми вы столкнулись с семантической сетью. Например, пространство имен XML встроено в архитектурное предположение, что вы будете смешивать и сопоставлять использование многих разных словарей и пространств имен. (Это право есть очень "семантическая паутина" ). Таким образом, в SPARQL и RDF вы обычно обычно используете пространства имен xsd, rdf и rdfs и, возможно, также owl, skos и многие другие. SPARQL и RDF/RDFS также имеют множество перехватов и функций, которые явно позволяют сделать такие вещи, как онтологический вывод. Вы будете склонны идентифицировать вещи с URI как способ "namespacing your identifier", а также потому, что некоторые люди могут захотеть удалить ссылку на URI... опять же предположение представляет собой широкое разделение данных между многими участниками.

Хранилища свойств по контрасту привязаны к различным вариантам использования, например гибкому моделированию данных в пределах одной модели/пространства имен, сопоставлениям между объектами и графиками для сохранения корпоративных приложений, быстрой эволюционируемости и т.д. Вы будете склонны идентифицировать вещи с помощью своей собственной схемы (или внутреннего идентификатора базы данных). Целое число с автоматическим добавлением может быть не лучшей формой идентификатора для любого случайного потребителя в Интернете (и они, конечно же, не могут быть удалены как URL-адреса), но они могут не быть вашей первой мыслью для внутреннего приложения компании.

Итак, что лучше? Чем больше атомного трехмерного хранилища, или графа свойств? Нужно ли смешивать и сопоставлять много разных словарей в одном запросе или модели данных? Вам нужно создать онтологию OWL или сделать вывод? Нужно ли сериализовать кучу java-объектов в памяти в базу данных? Вам нужно быстро пройтись по длинным дорожкам? Эти типы вопросов будут определять ваш выбор.

Графы - это графики, оба из них - графики, и поэтому я не думаю, что существует много различий в терминах того, что они могут представлять, или как вы думаете о проблеме в терминах графика. Различия сводятся к архитектуре под капотом, и какие варианты использования вы считаете нужными вам. Я не скажу вам, что один лучше другого, но разумно выбирайте.

Ответ 2

(в ответ на комментарии к этому ответу: fooobar.com/info/171332/...)

Когда определено производственное правило owl: inverseOf, триплекс обратного свойства выводится рассуждателем либо при добавлении или обновлении магазина, либо при выборе из магазина. Это "материализованное отношение"

Schema.org - словарь RDFS - определяет, например, https://schema.org/isPartOf как обратное свойство hasPart. Если указаны оба, нет необходимости запускать другой запрос графового шаблона для обхода направленного отношения в другом направлении. (: book1 схема: hasPart? o), (? схема: isPartOf: book1), (? схема: hasPart: chapter2)

Безусловно, можно использовать RDFS и OWL для описания схемы и для графов свойств neo4j; но нет никаких причин, например, выводить обратные свойства или проверять схему.

Есть ли RDF-граф, который neo4j не может сохранить? В RDF есть типы данных и языки для объектов: вам нужно изменить свойства, в которых указаны типы данных и/или языки (и вы бы заново внедрили четко определенную семантику)

Может ли каждый граф neo4j быть представлен с помощью RDF? Да.

RDF - это представление для графиков, для которых существует очень много реализаций хранилища, оптимизированных для различных вариантов использования, таких как производительность вставки и запросов.

Сравнение neo4j с конкретным триплетным складом (с поддержкой рассуждений) может быть более полезным сравнением, учитывая, что все графики neo4j могут быть выражены как RDF.