Hacker News Reader

Comment by rkwz | Hacker News Reader

The numbers look impressive compared to Neo4j!

Do you know what is the reason for these results? Is it because of C++ (MemGraph) vs Java (Neo4j)?

Any other queries where MemGraph does poorly compared to Neo4j? What are the downsides to using MemGraph?

So is it because of C++ vs Java? Well, not everything can be written just to these differences, a lot of stuff can influence results, architecture, database isolation level etc. One of the many reasons is definitely a C++ and Java argument. Take a look at memory usage, here, you can see how JVM is memory hungry. Also, it takes time to warm JVM and Neo4j, so it is another penalty for the same reason.

So far, on this dataset and scale, we didn't encounter but we have plans for a bigger dataset and more complex queries, you can take a look at the limitations part of this benchmark.

What are the downsides, Memgraph and Neo4j are currently a bit different vendors, Memgraph is an in-memory database, while Neo4j is on disk. So in Memgraph's case, you are exclusively using RAM as a storage but gain speed, we have snapshots for disk for recovery, etc. While Neo4j is on disk, not-in memory but they are loading a bunch of stuff in RAM and consuming waste amounts of RAM, so it is hard to give pure distinction.

The memory/disk is actually a huge difference for durability and a really important factor when making a decision to use a database. I believe it would be good to mention it in the benchmark for fair comparison.

Yes, good point, but both Neo4j and Memgraph(https://memgraph.com/product) are ACID-compliant and have on-disk persistent storage. Memgraph is currently RAM constricted, while Neo4j is not but it is hungry for RAM.

Is the comparison using on-disk persistent storage of Memgraph? The facts that they're both ACID-compliant and you can backup the data to disk in Memgraph are not relevant IMO considering the fact that I/O is the main driver for the latency for most of the workloads and reading data from disk is much slower compared to memory. Not sure how Neo4j works but an alternative might be running Neo4j in-memory mode.

No, currently, Memgraph is loaded 100% in RAM. Agree with the point about latency regarding I/O. The story with Neo4j is a bit more complex one. They are loading graph in memory, and using disk storage, doing both. But take a look at memory usage from them, it is the magnitude higher then Memgraph.

Did you manage to figure out where does the difference in memory consumption come from? Do you attribute it only to JVM or have you designed low-memory footprint data structures in memgraph?

Java programs tend to use the memory they're given to provide the best performance in the server environments so it's not conservative in terms of memory allocation. While it does use more memory in a given time, it doesn't necessarily mean that it relies on all the allocated memory. That's one of the reasons why benchmarking is so hard..

Exactly, you are right. We were able to decrease Memory usage to 1GB in Neo4j case, but then experienced some crashes. We then just removed the limit, and let it take us much as it needs.

The difference comes from several things, JVM being the first and obvious one. It takes as much memory as whole Memgraph + small dataset in this case. Second is the overallocation that JVM/Neo4j is doing, taking a bit more memory to have future space to grow. The third one comes to the implementations of storage and Neo4j cache implementation, not sure what Neo4j does on that side and how impactful it is. We use a skip list.

Reply on news.ycombinator.com