It is my fav graph database. It scales more like MongoDB, so not as easily horizonal as Firestore, but not bad. For analytics, ArangoDB is pretty cool.
When you are using ArangoDB for more transactional UI stuff, it still is good - but I found an issue when using graph traversals for data sets... pagination. I think this might be an issue with all graph databases. When you do a traversal query, it would make sense that the order is deterministic - but there really isn't a good "start at". You have to traverse the whole graph regardless on each page. Maybe there is something that I was missing.
I do agree with you that Firestore really needs some query improvements. There is a lot I like about Google Cloud. What I don't like about Google is that they tend to focus only on what is trending. Firestore is still better than AWS's DynamoDB, but then there is AWS DocumentDB now. Google needs to do something here.
My main job is not in IT, but I do have a CS degree and have been programming for over 20 years (only born in 1984). I hate dealing with Servers, and want Graph Databases to be the new norm.
I don’t think all Graph databases have that problem and can index differently. My issue with Arrangodb, like Tigergraph, is the price. Need to see examples to compare. Thanks for info.
Similar to how MongoDB worked, they make money on the enterprise extras that are probably necessary for large scale deployments. However, you can roll a cluster or a single server on some compute. They also have Oasis, which is like Atlas.
All that said, I do like Firestore's pay as you grow model and GCP has a great free tier for prototyping. Most databases, if you still want performance, requires a minimum buy-in regardless of use. Sometimes the difference of a few hundred a month can pause experimental projects. I really hope Google does some nice updates to Firestore.
When you are using ArangoDB for more transactional UI stuff, it still is good - but I found an issue when using graph traversals for data sets... pagination. I think this might be an issue with all graph databases. When you do a traversal query, it would make sense that the order is deterministic - but there really isn't a good "start at". You have to traverse the whole graph regardless on each page. Maybe there is something that I was missing.
Yes. But then your next page, you are running your traversal again.
One suggestion I read is to put a key/value of a random value then run a weighted traversal using that random number as a weight. That creates a deterministic response. Helps a bit. Still, if you traverse and return 100 responses then want 101 to 200, then you are still running the full traversal.
In a SQL or NoSQL, your more likely to be skipping items on an index. That is much faster than running a traversal then skipping. If your traversal is deterministic then the second page might return unexpected results.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You might want to check out ArangoDB
arangodb.com/
It is my fav graph database. It scales more like MongoDB, so not as easily horizonal as Firestore, but not bad. For analytics, ArangoDB is pretty cool.
When you are using ArangoDB for more transactional UI stuff, it still is good - but I found an issue when using graph traversals for data sets... pagination. I think this might be an issue with all graph databases. When you do a traversal query, it would make sense that the order is deterministic - but there really isn't a good "start at". You have to traverse the whole graph regardless on each page. Maybe there is something that I was missing.
I do agree with you that Firestore really needs some query improvements. There is a lot I like about Google Cloud. What I don't like about Google is that they tend to focus only on what is trending. Firestore is still better than AWS's DynamoDB, but then there is AWS DocumentDB now. Google needs to do something here.
I don’t think all Graph databases have that problem and can index differently. My issue with Arrangodb, like Tigergraph, is the price. Need to see examples to compare. Thanks for info.
Well, it is open source with the Apache v2 license.
github.com/arangodb/arangodb
Similar to how MongoDB worked, they make money on the enterprise extras that are probably necessary for large scale deployments. However, you can roll a cluster or a single server on some compute. They also have Oasis, which is like Atlas.
All that said, I do like Firestore's pay as you grow model and GCP has a great free tier for prototyping. Most databases, if you still want performance, requires a minimum buy-in regardless of use. Sometimes the difference of a few hundred a month can pause experimental projects. I really hope Google does some nice updates to Firestore.
can’t you combine an AQL Traversal with the high-level operation LIMIT or use a FILTER to only include a subset of the ascending indexes?
Yes. But then your next page, you are running your traversal again.
One suggestion I read is to put a key/value of a random value then run a weighted traversal using that random number as a weight. That creates a deterministic response. Helps a bit. Still, if you traverse and return 100 responses then want 101 to 200, then you are still running the full traversal.
In a SQL or NoSQL, your more likely to be skipping items on an index. That is much faster than running a traversal then skipping. If your traversal is deterministic then the second page might return unexpected results.