А язык запросов? Я же не только про хранение, вспомни Cypher:

CALL algo.closeness.stream('Node', 'LINK')
YIELD nodeId, centrality

RETURN algo.getNodeById(nodeId).id AS node, centrality
ORDER BY centrality DESC
LIMIT 20;

https://neo4j.com/docs/graph-algorithms/3.5/labs-algorithms/closeness-centrality/

Сейчас же вообще тенденция "пользователю не нужно ничего искать, кроме как полнотекстом", с предположением "пользователь помнит, как называются все файлы на его компьютере наизусть".

Это да. Я в свое время JB продвигал идею сделать на базе Idea рабочую лошадку для работы со сложными документами. С разметкой, связями, автогенерацией отчетов и выжимок и так далее.

Ну это, да. Кейсы нужны. Вот ты эту выборку делаешь в graphx и кладёшь в базу/кэш. Потом забираешь и работаешь либами

Смотри, вот для такого нужны графы
https://neo4j.com/docs/graph-data-science/current/algorithms/

Это не про "выбрать из табличек" - это "выбрать таким-то типом математики"

Походу JB не прислушались :(, хотя конкурента JupiterNotebook они сделали, но там работа с кодом запросов и построением графиков по ответам

Напиши, почему то что я написал, не будет работать в твоих кейсах. Grapx - это и есть графы

Да, пару минут

Да, с помощью spark graphx, без графовой базы

Вот поэтому
https://spark.apache.org/docs/latest/graphx-programming-guide.html

Там три алгоритма

Можно работать с графами (графовой математикой) без графовой базы

Я знаю, что не прислушались, у них даже в новом Space так и нет инструментов работы с требованиями/документами.

Могу кейс придумать из логистики, где это ой как важно

Аргумент. И всё же нужно смотреть. В известных мне кейсах, GraphX хватало всегда.

С документами я недавно находил, в открытый доступ (опен сурс) spotify backstage выложили, внутренний тулл, с плагином для работы с документами. Руки пока не дошли развернуть. Все остальные ide в моем поле зрение ни о чем, тот же сфинкс, которые многие используют, что то не он для меня от слова совсем.

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

Конечно можно это написать поверх spark'а, можно в app вынести - это не проблема. Проблема всегда в том, что ты не знаешь, какие связи тебе именно нужны, и "дискаверишь" их в процессе - а это дорого на таблицах

Сфинкс - это же просто полнотекстовый движок. Или что-то еще есть?

Да он самый. Просто когда ищешь, не разобравшись его советуют, через пару месяцев повторяешь поиск, забывается, так как увидев его сразу понятно что не он нужен, опять смотришь, и все повторяется.

Ну, тогда уж лучше эластик. Для себя я конфлюенс ставлю, но он с каждым годом все хуже и хуже, а старые версии уже не работают (