We have stress tested neo4j with over 500 concurrent users in a webapp with a smaller dataset and we found no performance issues. We even wrap their api in a domain layer that adds some extra overhead. One thing to keep in mind is that if your data ever grows to a point where it needs to be distributed among machines you can't do that with the free version of neo but I think they support it with one of the commercial licenses.
In my experience so far with Neo +5 months, since it is embedded if you use java you get a much better experience than using any relational db with a orm layer such as hibernate. The data is not transported from your db to a resulset then to a pojo then tou your view objects. With neo the data may be in memory when you request it and there is no jdbc layer in between your code and the graph. We have also purposedly crashed the JVM and app hoping that at some point it will corrupt the graph and we have been doing this repeteadly at least 10 times a day for the last 5 months. It has always recovered and completed queued transactions. So far we have not been able to corrupt the graph or bring it down. Backing up the data is also easy as a copy of the graph folder is all you need. PROS - Fast - Easy api - Reliable - High Performance in our use cases - The Neo team is fast answering doubts and questions - No SQL - Fast relationship traversals, in the relational world this usually means JOINs which are not very scalable. - Ideal for scenarios where there are multiple relationships and interconnected objects CONS - Free version is non distributable in multiple machines - Only one process or JVM can access the graph at a time - No SQL (if you like sql) - Filtered traversals where results should be ordered usually require full scans / traversal then reorder results. This is not scalable when pagination is required and the results are millions. We have fixed this issue though by having a separate index for single ordereded relationships. In a nutshell this is what your typical relational db provides as a btree index of properties that allows you to query with "order by" fast. Neo at the time does not have that so you have to keep your own indexes if you want ordered traversals. (Not a trivial task to implement) 2010/5/2 suryadev vasudev <suryadev.vasu...@gmail.com> > We are evaluating Neo4J for a business critical application. There will be > a > User Interface UI component to browse the graph, create nodes and > properties > as well as create/modify relationships. The data set spans across 7 domains > and expected to be around 40 GB. > User will manipulate data in 3 domains. A back end integration is expected > to manage data in remaining 4 domains. I use the word domain to mean > nodes/relationships/attributes that are grouped to perform one activity > like > Sale Order, Shipping, Distribution etc. The domains are related to each > other and queries traverse across different domains > We are expecting 500 users per hour to use the system. Each user may > initiate a query once in 2 minutes. Each query is expected to traverse > through 20,000 nodes and collect 10 properties for filtering/display. > I am accountable for implementing this system. You probably know what > accountable means:) Say it is related to Guillotine. > What should I do to convince myself to move forward? Things that come to my > mind are stability, scalability, auditing and monitoring. Stability means > the JVM/application won't crash. Scalability means each user will get > response in 1-2 second for up to 500 users. Auditing means the system > reports its performance for all interactions. Monitoring means health and > performance of the system are made visible. > Comments and pointers to related articles are appreciated. > TIA > SDev > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Raul Raja _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
