forum.opennet.ru - "Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа " (25)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа "	+/–
Сообщение от opennews (??), 11-Июл-20, 12:24
Для PostgreSQL предложено дополнение AGE (AgensGraph-Extension) с реализацией языка запросов openCypher для манипуляций с наборами связанных между собой иерархических данных, образующих граф. Вместо столбцов и строк графо-ориентированые БД используют структуру, похожую на сеть - задаются узлы, их свойства и отношения между узлами. AGE распространяется под лицензией Apache 2.0, передан компанией Bitnine под покровительство Фонда Apache и в настоящее время помещён в инкубатор Apache... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53337
Ответить \| Правка \| Cообщить модератору

Оглавление

Скрыто модератором, Аноним (1), 12:24 , 11-Июл-20, (1) –7

Скрыто модератором, Аноним (2), 12:29 , 11-Июл-20, (2) +1
Скрыто модератором, Аноним (3), 12:33 , 11-Июл-20, (3) +9

Ээээ а насколько эффективно организовано хранение графовых данных и их обрабо, YetAnotherOnanym (ok), 12:33 , 11-Июл-20, (4) –2

Вот пишут AgensGraph is fastest graph database all around the world с http, x3who (?), 13:44 , 11-Июл-20, (5) +2

на заборах тоже пишут , Аноним (21), 22:11 , 12-Июл-20, (21) –1
Как довольный юзер neo4j скажу, либо там от слона ничего не осталось, либо они б, лютый жабби__ (?), 13:08 , 13-Июл-20, (27) –2

я предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются , neAnonim (?), 17:15 , 11-Июл-20, (9)
Сам себе отвечу Там на их сайте вроде бы основной фишкой преподносится то, что в, YetAnotherOnanym (ok), 18:56 , 12-Июл-20, (20) +1

Можно ссылку Как понял я основная фича это то, что можно одновременно использов, Аноним (25), 10:48 , 13-Июл-20, (25) +1

Прямо на стартовой https bitnine net , YetAnotherOnanym (ok), 10:58 , 13-Июл-20, (26)

https www amazon com Hierarchies-Smarties-Kaufmann-Management-Systems dp 01238, master (??), 17:46 , 13-Июл-20, (29)

Postgres получился неплохой метадвижок для создание специализированных бд в виде, Аноним (6), 13:48 , 11-Июл-20, (6) +3
Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml , mos87 (ok), 18:09 , 11-Июл-20, (10) –5

Для тех случаев, когда есть и классически-реляционные, и графовые данные, и хоче, Аноним (11), 18:52 , 11-Июл-20, (11) +4
Это ты бы так сделал А нормальные люди используют низкоуровневый движок хранени, Cuernud (?), 20:04 , 11-Июл-20, (12) +4
Если уже есть Постгрес на проекте лучше уж пихать все в неё чем поднимать новую , Аноним (13), 21:51 , 11-Июл-20, (13)
Может это случай синдрома когда у тебя в руках молоток, всё вокруг кажется гвоз, Ordu (ok), 21:52 , 11-Июл-20, (14)
Графовое расширение - крайне недостающая вещь в PostgreSQL, чтобы эта БД была по, Аноним (15), 21:53 , 11-Июл-20, (15) +6

Да, все, кому это надо в работе, люто ждут Когда-то давно игрался с agens, вр, нитрол (?), 22:10 , 11-Июл-20, (16)

сколько платят за коммент ну не скажет такого человек, который хоть раз щупал м, лютый жабби__ (?), 23:10 , 13-Июл-20, (30) –1

Я, наверное, не уловил основную мотивацию вопроса, но попробую ответить, как смо, нитрол (?), 20:24 , 14-Июл-20, (31)

Вы немножко путаете понятия То что кто-то понимает английский язык не означает, , КО (?), 09:07 , 13-Июл-20, (23)

Взлетит и высоко если в AWS запихают , mail (?), 13:55 , 12-Июл-20, (19) +1
Классное объяснение, с учетом того, что сеть это частный случай графа , КО (?), 08:56 , 13-Июл-20, (22)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 11-Июл-20, 12:24 –7 +/–

Не нужно, как и электрон.
В 70-х прекрасно без этих ваших графовых БД обходились.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3

2. Сообщение от Аноним (2), 11-Июл-20, 12:29 +1 +/–

А раньше люди вообще только дубинкой обходились.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (3), 11-Июл-20, 12:33 +9 +/–

> В 70-х прекрасно без этих ваших графовых БД обходились.
В 70-х и без вас, дорогой Аноним, прекрасно обходились.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от YetAnotherOnanym (ok), 11-Июл-20, 12:33 –2 +/–

