Thanks for the ideas! OK, I'll tell a bit more about my current scenario. I use the graph to store medium sized texts (various sizes, 1 - 30kb) with some properties, their tokens (1-2-3 word phrases) with many properties, and some other stuff too which is not relevant now. Since I use the graph for teaching AI algoritms, I need to query (and modify) large parts of the graph from time to time and I cannot do any pruning here (at least I didn't find a way to do that). The relationships I use are mainly the same type and I cannot really distinguish them in the domain. The only thing I can think of is to introduce different types of relationships based on word count for tokens (e.g.: TOKEN_1, TOKEN_2, TOKEN_3 for 1-2-3 length phrases). Otherwise they are considered the same. And all the text nodes are connected to the reference node (I have *many* text nodes). The most problematic part is to query (a part of) the text nodes. Currently I access the DB through the REST API mainly because I need to have concurrent access and it seemed a good solution at first when I started the project. I use travesing to query the nodes/relationships I need and I also use the indexing service for various tasks (duplicate check, node lookup). Since the relationships I use have the same type, I cannot write efficient prune evaluators. It would be good if I could query the results in more groups each returning only ~100 results but I have no ways to tell the traverser where to start and where to stop (the graph itself doesn't have such information).
If I understand well Your advice I should implement complex server plugins and call them using REST? So actually I put parts of the program logic to the DB server? This will have better performance but won't it make development harder (program logic is distibuted on different levels)? Yes, unfortunately I need concurrent write access. However, sharing the GraphDatabaseService object might be usable for me. I'll investigate this approach too. Thanks again, Miklós Kiss 2011.02.28. 10:38 keltezéssel, Michael Hunger írta: > Miklós, > > you should actually do both :) > > So go for the embedded version to create domain specific service calls for > interacting with your database. > > And then expose those as your own REST-endpoints using either a Server-Plugin > or an unmanaged extension. > > The current REST server API is too noisy to transfer that many relationships > per node. > > How do you currently use the REST server API ? Which calls? > If you don't already do traversals then you should definitely look into them. > (Rather than traversing node relationships one by one). > With the traversal you can already specify javascript code that is executed > in the server context for pruning and filtering. > > Do you need concurrent write access? Otherwise the other stores can work in > readonly mode against the database. > And concurrent access from inside the same VM is no problem, you can easily > share the GraphDatabaseService object. > > Perhaps you can also tell us a bit about your domain and how it is modelled > to support you there. > > Cheers > > Michael > > Am 28.02.2011 um 10:19 schrieb Kiss Miklós: > >> Hi all, >> >> I'm wondering if I'm using the Neo4j graph database right. My current >> graph structure contains many relations for every single node. Some of >> the nodes have>10000 relations which is hard to traverse using REST >> server (collecting nodes is heavy on memory and transmitting is heavy on >> bandwith). >> >> My first question is: is this structure a useable one or should I >> restructure my graph so that the number of direct relationships becomes >> much lower (don't really know how could I do that and it would obfuscate >> the domain model)? >> >> My second question is: if I leave the structure that way, I could solve >> the performance issues if I used the embedded version of neo. However, I >> need to have concurrent access to the graph. Is this possible? >> >> Thanks, >> Miklós Kiss >> _______________________________________________ >> Neo4j mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
