2010-07-13 17 views

Répondre

11

En guise de réponse à une question, vous pouvez consulter cette interview avec Emil Eifrem (fondateur de neo): http://www.infoq.com/interviews/eifrem-graphdbs. En particulier, consultez la partie «Du point de vue de la complexité des données, comment Neo4j aide-t-il à éliminer la complexité de l'implémentation du stockage de vos données?»: «Des centaines de millions sont probablement importants et des milliards certainement importants.

Je discutais récemment avec neo technologies, dans lequel ils partageaient le fait que les plus grandes installations qu'ils connaissent ne possèdent pas plus de 3 à 5 machines. En outre, ils ont dit que la taille du graphique que neo4j peut gérer efficacement dépend du nombre de nœuds et d'arêtes dans le graphique. Si elles peuvent toutes être gardées en mémoire, la plupart des requêtes seront rapides. Vous trouverez les tailles pour les nœuds et les arêtes en mémoire à http://wiki.neo4j.org/content/Configuration_Settings (il s'agit de 9 octets par nœud et de 33 octets par relation).

+1

3-5 machines semble assez petit ... –

+1

Jep. C'est ce que nous pensions. La solution HighAvailability aurait été testée avec 20 machines. Ils n'ont pas vu le besoin de plus de machines dans la pratique. Si votre ok avec la limite actuelle de 4 milliards de primitives alors votre problème peut devenir la vitesse d'écriture (qui est généralement limitée en vitesse par IO). L'ajout de serveurs met à l'échelle les lectures mais pas les écritures. – Stephan

+0

Il s'agit de 32 milliards de primitives. –

12

Le nombre de nœuds et de relations était récemment (avec le 1.3 release) étendu à 32 milliards chacun et 64 milliards de plus pour les propriétés. Si vous regardez la liste de diffusion, il y a eu des enquêtes récentes pour quitelarge datastores.