3 ms·

ArangoDB is free open source multi model no-sql db that has decent¹ perfomance with graph support: https://www.arangodb.com https://www.arangodb.com ¹ https:/

by iod 11y ago

ArangoDB is free open source multi model no-sql db that has decent¹ perfomance with graph support: https://www.arangodb.com https://www.arangodb.com ¹ https://www.arangodb.com/2015/10/benchmark-postgresql-mongodb-arangodb/ https://www.arangodb.com/2015/10/benchmark-postgresql-mongod...

rspeer 11y ago
"The performance will suffer if the dataset is much bigger than the memory." That is a huge drawback when compared to relational databases. A good follow-up question would be: which open-source graph databases can reasonably import and store graph data that's not small -- that is, more data than fits in than RAM? Without proprietary extensions?
- jerven 11y ago
  Blazegraph Virtuoso Jena tdb Can easily load large to very large graphs.
- reactor 11y ago
  Looks like they have persistent indexes in the roadmap (ver 3.0) https://www.arangodb.com/roadmap/ https://www.arangodb.com/roadmap/ which might help.
- LyndsySimon 11y ago
  How much data are you dealing with? In my (admittedly limited) experience, it's usually cheaper to throw money at hardware than other options.
  - rspeer 11y ago
    Throwing money on RAM because most graph databases haven't figured out how to use the disk effectively is not a good use of money. What's cheaper than buying all the RAM in the universe is figuring out a different system besides a graph database that does the job. A good example would be the graph of Wikipedia links. About 100 million edges among 5 million nodes, last I checked. The nodes have large differences in degree. The raw data for this is not the slightest bit large. We're only talking about gigabytes. But it would absolutely destroy Neo4J to even try to import it, to say nothing of running an interesting algorithm that justifies using a graph database on it, and Neo4J seems to be everyone's favorite open-source graph database for some reason.
- neunhoef 11y ago
  One of the developers of ArangoDB here. Let me explain this quotation. When your graph data (including indices) do no longer fit into the RAM of a single server, you can either live with the higher latency of loading data from disk or you can use sharding, which will lead to communication and therefore slower traversals. That does not mean that things stop working, but performance will be less good, you can no longer visit tens of millions of nodes per second in a traversal as in RAM on a single server. If you actually only traverse a much smaller hot subgraph, I would probably go for the disk based single server approach. If your graph has a natural known clustering, then an optimized sharding solution with fine tuned sharding keys us probably your best bet. You can do all this with ArangoDB. However, graph traversals vary greatly in many respects, and your mileage may vary accordingly, with any approach. I would love to chat in more detail about your use case.

by iod 11y ago

rspeer 11y ago

"The performance will suffer if the dataset is much bigger than the memory." That is a huge drawback when compared to relational databases. A good follow-up question would be: which open-source graph databases can reasonably import and store graph data that's not small -- that is, more data than fits in than RAM? Without proprietary extensions?

jerven 11y ago
Blazegraph Virtuoso Jena tdb Can easily load large to very large graphs.
reactor 11y ago
Looks like they have persistent indexes in the roadmap (ver 3.0) https://www.arangodb.com/roadmap/ https://www.arangodb.com/roadmap/ which might help.
LyndsySimon 11y ago
How much data are you dealing with? In my (admittedly limited) experience, it's usually cheaper to throw money at hardware than other options.
- rspeer 11y ago
  Throwing money on RAM because most graph databases haven't figured out how to use the disk effectively is not a good use of money. What's cheaper than buying all the RAM in the universe is figuring out a different system besides a graph database that does the job. A good example would be the graph of Wikipedia links. About 100 million edges among 5 million nodes, last I checked. The nodes have large differences in degree. The raw data for this is not the slightest bit large. We're only talking about gigabytes. But it would absolutely destroy Neo4J to even try to import it, to say nothing of running an interesting algorithm that justifies using a graph database on it, and Neo4J seems to be everyone's favorite open-source graph database for some reason.
neunhoef 11y ago
One of the developers of ArangoDB here. Let me explain this quotation. When your graph data (including indices) do no longer fit into the RAM of a single server, you can either live with the higher latency of loading data from disk or you can use sharding, which will lead to communication and therefore slower traversals. That does not mean that things stop working, but performance will be less good, you can no longer visit tens of millions of nodes per second in a traversal as in RAM on a single server. If you actually only traverse a much smaller hot subgraph, I would probably go for the disk based single server approach. If your graph has a natural known clustering, then an optimized sharding solution with fine tuned sharding keys us probably your best bet. You can do all this with ArangoDB. However, graph traversals vary greatly in many respects, and your mileage may vary accordingly, with any approach. I would love to chat in more detail about your use case.