[Neo4j] Neo4j embedded
jacob.hansson at neotechnology.com
Fri Oct 7 16:06:09 CEST 2011
If you choose to use the server or if you choose the embedded database will
have a significant impact on how those results turn out. For performing
large queries, the server should not be much slower than the embedded
database. It will be significantly slower (more than two orders of
magnitude) on single read/write operations.
Like Jim mentioned, we are looking at a new REST implementation that
essentially nullifies this speed difference. It is currently at an
experimental stage, but we will make sure to share details and get feedback
on it from y'all as it progresses, stay tuned.
On Fri, Oct 7, 2011 at 3:15 PM, Antriani Stylianou <antriani.s at gmail.com>wrote:
> Thanks again for the answer but my system is actually a benchmarking
> In other words I am trying to find out if there are performance
> difference between the 2 DBs not through an application.
> On 10/7/11 1:36 PM, Jim Webber wrote:
> > Hi Antriani,
> >> Ok, but the REST API doesn't produce more network overhead (i.e.
> >> HTTP...) compared to a driver implementation using sockets for access
> >> for example MySQL JDBC ?
> > I have no data to support this, but I'm going to make an educated guess
> and say that the MySQL JDBC driver is overall faster than our REST API :-)
> > But my point stands: measure your system, not its components.
> > Neo4j might well have a slower network API than MySQL, but you might find
> that because of the data model, you ship less data over the network, or the
> queries run so much faster that network differences become negligible.
> > Something will be your bottleneck in either the Neo4j case or the MySQL
> case, but if the Neo4j case is faster despite having a slower network
> interface, then you might not care.
> > Jim
> > _______________________________________________
> > Neo4j mailing list
> > User at lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> Neo4j mailing list
> User at lists.neo4j.org
Phone: +46 (0) 763503395
More information about the User