Ээээ... а насколько эффективно организовано хранение графовых данных и их обработка в реляционной БД, по сравнению с нативными графовыми БД?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #9, #20, #29

5. Сообщение от x3who (?), 11-Июл-20, 13:44 +2 +/–

Вот пишут: "AgensGraph is fastest graph database all around the world."
(с) https://www.startupranking.com/bitnine

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #21, #27

6. Сообщение от Аноним (6), 11-Июл-20, 13:48 +3 +/–

Postgres получился неплохой метадвижок для создание специализированных бд в виде расширений.

Ответить | Правка | Наверх | Cообщить модератору

9. Сообщение от neAnonim (?), 11-Июл-20, 17:15 +/–

> Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQL
я предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются по разному. (src лень изучать)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

10. Сообщение от mos87 (ok), 11-Июл-20, 18:09 –5 +/–

Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?
Sql головного мозга какой-то
Это все равно что у отвертки из рем набора машины вместо ручки будет руль

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #12, #13, #14, #15, #23

11. Сообщение от Аноним (11), 11-Июл-20, 18:52 +4 +/–

Для тех случаев, когда есть и классически-реляционные, и графовые данные, и хочется с ними работать атомарно, в рамках транзакций - очень удобно должно быть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

12. Сообщение от Cuernud (?), 11-Июл-20, 20:04 +4 +/–

Это ты бы так сделал. А нормальные люди используют низкоуровневый движок хранения, который есть в реляционной СУБД, и создают свою обёртку, вместо SQL-ной.
Ну и конечно, SQL головного мозга тебе не грозит, этой болезни у тебя просто "угнездиться негде". ©

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (13), 11-Июл-20, 21:51 +/–

Если уже есть Постгрес на проекте лучше уж пихать все в неё чем поднимать новую базу и городить все туда.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

14. Сообщение от Ordu (ok), 11-Июл-20, 21:52 +/–

> Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?
Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой.
Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке.
Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида:
struct Vertex {
    name: String,
    edge: Vec<Edge*>,
}
struct Edge {
   left: *Vertex,
   right: *Vertex,
}
не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (15), 11-Июл-20, 21:53 +6 +/–

Графовое расширение - крайне недостающая вещь в PostgreSQL, чтобы эта БД была по настоящему универсальным средством построения систем. С JSONB (средство хранения некого куска данных без схемы) и графами она покроет все потребности большинства сервисов. Базу это не убьёт, но улучшит. А когда доведут до ума FDW и шардинг, это будет атомная бомба в мире СУБД.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16

16. Сообщение от нитрол (?), 11-Июл-20, 22:10 +/–

Да, все, кому это надо в работе, люто ждут :) Когда-то давно игрался с agens, вроде работает, но 0.х и малоизвестность не тянет это в прод. Кажется, некие Fujitsu/etc, один из корпоративных контрибьюторов pg, где-то заикались, что у них в roadmap добавить graph model в pg. Если все это правда, то могут скоро много разных graph model impl повалить в pg. Юношеский каммент: "может надо обратиться к Oleg Bartunov, может также хорошо запилят graph model, как у них вышло с JSONB? Там у людей вся жизнь с pg в обнимку."

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #30

19. Сообщение от mail (?), 12-Июл-20, 13:55 +1 +/–

Взлетит и высоко если в AWS запихают.

Ответить | Правка | Наверх | Cообщить модератору

20. Сообщение от YetAnotherOnanym (ok), 12-Июл-20, 18:56 +1 +/–

Сам себе отвечу.
Там на их сайте вроде бы основной фишкой преподносится то, что в ПГ хранятся некие данные об объектах (в традицонной для реляционной БД форме) и в дополнение к этому некая граф-структура, отражающая связи между этими объектами. То есть, это именно дополнение к ПГ для работы с неким специфическим типом данных, и её не совсем уместно сравнивать с графовыми БД.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #25

21. Сообщение от Аноним (21), 12-Июл-20, 22:11 –1 +/–

на заборах тоже пишут...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

22. Сообщение от КО (?), 13-Июл-20, 08:56 +/–

>графо-ориентированые БД используют структуру, похожую на сеть
Классное объяснение, с учетом того, что сеть это частный случай графа. :)

Ответить | Правка | Наверх | Cообщить модератору

23. Сообщение от КО (?), 13-Июл-20, 09:07 +/–

Вы немножко путаете понятия.
То что кто-то понимает английский язык не означает, что он англичанин. Даже если это его родной язык.
Так же и с Бд - язык общения с пользователем не обязан быть единственным и определять ее внутреннюю структуру.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 13-Июл-20, 10:48 +1 +/–

Можно ссылку? Как понял я основная фича это то, что можно одновременно использовать реляционные и графовые схемы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #26

