Почему TripleStore не реализован как Native Graph Store, как Property-Graph Store?

Question

Хранилище на основе Sparql или, иначе говоря, TripleStore, как известно, менее эффективно, чем хранилище графа свойств, в дополнение к невозможности его распределения при сохранении производительности в виде графа свойств.

Я понимаю, что на карту поставлено много вещей, таких как логические выводы, а что нет.Откладывая распространение и вывод в сторону, где мы могли бы ограничиться RDFS, которая может быть полностью перехвачена через SPARQL, мне интересно, почему это так?

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

Я предполагаю, что если sparql может быть преобразован в эффективный обход шагов, и данные сохраняются как граф свойств, например, как janusGraph https://docs.janusgraph.org/latest/data-model.html, топроблема производительности будет решена при сохранении некоторого вывода, такого как RDFS.

При этом, Sparql, конечно, не является полным по Тьюрингу, но, по крайней мере, для того, что он делает, он будет делать это быстро и, возможно, также в масштабе.На мой взгляд, цель состоит не в том, чтобы конкурировать, а в том, чтобы использовать SPARQL для простоты использования и использования языка обхода, такого как gremlin, для вещей, которые действительно в этом нуждаются, например OLAP.

Есть ли какой-либо проект в этом направлении, рассмотрел ли Apache jena что-нибудь из этого?

Я видел, что Graql of Grakn, кажется, использует эту дорогу по причине, которую я объясняю выше, и, следовательно, что останавливает сообщество TripleStore?

Answer 1

@ Майкл, я рад, что вы вступили, поскольку вы определенно знаете больше, чем я об этом :).На данный момент я нахожусь в учебном путешествии.По вашей просьбе вот один из документов, которые вдохновили меня на понимание:

arxiv.org / abs / 1801.02911 (SPARQL-запрос графов свойств с использованием обходов Gremlin)

Iпроцитируйте их

"Мы представляем всестороннюю эмпирическую оценку Gremlinator и демонстрируем его обоснованность и применимость, выполняя запросы SPARQL над ведущими хранилищами графиков Neo4J, Sparksee и Apache TinkerGraph и сравниваем производительность с RDF.хранит Virtuoso, 4Store и JenaTDB. Наша оценка демонстрирует существенный выигрыш в производительности, полученный аналогами Gremlin запросов SPARQL, особенно для запросов в форме звезды и сложных. "

Они объясняют, однако, что все зависит как-тоо типе запросов.

Или в качестве другого ответа укажите, что при переполнении стека Сравнение реляционных баз данных и графовых баз данных также поможет понять проблему между множеством и путем.Насколько я понимаю, TripleStore работает и с Set.Это, как говорится, я определенно не знаю всех методов оптимизации, реализованных в TripleStore в последнее время, и я видел несколько статей, объясняющих методы для существенного сокращения операции объединения набора.

На раздаче больше мужественных чувств.Например, выполнение операции объединения в распределенном режиме звучит для меня очень, но очень дорого.У меня нет документов, и мое исследование не является исчерпывающим.Но из того, что у меня есть красный, и мне придется копаться в моем Evernote :), чтобы поддержать его, это фундаментальная проблема с дистрибуцией.Автоматическое интеллектуальное разбиение здесь, кажется, не помогает облегчить проблему.

@ Майкл, это очень, но очень сложный вопрос.Я определенно нахожусь в пути, и именно поэтому я помогаю себе с помощью stackoverflow, чтобы направлять свои исследования.Вы, вероятно, имеете представление о том, почему.Так что не стесняйтесь указатели действительно.

При этом я не говорю, что есть проблема с RDF и что Property-Graph лучше.Я говорю, что так или иначе, когда дело доходит до обхода графа, есть способы реализовать бэкэнд, который делает это быстрым.Модель данных здесь не проблема, проблема заключается в структуре данных, используемой для поддержки обхода.Второе, что я хочу сказать, это то, что, по-видимому, выбор языка запросов влияет на то, как выполняется «обход» и, следовательно, на структуру данных, которая используется для поддержки модели данных.

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

Короче говоря, мой вопрос сводится к тому, возможно ли, чтобы хранилища RDF были поддержаны так называемым Native Graph Storage, а затем реализовывать Sparql в терминах шагов обхода, а не объединять наборы в соответствии с его алгеброй?Разве это не делает вещи немного быстрее.Похоже, что это в некотором роде подход, принятый https://github.com/graknlabs/grakn, который в первую очередь поддерживается janusGraph для хранилища, подобного графу.Хотя это не RDF, Graql - это та же идея, что и RDFS ++ + Sparql.Они утверждают, что просто делают это лучше, на что у меня есть оговорка, но это не основной вопрос этой темы.Суть в том, что они поддерживают представление знаний путем поиска информации (обход пути) и сопутствующего подхода к хранению, который отстаивал Property-Graph.Позвольте мне прояснить это, я не говорю, что собственное хранилище графа является свойством графа свойств.Я просто думаю, что подход к хранилищу оптимизирован для хранения структуры графа, когда поиск информации включает в себя (путь) обход: https://docs.janusgraph.org/latest/data-model.html.

Answer 2

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

Модель графа свойств и Gremlin,может быть легко реализовано поверх системы на основе RDF.Насколько мне известно, это было сделано дважды, и в одной из этих реализаций обоснование поддерживалось на уровне Gremlin / Property Graph.Таким образом, вам не нужно быть системой на основе графа свойств для поддержки этой модели.Существует множество причин, по которым системы, RDF и Property Graph, делают конкретные варианты реализации, от хранилища до исполнения и далее, и некоторые из них руководствуются «нативной» моделью, технологией, выбранной для реализации, и, возможно, самое главное,варианты использования системы и проблемы, которые она стремится решить.

Кроме того, неясно, что вы рекомендуете авторам систем на основе RDF;Вы предполагаете, что горизонтальное масштабирование выгодно?Вы утверждаете, что ваши предпочтения в отношении модели Графа пропити следует воспринимать как евангелие, чтобы системы на основе RDF отказывались и переключали модели данных?Вы хотите, чтобы системы графов свойств модифицировали RDFS?

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