Базы данных графов и триплесторы RDF: хранение данных графов в python
Мне нужно разработать графическую базу данных в python (мне бы понравилось, если кто-нибудь может присоединиться ко мне в разработке. У меня уже есть немного кода, но я бы с удовольствием обсудил его).
Я провел исследование в интернете. в Java, СУБД Neo4j является кандидатом, но я не смог найти ничего о фактическом дисковом хранилище. В python есть много графовые модели данных (см. Это предложение pre-PEP, но ни один из них не удовлетворяет мою потребность хранить и извлекать из диск.
Я знаю о triplestores, однако. triplestores-это в основном базы данных RDF, поэтому модель данных графика может быть отображена в RDF и сохранена, но я обычно обеспокоен (в основном из-за отсутствия опыта) этим решением. Один из примеров -кунжутное. Дело в том, что в любом случае вам нужно преобразовать из представления графа в памяти в представление RDF и viceversa в любом случае, если клиентский код не хочет взломать документ RDF напрямую, что в основном едва ли. Это было бы похоже на обработку кортежей БД напрямую, а не на создание объекта.
каково современное состояние для хранения и извлечения (а-ля СУБД) графовых данных в python, на данный момент? Имеет ли смысл начать разработку реализации, надеюсь, с помощью кого-то, кто заинтересован в ней, и в сотрудничестве с авторами предложений для Graph API PEP ? Обратите внимание, что это будет частью моей работы в течение следующих месяцев, поэтому мой вклад к этому возможному проекту довольно серьезно;)
редактировать: нашли тоже directededge, но это, кажется, коммерческий продукт
7 ответов
я использовал как Джена, который является Java framework, и Allegrograph (Lisp, Java, привязки Python). У йены есть сестринские проекты для хранения графических данных и существует долгое, долгое время. Allegrograph довольно хорош и имеет бесплатную версию, я думаю, я бы предложил эту причину легко установить, бесплатно, быстро, и вы могли бы быть и идти в кратчайшие сроки. Сила, которую вы получите от изучения немного RDF и SPARQL, вполне может стоить вашего времени. Если вы знайте SQL уже тогда, когда вы отлично начинаете. Возможность запроса вашего графика с помощью SPARQL даст вам некоторые большие преимущества. Сериализация в тройки RDF будет простой, а некоторые форматы файлов очень просты ( например, NT ). Приведу пример. Допустим, у вас есть следующие идентификаторы узла-ребра-узла графика:
1 <- 2 -> 3 3 <- 4 -> 5
они уже являются формой объекта предиката субъекта, поэтому просто шлепните по нему некоторые обозначения URI, загрузите его в тройное хранилище и запросите по желанию через SPARQL. Вот он в формате NT:
<http://mycompany.com#1> <http://mycompany.com#2> <http://mycompany.com#3> . <http://mycompany.com#3> <http://mycompany.com#4> <http://mycompany.com#5> .
Теперь запрос для всех узлов два перехода от узла 1:
SELECT ?node WHERE { <http://mycompany.com#1> ?p1 ?o1 . ?o1 ?p2 ?node . }
Это, конечно, даст http://mycompany.com#5>.
другой кандидат будет Mulgara, написано на чистом Java. Поскольку вы, кажется, больше заинтересованы в Python, хотя я думаю, что вы должны сначала взглянуть на Allegrograph.
Я думаю, что решение действительно зависит от того, что именно вы хотите сделать с графиком, как только вам удастся сохранить его на диске/в базе данных, и это немного неясно в вашем вопросе. Тем не менее, несколько вещей, которые вы, возможно, захотите рассмотреть:
- Если вы просто хотите сохранить график без использования каких-либо функций или свойств, которые можно ожидать от решения СУБД (например, ACID), как насчет просто маринования объектов в плоский файл? Очень рудиментарно, но, как я уже сказал, зависит именно от того, чего вы хотите достичь.
- ЗОДБ - это объектная база данных для Python (откат от проекта Zope, я думаю). Я не могу сказать, что у меня был большой опыт работы в высокопроизводительной среде, но несколько ограничений позволяют хранить объекты Python изначально.
- Если вы хотите преследовать RDF, есть RDF Алхимия проект, который может помочь облегчить некоторые из ваших проблем преобразование из вашего графика в структуры RDF, и я думаю, что Сезам является частью его стека.
есть некоторые другие инструменты настойчивость подробно на сайте python, который может представлять интерес, однако я потратил довольно много времени на изучение этой области в прошлом году, и в конечном итоге я обнаружил, что не было собственного решения Python, которое отвечало моим требованиям.
наибольший успех у меня был с использованием MySQL с пользовательским ORM, и я опубликовал пару соответствующих ссылок в ответ для этот вопрос. Кроме того, если вы хотите внести свой вклад в проект РСУБД, когда я говорил с кем-то из открытого запроса о механизм хранения графиков для MySQL казалось, они заинтересованы в активном участии в своем проекте.
Извините, я не могу дать более окончательного ответа, но я не думаю, что он есть... Если вы начнете разрабатывать свою собственную реализацию, мне было бы интересно быть в курсе того, как вы продвигаетесь.
Что касается Neo4j, вы заметили существующий Python-привязки? Что касается дискового хранилища, взгляните на этой теме на рассылки.
для graphdbs в Python,Система Управления Базами Данных Hypergraph проект был недавно запущен на SourceForge по Морис Линг.
RDFLib-это библиотека python, которую вы можете использовать. Используя пример harschware:
создать test.nt
файл, как показано ниже:
<http://mycompany.com#1> <http://mycompany.com#2> <http://mycompany.com#3> .
<http://mycompany.com#3> <http://mycompany.com#4> <http://mycompany.com#5> .
для запроса всех узлов два перехода от узла 1 в RDFLib:
from rdflib import Graph
g = Graph()
g.parse("test.nt", format="nt")
qres = g.query(
"""SELECT ?node
WHERE {
<http://mycompany.com#1> ?p1 ?o1 .
?o1 ?p2 ?node .
}"""
)
for row in qres:
print(node)
должен вернуть ответ <http://mycompany.com#5>
.