Ключевое отличие TigerGraph от остальных графовых бд это MPP и ACID одновременно, т.е. она HTAP бд (новое поколение). Шардинг реализован как node-based (есть два основных вида - predicate-based когда мы шардируем грани, и node-based когда мы шардируем вершины с исходящими гранями). Проблема node-based шардинга в supernode problem (когда очень много граней у вершины). Документация, да у них та еще, очень тяжело разобраться, видимо какой то особый образ мышления у китайцев. Это притом что я отлично знаю cypher и gremlin и знаю примерно каким должен быть запрос. Клиентам они говорят, купите лицензию, потом мы вам дадим наших инженеров и они все настроят и объяснят.
Вообще у нас сейчас только два способа хранить графы — это таблицы и key-value (и колоночные) структуры. Но перед этим существует ещё in-memory слой, где ноды связаны через memory pointer'ы, т.е. экземпляр класса Node в RAM имеет скалярные свойства (типа name, gender и т.д.), но кроме них ещё массив pointer'ов на другие ноды с которыми он связан. И за счёт этого слоя получается очень быстро передвигаться по графу, просто прыгаешь из одной области памяти в другую по pointer'ам. В Neo4j они называют это «joins during building, not during quering». Если у mssql такой слой есть, то принципиально это то же самое что графовая БД.
match (bts)-[:port_attach]->(:port)-[:vlan]->(vlan:vlan)
Если точно известно, что на другом конце нод типа port (а это очевидно из типа связи port_attach), то не нужно ещё раз фильтровать по метке, это лишний шаг, можете посмотреть профиль запроса. Т.е.:
match (bts)-[:port_attach]->()-[:vlan]->(vlan)
Я думаю это ошибочная модель графа, переходы между зонами должны быть представлены гранями т.к. это действия, а не объекты. На грани я бы предложил хранить trackId цепочки и построить vertex-centric индекс (zoneId, trackId)
Я думаю это ошибочная модель графа, переходы между зонами должны быть представлены гранями т.к. это действия, а не объекты. На грани я бы предложил хранить trackId цепочки и построить vertex-centric индекс (zoneId, trackId)
это чтобы проблему supernode обойти?
In-Database аналитика, тьюринг полный язык GSQL, который наиболее близок к грядущему GQL стандарту
вот это реально сомнительно
Ключевое отличие TigerGraph от остальных графовых бд это MPP и ACID одновременно, т.е. она HTAP бд (новое поколение). Шардинг реализован как node-based (есть два основных вида - predicate-based когда мы шардируем грани, и node-based когда мы шардируем вершины с исходящими гранями). Проблема node-based шардинга в supernode problem (когда очень много граней у вершины). Документация, да у них та еще, очень тяжело разобраться, видимо какой то особый образ мышления у китайцев. Это притом что я отлично знаю cypher и gremlin и знаю примерно каким должен быть запрос. Клиентам они говорят, купите лицензию, потом мы вам дадим наших инженеров и они все настроят и объяснят.
а что за плагин у neo4j - node-splitter?
Что будет дальше можно в этом видео подсмотреть https://info.tigergraph.com/graph-ai-summit-spring-2021-hardware-considerations-for-faster-and-deeper-insights-from-your-large-scale-graph
Если точно известно, что на другом конце нод типа port (а это очевидно из типа связи port_attach), то не нужно ещё раз фильтровать по метке, это лишний шаг, можете посмотреть профиль запроса. Т.е.:
match (bts)-[:port_attach]->()-[:vlan]->(vlan)