26. Сообщение от YetAnotherOnanym (ok), 13-Июл-20, 10:58 +/–

Прямо на стартовой (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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

27. Сообщение от лютый жабби__ (?), 13-Июл-20, 13:08 –2 +/–

Как довольный юзер neo4j скажу, либо там от слона ничего не осталось, либо они брешут как троцкие.
Лень по ссылкам ходить, но полагаю, что функционала там как во всех сишных поделках, на 5% от neo4j. Когда сделаете близко к 100%, тогда и квакайте про fastest around the world :)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

29. Сообщение от master (??), 13-Июл-20, 17:46 +/–

https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

30. Сообщение от лютый жабби__ (?), 13-Июл-20, 23:10 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #31

31. Сообщение от нитрол (?), 14-Июл-20, 20:24 +/–

>>может также хорошо запилят graph model, как у них вышло с JSONB
> сколько платят за коммент? ну не скажет такого человек, который хоть раз
> щупал монгу.
> с чем сравниваешь-то?!
Я, наверное, не уловил основную мотивацию вопроса, но попробую ответить, как смогу.
Монгу, конечно же, пробовали и в проде топтали, но бывают такие задачи/проекты, где очень удобно/хорошо ложится все в один multi-model storage как тот же pg, где можно использовать прелести document oriented (JSONB), различные индексы, уже проверенные временем подходы к работе с SQL (т.е. народ это уже умеет делать, не надо новый *QL учить, плюс готовые решения around), тут же и готовые решения под time series data (тигр tsdb) и т.п.
Но я это пишу не сцелью "уговорить" использовать базу Х для хранения данных или забивания гвоздей везде и всегда. Это просто пример, ибо не везде solution X стоит слепо лепить, или даже если очень хочется и можется, не везде оно хорошо зайдет.
Как-то так.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 11-Июл-20, 12:24	–7 +/–
Не нужно, как и электрон. В 70-х прекрасно без этих ваших графовых БД обходились.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2, #3

2. Сообщение от Аноним (2), 11-Июл-20, 12:29	+1 +/–
А раньше люди вообще только дубинкой обходились.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (3), 11-Июл-20, 12:33	+9 +/–
> В 70-х прекрасно без этих ваших графовых БД обходились. В 70-х и без вас, дорогой Аноним, прекрасно обходились.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

4. Сообщение от YetAnotherOnanym (ok), 11-Июл-20, 12:33	–2 +/–
Ээээ... а насколько эффективно организовано хранение графовых данных и их обработка в реляционной БД, по сравнению с нативными графовыми БД?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5, #9, #20, #29

5. Сообщение от x3who (?), 11-Июл-20, 13:44	+2 +/–
Вот пишут: "AgensGraph is fastest graph database all around the world." (с) https://www.startupranking.com/bitnine
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #21, #27

6. Сообщение от Аноним (6), 11-Июл-20, 13:48	+3 +/–
Postgres получился неплохой метадвижок для создание специализированных бд в виде расширений.
Ответить \| Правка \| Наверх \| Cообщить модератору

9. Сообщение от neAnonim (?), 11-Июл-20, 17:15	+/–
> Проект продолжает развитие СУБД AgensGraph, которая представляет собой переработанную для обработки графов модификацию PostgreSQL я предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются по разному. (src лень изучать)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

10. Сообщение от mos87 (ok), 11-Июл-20, 18:09	–5 +/–
Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем? Sql головного мозга какой-то Это все равно что у отвертки из рем набора машины вместо ручки будет руль
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11, #12, #13, #14, #15, #23

11. Сообщение от Аноним (11), 11-Июл-20, 18:52	+4 +/–
Для тех случаев, когда есть и классически-реляционные, и графовые данные, и хочется с ними работать атомарно, в рамках транзакций - очень удобно должно быть.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

12. Сообщение от Cuernud (?), 11-Июл-20, 20:04	+4 +/–
Это ты бы так сделал. А нормальные люди используют низкоуровневый движок хранения, который есть в реляционной СУБД, и создают свою обёртку, вместо SQL-ной. Ну и конечно, SQL головного мозга тебе не грозит, этой болезни у тебя просто "угнездиться негде". ©
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (13), 11-Июл-20, 21:51	+/–
Если уже есть Постгрес на проекте лучше уж пихать все в неё чем поднимать новую базу и городить все туда.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

14. Сообщение от Ordu (ok), 11-Июл-20, 21:52	+/–
> Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем? Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой. Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке. Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида: struct Vertex { name: String, edge: Vec<Edge>, } struct Edge { left: Vertex, right: *Vertex, } не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (15), 11-Июл-20, 21:53	+6 +/–
Графовое расширение - крайне недостающая вещь в PostgreSQL, чтобы эта БД была по настоящему универсальным средством построения систем. С JSONB (средство хранения некого куска данных без схемы) и графами она покроет все потребности большинства сервисов. Базу это не убьёт, но улучшит. А когда доведут до ума FDW и шардинг, это будет атомная бомба в мире СУБД. Сейчас БД активно идут в универсальность.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #16

16. Сообщение от нитрол (?), 11-Июл-20, 22:10	+/–
Да, все, кому это надо в работе, люто ждут :) Когда-то давно игрался с agens, вроде работает, но 0.х и малоизвестность не тянет это в прод. Кажется, некие Fujitsu/etc, один из корпоративных контрибьюторов pg, где-то заикались, что у них в roadmap добавить graph model в pg. Если все это правда, то могут скоро много разных graph model impl повалить в pg. Юношеский каммент: "может надо обратиться к Oleg Bartunov, может также хорошо запилят graph model, как у них вышло с JSONB? Там у людей вся жизнь с pg в обнимку."
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #30

19. Сообщение от mail (?), 12-Июл-20, 13:55	+1 +/–
Взлетит и высоко если в AWS запихают.
Ответить \| Правка \| Наверх \| Cообщить модератору

20. Сообщение от YetAnotherOnanym (ok), 12-Июл-20, 18:56	+1 +/–
Сам себе отвечу. Там на их сайте вроде бы основной фишкой преподносится то, что в ПГ хранятся некие данные об объектах (в традицонной для реляционной БД форме) и в дополнение к этому некая граф-структура, отражающая связи между этими объектами. То есть, это именно дополнение к ПГ для работы с неким специфическим типом данных, и её не совсем уместно сравнивать с графовыми БД.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #25

21. Сообщение от Аноним (21), 12-Июл-20, 22:11	–1 +/–
на заборах тоже пишут...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

22. Сообщение от КО (?), 13-Июл-20, 08:56	+/–
>графо-ориентированые БД используют структуру, похожую на сеть Классное объяснение, с учетом того, что сеть это частный случай графа. :)
Ответить \| Правка \| Наверх \| Cообщить модератору

23. Сообщение от КО (?), 13-Июл-20, 09:07	+/–
Вы немножко путаете понятия. То что кто-то понимает английский язык не означает, что он англичанин. Даже если это его родной язык. Так же и с Бд - язык общения с пользователем не обязан быть единственным и определять ее внутреннюю структуру.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 13-Июл-20, 10:48	+1 +/–
Можно ссылку? Как понял я основная фича это то, что можно одновременно использовать реляционные и графовые схемы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #20 Ответы: #26

26. Сообщение от YetAnotherOnanym (ok), 13-Июл-20, 10:58	+/–
Прямо на стартовой (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
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25

27. Сообщение от лютый жабби__ (?), 13-Июл-20, 13:08	–2 +/–
Как довольный юзер neo4j скажу, либо там от слона ничего не осталось, либо они брешут как троцкие. Лень по ссылкам ходить, но полагаю, что функционала там как во всех сишных поделках, на 5% от neo4j. Когда сделаете близко к 100%, тогда и квакайте про fastest around the world :)))
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

29. Сообщение от master (??), 13-Июл-20, 17:46	+/–
https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Managem...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

30. Сообщение от лютый жабби__ (?), 13-Июл-20, 23:10	–1 +/–
>может также хорошо запилят graph model, как у них вышло с JSONB сколько платят за коммент? ну не скажет такого человек, который хоть раз щупал монгу. с чем сравниваешь-то?!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #31

31. Сообщение от нитрол (?), 14-Июл-20, 20:24	+/–
>>может также хорошо запилят graph model, как у них вышло с JSONB > сколько платят за коммент? ну не скажет такого человек, который хоть раз > щупал монгу. > с чем сравниваешь-то?! Я, наверное, не уловил основную мотивацию вопроса, но попробую ответить, как смогу. Монгу, конечно же, пробовали и в проде топтали, но бывают такие задачи/проекты, где очень удобно/хорошо ложится все в один multi-model storage как тот же pg, где можно использовать прелести document oriented (JSONB), различные индексы, уже проверенные временем подходы к работе с SQL (т.е. народ это уже умеет делать, не надо новый *QL учить, плюс готовые решения around), тут же и готовые решения под time series data (тигр tsdb) и т.п. Но я это пишу не сцелью "уговорить" использовать базу Х для хранения данных или забивания гвоздей везде и всегда. Это просто пример, ибо не везде solution X стоит слепо лепить, или даже если очень хочется и можется, не везде оно хорошо зайдет. Как-то так.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #30