Comments 20
https://age.apache.org/ настройка PostgreSQL для выполенния графовых запросов. В активной разработке.
есть ещё AgensGraph https://github.com/bitnine-oss/agensgraph тоже основана на PostgreSQL
вот бы сравнить предложенную реализацию с чем-то не требующим рекурсивных запросов, например: https://en.wikipedia.org/wiki/Nested_set_model
Чем этот способ хранения ориентированных графов отличается от таблицы смежности? https://habr.com/ru/post/537062/
Ничего себе какое открытие! Оказывается (!!!) в любой реляционной базе где есть рекурсивные запросы можно работать с графом!
Давайте усложним задачу - возьмём миллионов 500 вершин и миллиарда три связей и решим задачу попроще вроде поиска ближайшего окружения по набору признаков от заданной вершины с небольшой конкурентной нагрузкой сессий так в 20 :)
Кстати, а как такое решать? Не в постгресе, а вообще?
В специализированных движках (графовые субд) конечно
Работал на сервере Neo4j 4.4 (он-прем) со 100 ГБ ОЗУ, там было около 25 миллионов вершин и около 100 миллионов рёбер в БД.
Шуршал на он на оценку "удовлетворительно" - достаточно быстро для прода, но не поражал воображение и вообще не было запаса прочности для масштабирования.
Чтобы переварить миллиарды рёбер на Neo4j, нужен мини-ЦОД, наверно)
И PG на том же железе работал бы не сильно хуже
100 Гб конечно не о чем на самом деле и есть разница между 25м вершин и 500 М :)
ну и Neo не самое лучшее решение.
представьте что у вас будет стоять задача например достроения графа в онлайн режиме с интеграцией с системой принятия решений в реальном времени. Никак вы ее на рсубд не решите за вменяемую стоимость и sla.
EdgeDB же.
Parent/child это только частный случай графа. Как правило, для графовых задач узлы (ребра) могут быть объектами разного класса и иметь разные наборы свойств. Это, конечно, можно уложить в реляционную модель, но это будет нецелевое использование реляционной СУБД. Для таких вещей есть более подходящие модели хранения (и свои QL).
Тот случай, когда комментарии намного релевантнее саиой статьи, уж извините. Ничего из изложенного не "графовое" в каком то уникальном виде, т.е. применимо к плюс-минус любой из нормальных СУБД - чистый sql.
А вот ссылки коллег интересные.
data VARCHAR(255)
Сразу, varchar(n) vs text: https://ru-postgres.livejournal.com/65930.html
И, естетсвенно, официальная вики по постгресу: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_varchar.28n.29_by_default
CREATE TABLE edges ( previous_node INTEGER REFERENCES nodes(id), next_node INTEGER REFERENCES nodes(id), PRIMARY KEY (previous_node, next_node) );
В те времена далёкие, теперь уже былинные (с) В.С.Высоцкий (почти), к узлу графа могло подключаться существенно больше рёбер, нежели предыдущее и следующее. А в неориентированном графе понятия "предыдущее" и "следующее" вообще смысла не имеют.
Postgres: графовая база данных, о которой вы не подозревали