Для PostgreSQL предложено дополнение AGE (AgensGraph-Extension) с реализацией языка запросов openCypher для манипуляций с наборами связанных между собой иерархических данных, образующих граф. Вместо столбцов и строк графо-ориентированые БД используют структуру, похожую на сеть - задаются узлы, их свойства и отношения между узлами. AGE распространяется под лицензией Apache 2.0, передан компанией Bitnine под покровительство Фонда Apache и в настоящее время помещён в инкубатор Apache...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53337
Не нужно, как и электрон.В 70-х прекрасно без этих ваших графовых БД обходились.
А раньше люди вообще только дубинкой обходились.
> В 70-х прекрасно без этих ваших графовых БД обходились.В 70-х и без вас, дорогой Аноним, прекрасно обходились.
Ээээ... а насколько эффективно организовано хранение графовых данных и их обработка в реляционной БД, по сравнению с нативными графовыми БД?
Вот пишут: "AgensGraph is fastest graph database all around the world."
(с) https://www.startupranking.com/bitnine
на заборах тоже пишут...
Как довольный юзер neo4j скажу, либо там от слона ничего не осталось, либо они брешут как троцкие.
Лень по ссылкам ходить, но полагаю, что функционала там как во всех сишных поделках, на 5% от neo4j. Когда сделаете близко к 100%, тогда и квакайте про fastest around the world :)))
> Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQLя предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются по разному. (src лень изучать)
Сам себе отвечу.
Там на их сайте вроде бы основной фишкой преподносится то, что в ПГ хранятся некие данные об объектах (в традицонной для реляционной БД форме) и в дополнение к этому некая граф-структура, отражающая связи между этими объектами. То есть, это именно дополнение к ПГ для работы с неким специфическим типом данных, и её не совсем уместно сравнивать с графовыми БД.
Можно ссылку? Как понял я основная фича это то, что можно одновременно использовать реляционные и графовые схемы.
Прямо на стартовой (https://bitnine.net/):
> In graph database technology, relationships are as important as data itself and when you are handling hyper-connected data the relationships between entities contain significant context, which is lost in the process of normalization using a conventional databases. Agensgraph is designed to deal with the complexity of the relationships and to provide an intuitive and dynamic insight that empowers executable and useful data intelligence.
> AgensGraph is the only multi-model graph database integrated with a relational database
https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem...
Postgres получился неплохой метадвижок для создание специализированных бд в виде расширений.
Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?
Sql головного мозга какой-то
Это все равно что у отвертки из рем набора машины вместо ручки будет руль
Для тех случаев, когда есть и классически-реляционные, и графовые данные, и хочется с ними работать атомарно, в рамках транзакций - очень удобно должно быть.
Это ты бы так сделал. А нормальные люди используют низкоуровневый движок хранения, который есть в реляционной СУБД, и создают свою обёртку, вместо SQL-ной.
Ну и конечно, SQL головного мозга тебе не грозит, этой болезни у тебя просто "угнездиться негде". ©
Если уже есть Постгрес на проекте лучше уж пихать все в неё чем поднимать новую базу и городить все туда.
> Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой.
Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке.
Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида:struct Vertex {
name: String,
edge: Vec<Edge*>,
}struct Edge {
left: *Vertex,
right: *Vertex,
}не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.
Графовое расширение - крайне недостающая вещь в PostgreSQL, чтобы эта БД была по настоящему универсальным средством построения систем. С JSONB (средство хранения некого куска данных без схемы) и графами она покроет все потребности большинства сервисов. Базу это не убьёт, но улучшит. А когда доведут до ума FDW и шардинг, это будет атомная бомба в мире СУБД.
Сейчас БД активно идут в универсальность.
Да, все, кому это надо в работе, люто ждут :) Когда-то давно игрался с agens, вроде работает, но 0.х и малоизвестность не тянет это в прод. Кажется, некие Fujitsu/etc, один из корпоративных контрибьюторов pg, где-то заикались, что у них в roadmap добавить graph model в pg. Если все это правда, то могут скоро много разных graph model impl повалить в pg. Юношеский каммент: "может надо обратиться к Oleg Bartunov, может также хорошо запилят graph model, как у них вышло с JSONB? Там у людей вся жизнь с pg в обнимку."
>может также хорошо запилят graph model, как у них вышло с JSONBсколько платят за коммент? ну не скажет такого человек, который хоть раз щупал монгу.
с чем сравниваешь-то?!
>>может также хорошо запилят graph model, как у них вышло с JSONB
> сколько платят за коммент? ну не скажет такого человек, который хоть раз
> щупал монгу.
> с чем сравниваешь-то?!Я, наверное, не уловил основную мотивацию вопроса, но попробую ответить, как смогу.
Монгу, конечно же, пробовали и в проде топтали, но бывают такие задачи/проекты, где очень удобно/хорошо ложится все в один multi-model storage как тот же pg, где можно использовать прелести document oriented (JSONB), различные индексы, уже проверенные временем подходы к работе с SQL (т.е. народ это уже умеет делать, не надо новый *QL учить, плюс готовые решения around), тут же и готовые решения под time series data (тигр tsdb) и т.п.
Но я это пишу не сцелью "уговорить" использовать базу Х для хранения данных или забивания гвоздей везде и всегда. Это просто пример, ибо не везде solution X стоит слепо лепить, или даже если очень хочется и можется, не везде оно хорошо зайдет.
Как-то так.
Вы немножко путаете понятия.
То что кто-то понимает английский язык не означает, что он англичанин. Даже если это его родной язык.
Так же и с Бд - язык общения с пользователем не обязан быть единственным и определять ее внутреннюю структуру.
Взлетит и высоко если в AWS запихают.
>графо-ориентированые БД используют структуру, похожую на сетьКлассное объяснение, с учетом того, что сеть это частный случай графа. :)