Быстрый график, идущий по RDF-подобным данным: тройной магазин или база данных графа?

Question

У меня есть структура данных графа типа RDF, то есть состоящая из узлов (сущностей), которые связаны ребрами (свойствами, отношениями) разных типов. Пользователь будет выбирать узел в этом графе (миллионы узлов, сотни миллионов краев), и я ищу быстрый способ отобразить «близость» выбранного узла (то есть один или два уровня узлов, из которых это путь через набор возможных отношений к первоначально выбранному узлу).

Я провел некоторое исследование и наткнулся на специализированные трехмерные магазины RDF и более общие графические базы данных, такие как neo4j и allegro. Тогда есть также продукты промежуточного уровня, такие как jena и кунжут.

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

Александр

Answer 1

я рекомендовал бы один из магазинов RDF (Jena, кунжутное, 4store, Виртуоз, OWLim, Oracle и т.д.). Затем вы можете просто изучить запрос SPARQL для своего решения и попробовать его в различных системах без необходимости кодирования для разных API.

Существует несколько подходов, которые вы можете использовать, самый простой - это запрос UNION с разными путями, вы можете использовать переменную для краевого URI и добавить FILTER, чтобы ограничить ее только теми, которые вам интересны

Answer 2

Чтобы уточнить, я бы не стал классифицировать Йену и/или Сезам как промежуточное ПО. У них есть собственное хранилище и индексы.

У Jena есть TDB, который использует индексы B + Tree. В частности, для графика по умолчанию у вас есть три индекса: SPO, POS и OSP.

В вашем случае индекс SPO будет использоваться для предоставления вам всех троек для данного объекта. Если вам нужны два уровня в глубину, вам нужно будет коснуться индекса несколько раз: по одному для начального объекта и по одному для каждого объекта, скорректированного на ваш объект.

TDB использует файлы с отображением памяти для кэширования ваших индексов, поэтому, если у вас достаточно ОЗУ, это не должно быть проблемой.

Что вы хотите сделать, очень близко к тому, что люди из сообщества RDF использовали для звонка Concise Bounded Description (CBD), однако, если вы хотите получить два или более уровня глубины, вам нужно будет реализовать это самостоятельно. Язык запросов SPARQL дает вам DESCRIBE, который вы можете использовать (но это один уровень глубины).

И последнее, но не менее важное: вы говорите, что у вас есть структура данных графа типа RDF, но это не RDF. По этой причине вы должны либо преобразовать свои данные в RDF, либо отказаться от идеи использования трехмерного хранилища, поскольку они предназначены для загрузки и управления данными RDF. Даже если вы можете использовать только часть слоя хранения и индексирования для создания и использования собственных пользовательских индексов.

Лучше всего сделать эксперимент с вашими данными и сравнить, как различные решения работают с вашим прецедентом.