Почему TripleStore не реализован как Native Graph Store, как Property-Graph Store?
Хранилище на основе 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?
2 ответа
@ Майкл, я рад, что ты вмешался, поскольку ты определенно знаешь больше, чем я об этом:) . На данный момент я нахожусь в учебном путешествии. По вашей просьбе вот один из документов, которые вдохновили меня на понимание:
arxiv.org/abs/1801.02911 (SPARQL-запрос графов свойств с использованием обходов Gremlin)
Я цитирую их
"Мы представляем всестороннюю эмпирическую оценку Gremlinator и демонстрируем его обоснованность и применимость, выполняя запросы SPARQL над ведущими хранилищами графиков Neo4J, Sparksee и Apache TinkerGraph и сравнивая производительность с хранилищами RDF Virtuoso, 4Store и JenaTDB. Наша оценка демонстрирует существенный выигрыш в производительности, полученный аналогами Gremlin запросов SPARQL, особенно для запросов в форме звезды и сложных запросов."
Однако они объясняют, что все зависит как-то от типа запросов.
Или, в качестве другого ответа, указав, что при переполнении стека сравнение реляционных баз данных и графовых баз данных также поможет понять проблему между множеством и путем. Насколько я понимаю, TripleStore работает и с Set. Это, как говорится, я определенно не знаю всех методов оптимизации, реализованных в TripleStore в последнее время, и я видел несколько статей, объясняющих методы для существенного сокращения операции объединения набора.
На раздаче больше мужественных чувств. Например, выполнение операции объединения в распределенном режиме звучит для меня очень, но очень дорого. У меня нет документов, и мое исследование не является исчерпывающим. Но из того, что у меня есть красный, и мне придется копаться в моем Evernote:), чтобы поддержать его, это фундаментальная проблема с дистрибуцией. Автоматическое интеллектуальное разбиение здесь, кажется, не помогает облегчить проблему.
@ Майкл, это очень, но очень сложная тема. Я определенно нахожусь в пути, и именно поэтому я помогаю себе с помощью stackru, чтобы направлять свои исследования. Вы, вероятно, имеете представление о том, почему. Так что не стесняйтесь указатели действительно.
При этом я не говорю, что есть проблема с 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.
Во-первых, я хотел бы видеть ссылки, подтверждающие ваше утверждение о том, что системы на основе RDF по своей природе менее эффективны, чем системы с графами свойств, потому что, честно говоря, это бессмысленное утверждение. Кроме того, были распространены, и я предполагаю, что вы имеете в виду масштабирование, хранилища RDF, поэтому утверждение о том, что они не могут быть распределены, просто неверно.
Модель Property Graph и Gremlin легко могут быть реализованы поверх системы на основе RDF. Насколько мне известно, это было сделано дважды, и в одной из этих реализаций обоснование поддерживалось на уровне Gremlin/Property Graph. Таким образом, вам не нужно быть системой на основе графа свойств для поддержки этой модели. Существует множество причин, по которым системы, RDF и Property Graph, делают конкретные варианты реализации, от хранилища до исполнения и далее, и некоторые из них руководствуются "нативной" моделью, технологией, выбранной для реализации, и, возможно, самое главное, варианты использования системы и проблемы, которые она стремится решить.
Кроме того, неясно, что вы рекомендуете авторам систем на основе RDF; Вы предполагаете, что горизонтальное масштабирование выгодно? Вы утверждаете, что ваши предпочтения в отношении модели Графа пропити следует воспринимать как евангелие, чтобы системы на основе RDF отказывались и переключали модели данных? Хотите ли вы модифицировать системы Property Graph RDFS?
Наконец, к первоначальному вопросу, который вы задали, я думаю, что он у вас задом наперед; модель графа свойств представляет собой гибридную модель графа, смешивающую элементы графа и модели ключ-значение, тогда как модель RDF представляет собой чистую, т. е. собственную модель графа. Гремлин примет модель RDF, хотя и с синтаксическим сахаром вокруг того, что в мире RDF называется реификацией, но для всех остальных - краевыми свойствами. Так что в мире, где ваш образец модели графа свойств отказывается от упомянутой модели, я не уверен, что вам еще сказать, кроме того, что вы должны сделать немного больше базовых исследований.