Няколко мисли по въпроса:
Бих се опитал да моделирам вашия модел на домейн Neo4j, за да включа атрибутите на всеки възел в графиката. Като разделите данните си в две различни хранилища за данни, може да ограничите някои операции, които може да искате да направите.
Предполагам, че се свежда до това какво ще правите с вашата графика. Ако например искате да намерите всички възли, свързани към конкретен възел, чиито атрибути (т.е. име, възраст... каквото и да е) са определени стойности, първо трябва ли да намерите правилния идентификационен номер на възел във вашата база данни MySQL и след това да влезете в Neo4j? Това просто изглежда бавно и прекалено сложно, когато можете да направите всичко това в Neo4j. Така че въпросът е:ще ви трябват ли атрибутите на възел, когато обикаляте графиката?
Ще се променят ли данните ви или са статични? Наличието на две отделни хранилища за данни ще усложни нещата.
Въпреки че генерирането на статистически данни с помощта на MySQL база данни може да е по-лесно, отколкото да се прави всичко в Neo4j, кодът, необходим за преминаване през графика, за да се намерят всички възли, които отговарят на определени критерии, не е прекалено труден. Какво представляват тези статистически данни трябва да управляват вашето решение.
Не мога да коментирам ефективността на MySQL заявката за избор на идентификатори на възли. Предполагам, че това се свежда до колко възли ще трябва да изберете и вашата стратегия за индексиране. Съгласен съм за производителността на нещата, когато става въпрос за преминаване на графика.
Това е добра статия само за това:MySQL срещу Neo4j на Обход на широкомащабна графика и в този случай, когато казват голям, те означават само милион върхове/възли и четири милиона ръба. Така че дори не беше особено плътна графика.
