The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа

11.07.2020 11:35

Для PostgreSQL предложено дополнение AGE (AgensGraph-Extension) с реализацией языка запросов openCypher для манипуляций с наборами связанных между собой иерархических данных, образующих граф. Вместо столбцов и строк графо-ориентированые БД используют структуру, похожую на сеть - задаются узлы, их свойства и отношения между узлами. AGE распространяется под лицензией Apache 2.0, передан компанией Bitnine под покровительство Фонда Apache и в настоящее время помещён в инкубатор Apache.

Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQL. Ключевым отличием является реализация AGE в форме универсального дополнения, работающего в виде надстройки над штатными выпусками PostgreSQL. Опубликованный на днях выпуск Apache AGE 0.2.0 поддерживает работу с PostgreSQL 11.

В текущем состоянии AGE поддерживает такие возможности языка запросов Cypher, как применение выражения "CREATE" для определения узлов и связей, выражение "MATCH" для поиска данных в графе по заданным условиям (WHERE), в указанном порядке (ORDER BY) и с выставленными ограничениями (SKIP, LIMIT). Результирующий набор данных, возвращаемый запросом, определяется при помощи выражения "RETURN". Для объединения нескольких запросов в цепочку доступно выражение "WITH".

Возможно создание мультимодельных БД, сочетающих модели иерархического хранения свойств в форме графа, реляционную модель и модель хранения документов в формате JSON. Поддерживается выполнение интегрированных запросов, включающих элементы языков SQL и Cypher. Доступно создание индексов для свойств вершин и рёбер графа. Для использования предложен расширенный набор типов Agtype, включающий типы для рёбер, вершин и путей в графе. Агрегатные выражения пока не реализованы. Среди доступных специализированных функций: id, start_id, end_id, type, properties, head, last, length, size, startNode, endNode, timestamp, toBoolean, toFloat, toInteger и coalesce.

  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Первый стабильный выпуск графо-ориентированной СУБД Nebula Graph
  3. OpenNews: Новая версия СУБД ArangoDB 3.6
  4. OpenNews: СУБД CockroachDB переходит на несвободную лицензию
  5. OpenNews: Выпуск СУБД OrientDB 2.2
  6. OpenNews: Релиз СУБД Neo4j 1.3, ориентированной на хранение графов
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/53337-postgresql
Ключевые слова: postgresql, graph, agensgraph
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:24, 11/07/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –7 +/
     
     
  • 2.2, Аноним (2), 12:29, 11/07/2020 Скрыто модератором
  • +1 +/
     
  • 2.3, Аноним (3), 12:33, 11/07/2020 Скрыто модератором
  • +9 +/
     

     ....ответы скрыты модератором (2)

  • 1.4, YetAnotherOnanym (ok), 12:33, 11/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ээээ... а насколько эффективно организовано хранение графовых данных и их обработка в реляционной БД, по сравнению с нативными графовыми БД?
     
     
  • 2.5, x3who (?), 13:44, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот пишут: "AgensGraph is fastest graph database all around the world."
    (с) https://www.startupranking.com/bitnine
     
     
  • 3.21, Аноним (21), 22:11, 12/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    на заборах тоже пишут...
     
  • 3.27, лютый жабби__ (?), 13:08, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как довольный юзер neo4j скажу, либо там от слона ничего не осталось, либо они брешут как троцкие.
    Лень по ссылкам ходить, но полагаю, что функционала там как во всех сишных поделках, на 5% от neo4j. Когда сделаете близко к 100%, тогда и квакайте про fastest around the world :)))
     
  • 2.9, neAnonim (?), 17:15, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQL

    я предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются по разному. (src лень изучать)

     
  • 2.20, YetAnotherOnanym (ok), 18:56, 12/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сам себе отвечу.
    Там на их сайте вроде бы основной фишкой преподносится то, что в ПГ хранятся некие данные об объектах (в традицонной для реляционной БД форме) и в дополнение к этому некая граф-структура, отражающая связи между этими объектами. То есть, это именно дополнение к ПГ для работы с неким специфическим типом данных, и её не совсем уместно сравнивать с графовыми БД.
     
     
  • 3.25, Аноним (25), 10:48, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно ссылку? Как понял я основная фича это то, что можно одновременно использовать реляционные и графовые схемы.
     
     
  • 4.26, YetAnotherOnanym (ok), 10:58, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Прямо на стартовой (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
     
  • 2.29, master (??), 17:46, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/012
     

  • 1.6, Аноним (6), 13:48, 11/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Postgres получился неплохой метадвижок для создание специализированных бд в виде расширений.
     
  • 1.10, mos87 (ok), 18:09, 11/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?
    Sql головного мозга какой-то
    Это все равно что у отвертки из рем набора машины вместо ручки будет руль
     
     
  • 2.11, Аноним (11), 18:52, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Для тех случаев, когда есть и классически-реляционные, и графовые данные, и хочется с ними работать атомарно, в рамках транзакций - очень удобно должно быть.
     
  • 2.12, Cuernud (?), 20:04, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это ты бы так сделал. А нормальные люди используют низкоуровневый движок хранения, который есть в реляционной СУБД, и создают свою обёртку, вместо SQL-ной.
    Ну и конечно, SQL головного мозга тебе не грозит, этой болезни у тебя просто "угнездиться негде". ©
     
  • 2.13, Аноним (13), 21:51, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если уже есть Постгрес на проекте лучше уж пихать все в неё чем поднимать новую базу и городить все туда.
     
  • 2.14, Ordu (ok), 21:52, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?

    Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой.

    Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке.
    Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида:

    struct Vertex {
        name: String,
        edge: Vec<Edge*>,
    }

    struct Edge {
       left: *Vertex,
       right: *Vertex,
    }

    не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.

     
  • 2.15, Аноним (15), 21:53, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Графовое расширение - крайне недостающая вещь в PostgreSQL, чтобы эта БД была по настоящему универсальным средством построения систем. С JSONB (средство хранения некого куска данных без схемы) и графами она покроет все потребности большинства сервисов. Базу это не убьёт, но улучшит. А когда доведут до ума FDW и шардинг, это будет атомная бомба в мире СУБД.


    Сейчас БД активно идут в универсальность.

     
     
  • 3.16, нитрол (?), 22:10, 11/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, все, кому это надо в работе, люто ждут :) Когда-то давно игрался с agens, вроде работает, но 0.х и малоизвестность не тянет это в прод. Кажется, некие Fujitsu/etc, один из корпоративных контрибьюторов pg, где-то заикались, что у них в roadmap добавить graph model в pg. Если все это правда, то могут скоро много разных graph model impl повалить в pg. Юношеский каммент: "может надо обратиться к Oleg Bartunov, может также хорошо запилят graph model, как у них вышло с JSONB? Там у людей вся жизнь с pg в обнимку."
     
     
  • 4.30, лютый жабби__ (?), 23:10, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >может также хорошо запилят graph model, как у них вышло с JSONB

    сколько платят за коммент? ну не скажет такого человек, который хоть раз щупал монгу.
    с чем сравниваешь-то?!

     
     
  • 5.31, нитрол (?), 20:24, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>может также хорошо запилят graph model, как у них вышло с JSONB
    > сколько платят за коммент? ну не скажет такого человек, который хоть раз
    > щупал монгу.
    > с чем сравниваешь-то?!

    Я, наверное, не уловил основную мотивацию вопроса, но попробую ответить, как смогу.

    Монгу, конечно же, пробовали и в проде топтали, но бывают такие задачи/проекты, где очень удобно/хорошо ложится все в один multi-model storage как тот же pg, где можно использовать прелести document oriented (JSONB), различные индексы, уже проверенные временем подходы к работе с SQL (т.е. народ это уже умеет делать, не надо новый *QL учить, плюс готовые решения around), тут же и готовые решения под time series data (тигр tsdb) и т.п.

    Но я это пишу не сцелью "уговорить" использовать базу Х для хранения данных или забивания гвоздей везде и всегда. Это просто пример, ибо не везде solution X стоит слепо лепить, или даже если очень хочется и можется, не везде оно хорошо зайдет.

    Как-то так.

     
  • 2.23, КО (?), 09:07, 13/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы немножко путаете понятия.
    То что кто-то понимает английский язык не означает, что он англичанин. Даже если это его родной язык.
    Так же и с Бд - язык общения с пользователем не обязан быть единственным и определять ее внутреннюю структуру.
     

  • 1.19, mail (?), 13:55, 12/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Взлетит и высоко если в AWS запихают.
     
  • 1.22, КО (?), 08:56, 13/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >графо-ориентированые БД используют структуру, похожую на сеть

    Классное объяснение, с учетом того, что сеть это частный случай графа. :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру