VS
Я участвовал в разработке графовой базы
Size: a a a
2020 March 16
SB
внезапно
VS
Из плюсов - очень быстрое чтение и поиск
VS
Особенно сложный
SB
поправка: чтение, где нужны джоиины
SB
остальное чтение такое же ровно
VS
Из минусов - долгая запись
VS
С другой стороны, атомарные обновления вообще изи делаются
SB
блин, вся фишка графа как модели данных в хранении прямой ссылки на всех тех, о ком она знает, а не модель PK/FK. отсюда весь ее перфмонас. neo4j, насколько я помню, отчаянно пытались нащупать оптимальный способ хранить все это на диске, но как далеко они в этом продвинулись я уже давно не слежу, не суть.
SB
С другой стороны, атомарные обновления вообще изи делаются
почему?
VS
почему?
Потому что обновляешь обычно одну тройку
SB
Потому что обновляешь обычно одну тройку
в той же neo4j лэйблы, ноды, ребра лежат в разных файлах, которые к тому же как-то шардируются для масштабирования (точно не уверен). уже на этом уровне типичный запрос на запись потребует координации разных операций на запись и "атомарность" не выглядит прям настолько просто. или ты не о том, о чем я?
VS
Ну у меня был rdf формат в виде subject predicate object. База хранилась в сильно модифицированном sqlite
SB
а, так ты от PK/FK никуда не ушел
VS
Т.е. шардирования не было, но миллионы объектов держала
SB
это "типа" база на графах. но нет, это не она. нативная графовая модель дала бы еще лучший перфоманс.
VS
Для erp систем важен не перформанс,а возможность настройки под себя. И эта задача прямо ок выполнялась
SB
Для erp систем важен не перформанс,а возможность настройки под себя. И эта задача прямо ок выполнялась
ну да-да, я не спорю, просто товарищ выше утверждает, что не смог извлечь из графовых БД перфоманс на чтение сложных (мНоГа дЖоИнОв) запросов. на что я ему и возразил.
A
У меня была сеть людей и серии проектов и люди в них участвовали