Enkele gedachten hierover:
Ik zou proberen uw Neo4j-domeinmodel te modelleren om de kenmerken van elk knooppunt in de grafiek op te nemen. Door uw gegevens te scheiden in twee verschillende gegevensarchieven, kunt u bepaalde bewerkingen beperken die u misschien wilt doen.
Ik denk dat het neerkomt op wat je met je grafiek gaat doen. Als u bijvoorbeeld alle knooppunten wilt vinden die zijn verbonden met een specifiek knooppunt waarvan de attributen (dwz naam, leeftijd ... wat dan ook) bepaalde waarden zijn, zou u dan eerst de juiste knooppunt-ID in uw MySQL-database moeten zoeken en vervolgens naar Neo4j? Dit lijkt traag en te ingewikkeld als je dit allemaal in Neo4j zou kunnen doen. Dus de vraag is:heb je de attributen van een knoop nodig bij het doorlopen van de grafiek?
Veranderen uw gegevens of zijn deze statisch? Door twee afzonderlijke gegevensopslag te hebben, wordt het ingewikkelder.
Hoewel het genereren van statistieken met behulp van een MySQL-database misschien gemakkelijker is dan alles in Neo4j te doen, is de code die nodig is om een grafiek te doorlopen om alle knooppunten te vinden die aan een gedefinieerd criterium voldoen, niet al te moeilijk. Wat deze statistieken zijn, zou uw oplossing moeten bepalen.
Ik kan geen commentaar geven op de prestaties van de MySQL-query om knooppunt-ID's te selecteren. Ik denk dat dat komt door het aantal knooppunten dat u moet selecteren en uw indexeringsstrategie. Ik ben het echter eens over de prestatiekant van dingen als het gaat om het doorlopen van een grafiek.
Dit is een goed artikel hierover:MySQL vs. Neo4j op een Grootschalige grafiekoverschrijding en in dit geval, als ze groot zeggen, bedoelen ze alleen een miljoen hoekpunten/knooppunten en vier miljoen randen. Het was dus niet eens een bijzonder dichte grafiek.