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.
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.
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.
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.
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.
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.
21 comments
[ 4.5 ms ] story [ 15.1 ms ] threadDo 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?
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.
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://github.com/arangodb/graphql-sync
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.
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.
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.
https://github.com/solher/arangolite
https://github.com/diegogub/aranGO
Only arangolite is officially compatible with 3.1 at the moment though.