Hacker News Reader

Comment by Belphemur | Hacker News Reader

This is great !

I'm curious how does it perform in comparison of neo4j. Especially in memory usage.

Regarding graph databases: does anyone have specific recommendations regarding something suitable to hold 2-digit TB of graph data, and allow many queries regarding how datapoints that come up are connected to some areas of interest, through the big knowledge graph[0]? I'm looking into doing some prediction work based on it, and have not found any suitable data store so far, which would work well with it, due to the size and budged restraints limiting storage to NVMe modules, instead of DRAM. Any help finding a suitable datastore would be greatly appreciated.

[0]: http://data.gdeltproject.org/documentation/GDELT-Global_Know... https://blog.gdeltproject.org/gdelt-2-0-our-global-world-in-...

Have you checked https://github.com/dgraph-io/dgraph ?

Thank you for the suggestion, this seems to be exactly what I needed. It seems that the new-ness of it prevented me from finding it earlier.

Edit: I just read some more, and it seem like this is a graph-native "brother" of cockroachdb. Which was the one I previously cosndidered, until learning of the inadequate down-pushing ability of graph queries, which would increase network needs a lot. Let me know if you want me to try and notify you once there are benchmarks or production tests successfully completed.

Dgraph is very, very immature. I'd monitor their forum for a bit before deciding whether to use - you quickly get a good feel for the issues and raw edges: https://discuss.dgraph.io/

The production stack for this is almost always postgresql/Cassandra+spark. Some people also use stuff like Janus graph, but that is still too new.

Haven't tried in production, but Janus Graph[0] supposed to be able to scale to the sizes you're describing. The another one I looked at is ArangoDB[1] but again, never used in production.

[0] http://janusgraph.org

[1] https://www.arangodb.com

https://github.com/arangodb/arangodb

Hi Jan from ArangoDB here.

2-digit TB of graph data is for sure a serious graph :) Depending on what you actually want to analyze and how the graph is structured, you can either use our Pregel integration for high-level analytics of the data set or use SmartGraphs to shard the data to a cluster and perform in-depth traversals, pattern matching and such stuff. SmartGraphs is an Enterprise feature but free for evaluation and testing. Please note that the suitability of SmartGraphs depends on the structure of the graph itself (e.g. do you have or can identify communities to shard by efficiently)

We created a series of tutorials which guide you through such a process https://www.arangodb.com/pregel-community-detection/ (next step always at the end of each tutorial). You can choose between two storage engines. Think RocksDB is the better choice in your case, as everything is persisted to disk (data/indexes) and you can configure how much main memory should be used, so you can configure the trade-off between performance and main memory yourself. If you have fast SSDs it's even better, as RocksDB is optimized for that.

I think this is an unfair comparison as RedisGraph keeps everything in memory (graph index + graph entities) for the sake of performance, AFAIK Neo utilise disks.

This makes sense however even on-disk stores written in Java sometimes have non trivial memory usage characteristics. ElasticSearch is an example, so I would check what happens in the real world. Well of course an in memory system will always end having a memory usage proportional to the graph size...

For many use cases, ES has great memory characteristics because the doc values, which is now default.

https://www.elastic.co/guide/en/elasticsearch/reference/curr...

As an example, I have the HN data set on my laptop - about 15 GB of data and I have the max mem set to 3GB (heap is usually ~1) and I can search, aggregate, etc. very quickly without memory problems.

Sure I don't want to say that on-disk systems always need to have the whole set of pages in memory, but depending on the performances that you want to obtain, at least a percentage of the pages will need to be on memory, so if one has the illusion that: in-memory systems -> memory usage proportional to the amount of data. in-disk systems -> fixed memory usage, just more disk, this is usually not true.

In addition to my previous comment I would like to add that RedisGraph memory usage is proportional to the size of the graph stored, AFAIK Neo utilizes disk as the main storage, however the Java VM may have objects in memory in order to traverse the graph, so may also use some memory.

I've never tested the memory usage difference between the two, but it should be an interesting test to perform.

Generally speaking it seems like a common practice now days to load large portions of your data from disk to memory for performance reasons obviously, no one is willing to pay the penalty hit of disk seek when it comes to real time data querying.

It's 100% in memory so I would imagine memory consumption will be bigger. But being in C and in-memory is meant for CPU efficiency.

Reply on news.ycombinator.com