Graph Databases vs Triple Stores - когда использовать какие?

Я знаю, что есть аналогичные вопросы вокруг 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)

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

  • графовые базы данных: когда у вас есть известные, статические соединения
  • тройные магазины: когда у вас есть свободно подключенные узлы и часто ищут новые соединения

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

иными словами:

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

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

36
graph-databases neo4j orientdb sparql triplestore

1 ответов

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

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

<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 связь между двумя узлами, причем каждый узел имеет свойство. В RDF вы будете стремиться идентифицировать вещи по URI, в neo4j это объект базы данных, который получает идентификатор базы данных автоматически. Вот что я имею в виду о разнице между более атомарным/примитивным магазином (тройными магазинами) и более богатым графом свойств.

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

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

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

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

54