ArangoDB 3.1 – A Solid Ground to Scale Part II(arangodb.com)
arangodb.com
ArangoDB 3.1 – A Solid Ground to Scale Part II
https://www.arangodb.com/2016/11/arangodb-3-1-solid-ground-scale-part-ii/
9 comments
I've not used ArangoDB in any serious way. However, the co-founder and a lead engineer met with me in Seattle this week, and these guys are clearly very, very experienced serious engineers. They wanted to pick my brain about what to focus on regarding changefeeds, since I have experience using changefeeds in production via RethinkDB, and the ArangoDB devs hope to implement some variant of changefeeds soon. I also found out that ArangoDB's functionality is motivated by the founder's decade of experience building custom highly efficient software for companies; e.g., this is why the ArangoDB index is optimized to be entirely in memory. Their devs also have a strong interest in innovating on new algorithms, in addition to implementing known algorithms.
One thing that didn't make it into the announcement: using GraphQL in ArangoDB is now even easier:
https://docs.arangodb.com/3.1/Manual/Foxx/GraphQL.html
EDIT: Also there is now a built-in OAuth2 client:
https://docs.arangodb.com/3.1/Manual/Foxx/OAuth2.html
https://docs.arangodb.com/3.1/Manual/Foxx/GraphQL.html
EDIT: Also there is now a built-in OAuth2 client:
https://docs.arangodb.com/3.1/Manual/Foxx/OAuth2.html
... Except GraphQL in arangodb is based on `graphql-sync` which hasn't been updated in more than 6 months...
https://github.com/arangodb/graphql-sync
https://github.com/arangodb/graphql-sync
Fair point. The GraphQL integration was completed fairly early into the development of ArangoDB 3.1 and we had to prioritize other tasks over the maintenance of our sync wrapper to graphql-js.
I'll try to push out releases for 0.6 and 0.7 next week. Since 0.6 didn't introduce any breaking changes we should be able to update the bundled version to 0.6.2 with the next 3.1 bugfix releases but 0.7 (or 0.8 if it's out of beta) will have to wait until 3.2 due to the backwards incompatible changes.
Keep in mind that it will still be possible to use newer versions of graphql-sync directly, you just miss out on the Foxx/GraphQL integration as graphql-js relies on `instanceof` checks.
Also, the GraphQL integration literally fits in a single file and doesn't rely on any ArangoDB internals (just the Foxx router) so it will be possible to add your own copy of it to your code when the new version of graphql-sync is out.
I'll try to push out releases for 0.6 and 0.7 next week. Since 0.6 didn't introduce any breaking changes we should be able to update the bundled version to 0.6.2 with the next 3.1 bugfix releases but 0.7 (or 0.8 if it's out of beta) will have to wait until 3.2 due to the backwards incompatible changes.
Keep in mind that it will still be possible to use newer versions of graphql-sync directly, you just miss out on the Foxx/GraphQL integration as graphql-js relies on `instanceof` checks.
Also, the GraphQL integration literally fits in a single file and doesn't rely on any ArangoDB internals (just the Foxx router) so it will be possible to add your own copy of it to your code when the new version of graphql-sync is out.
By the by, graphql-sync has been updated in the 3.1 branch and the updated version will ship with the upcoming 3.1.1 bugfix release.
This is fantastic news.
That's great news. I tried the RC version 3.1 a while ago and especially like the new graph viewer. Much better than the one in 3.0 and seems to handle big graphs now.
New graph viewer and AQL editor in 3.1 are really good IMHO.
How much effort do I have to invest to get a glimpse on the new graph viewer?
Do I have to deploy a new ArangoDB 3.1 and generate some test data myself or is there a demo available for a first impression?
Do I have to deploy a new ArangoDB 3.1 and generate some test data myself or is there a demo available for a first impression?
Can also use the movie database example graph made famous by Neo4J.
I have adapted it for use in ArangoDB:
https://github.com/jsteemann/movie-database
ArangoDB ships with several example graphs so you don't have to come up with your own test data if you just want to explore the graph features.
Any numbers available re performance improvements due to binary Velocypack/Velocystream transport??
There isn't yet any benchmark result for this from ArangoDB.
However, we already adjusted our Java driver to use VelocyPack instead of JSON internally and VelocyStream for the client-server communication. This has led to quite some performance improvements in the YCSB benchmarks we ran. But to be fair, some of those are also due to some other refactoring work for the driver.
So it's still a to-do to run a proper benchmark for this soon.
However, we already adjusted our Java driver to use VelocyPack instead of JSON internally and VelocyStream for the client-server communication. This has led to quite some performance improvements in the YCSB benchmarks we ran. But to be fair, some of those are also due to some other refactoring work for the driver.
So it's still a to-do to run a proper benchmark for this soon.
Is it still badly documented and near impossible to setup a cluster?
Single node performance is good. Jespen tests are there. But devops says no. After two days they simply couldn't get it to run it in a cluster. So for now we switched back to ES for AP stuff and Rethink for CP stuff.
Single node performance is good. Jespen tests are there. But devops says no. After two days they simply couldn't get it to run it in a cluster. So for now we switched back to ES for AP stuff and Rethink for CP stuff.
I made it run in a cluster over docker swarm 7 days ago and it was fine ! Actually really nice experience !
That seems to be the type of answer they too believe to be appropiate. UsIng hipster day of week infrastructure like dc/os.
And how about a normal infrastructure? Like OpenStack and Ansible or dedicated servers? We can't have a database dictate our infrastrucure like that, but more to the point: the fact that it thinks it needs to shows a worrisome lack of competence and sense of responsibility.
Its a database. It should run everywhere rather than require exotic tools and parts that likely wont be maintained or be compatible in 3 to 5 years.
To put it simply: we have more and other challenges that actually pay the bills -- for a database we should feel like we can install it into any setup.
And how about a normal infrastructure? Like OpenStack and Ansible or dedicated servers? We can't have a database dictate our infrastrucure like that, but more to the point: the fact that it thinks it needs to shows a worrisome lack of competence and sense of responsibility.
Its a database. It should run everywhere rather than require exotic tools and parts that likely wont be maintained or be compatible in 3 to 5 years.
To put it simply: we have more and other challenges that actually pay the bills -- for a database we should feel like we can install it into any setup.
This looks great. An official Go driver would be even more awesome though!
Sadly the core team can't maintain drivers for all languages and environments but two awesome people have contributed community Go drivers:
https://github.com/solher/arangolite
https://github.com/diegogub/aranGO
Only arangolite is officially compatible with 3.1 at the moment though.
https://github.com/solher/arangolite
https://github.com/diegogub/aranGO
Only arangolite is officially compatible with 3.1 at the moment though.
a great release