Трассировка сервисов в мобильной транспортной сети. Как мы пришли к графовой БД Neo4j

Спрашивали до кого могли дотянуться. Как уже описывал — решение пришло в какой-то степени случайно.

А про внедрёж у Cisco и Со — смотрели use-cases, но это больше к buzzwords относится, чем к юзкейсам. Толковые советы дал вот этот товарищ, рекомендую его блог: maxdemarzi.com
У него близкая по теме статья: maxdemarzi.com/2019/03/01/network-routing-in-neo4j
Но у нас несколько другой подход.

Не изучал, не знаю.

Вообще у нас сейчас только два способа хранить графы — это таблицы и key-value (и колоночные) структуры. Но перед этим существует ещё in-memory слой, где ноды связаны через memory pointer'ы, т.е. экземпляр класса Node в RAM имеет скалярные свойства (типа name, gender и т.д.), но кроме них ещё массив pointer'ов на другие ноды с которыми он связан. И за счёт этого слоя получается очень быстро передвигаться по графу, просто прыгаешь из одной области памяти в другую по pointer'ам. В Neo4j они называют это «joins during building, not during quering». Если у mssql такой слой есть, то принципиально это то же самое что графовая БД.

Меня тоже этот вопрос интересовал, но точно не могу сказать. Судя по результатам бенчмарков и ряду ограничений, в MS SQL некоторая оптимизация хранения графовых структур в стиле index free adjacency все же есть.

Вообще же, у MS есть и собственно графовая СУБД — Trinity. На ней крутятся демки их Concept Graph, например.

Ок, спасибо, сделаем.

На каких сегментах транспорта делаете дискаверинг mac?