Как стать автором
Обновить

Комментарии 13

Наконец-то что-то интересное про сотовую связь. И спасибо за идею. Попробую использовать ваши наработки.

Странно, конечно, читать «т.н. графовые базы данных», «никому из наших айтишников» и пр. Хесус Барраса, по ощущениям главный евангелист Neo4j, как раз на телекомах специализировался. Такие кейсы давно уж стали общим местом. Вот раздел у них на сайте про вашу «вертикаль»: https://neo4j.com/use-cases/telecom. У других GDBMS аналогичные разделы на сайтах есть.

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

Спасибо за материал, теперь есть у кого спросить:
Графовые таблицы в MS-SQL можно назвать аналогом, или это, всё же, попытка эмулировать графовую логику реляционным движком?

Не изучал, не знаю.
Вообще у нас сейчас только два способа хранить графы — это таблицы и 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, например.

match (bts)-[:port_attach]->(:port)-[:vlan]->(vlan:vlan)
Если точно известно, что на другом конце нод типа port (а это очевидно из типа связи port_attach), то не нужно ещё раз фильтровать по метке, это лишний шаг, можете посмотреть профиль запроса. Т.е.:
match (bts)-[:port_attach]->()-[:vlan]->(vlan)
Ок, спасибо, сделаем.
Интересное решение. У нас для подобных задач используется Amdocs OSS который мы сильно допилили под наши процессы. Основной источник данных для базы — интеграция с системами управления, а посторение abis, iub и s1 — на основе дискаверинга macинтерфейсов.
На каких сегментах транспорта делаете дискаверинг mac?
Вся сеть доступа. Каждый свитч на каждом сайте
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории