janemanos

Hi @ahachete and thanks for your feedback to our benchmark 2018. We worked it into an update, please find it here: https://news.ycombinator.com/item?id=16473117

Hi Max.. thanks also for your feedback. We worked it into an update to the benchmark, please find it here: https://news.ycombinator.com/item?id=16473117

Hey Jake... thanks again for your feedback... we just published an update to the Benchmark following your feedback for Neo4j, please find it here: https://news.ycombinator.com/item?id=16473117

We just published an Update to the Benchmark, please find it here: https://news.ycombinator.com/item?id=16473117

Thanks a lot

Jan from ArangoDB here... true, and we know that it is a thin line to publish benchmark results when you're a vendor. But hope to at least provide a boilerplate for own tests and show that just because a db is multi-model, doesn't mean it has to be slow

True, benchmarking is really not trivial. Thanks for pointing us to the bug in our benchmark suite and sorry for our mistake. We fixed it https://github.com/weinberger/nosql-tests/pull/24 and reran the benchmark. We will publish an update soon and also fix the stats in the original post. Indeed, Neo4j with connection pooling improved stats in a few test cases but the overall ranking is not really affected.

Thanks again for helping us to improve the benchmark and creating fair conditions for all products tested!

Here you go: https://docs.google.com/spreadsheets/d/1_unaj2x_NCVNUHcxwMUV... Let me know if you have any question or need something else

Jan from ArangoDB here:

Did you read the appendix?

"We used a TCP/IP connection pool of up to 25 connections, whenever the driver permitted this. All drivers seem to support this connection pooling, except Neo4j. We sent instead twenty-five requests via NodeJS to Neo4j."

Just to avoid unfair conditions now, if connection pooling is possible with the neojs driver, then you would have to configure the benchmark scripts to not send 25 requests via Node as well.

We tricked ourselves with such stuff when preparing the benchmark.

Which DB operations included into the test is not something you also might have to perform with neo4j?

If you know how to write the shortest path query for Postgres, team ArangoDB would be happy to include it into the next update

Think it's also a question of effort involved for testing even more stores

In your 2015 article, you criticized that the ArangoDB team restarted the instances after each test run. In this 2018 edition, they don't do this anymore.

Jan from ArangoDB here... please note that this is a milestone release of ArangoDB 3.4 and ArangoSearch is fully tested but not yet production ready! The title here on HN might be misleading

Thanks for the article. Seems like a good appeoach to combine the strenghts of both graph & Hadoop. Wonder which other, in addtion to the described ones, use cases could be suitable here.

Anyone an idea?

Release looks cool! DC2DC opens many doors... but why the hack do you release on a Friday before Christmas?

So cool!

Haha! This is fun!

Maybe I'll see commercial fusion within my lifetime... how nice is that!

Jan from ArangoDB here

Sounds cool, let's talk :) feel free to ping me jan.stuecke at ...

Think it will happen. Sooner or later

Yes, and the tech giant are the only ones with enough users to let content producers reach an audience of relevance. Think that was the point the author tried to make, describing the switch from "content" to "audience". Content producers for films, music, and other expensive pieces do not have enough power anymore to reach a large enough audience to make a profit

Really don't see a sensible margin that can be given back to passengers. If you make 2-3$ per seat sold, then you already double the profit by selling a coke to passengers.

Will be interesting to see what people will do with all that new stuff

Back in the sixties some scientist said "Fusion is ready in 20 years", then in the eighties some others said it again, and in the 2000's the next ones... but hey, I don't care how long it will take as long as humankind strives for such stuff I'm fine

With ArangoDB you can choose between synchronous replication and asynchronous. With the Agency of ArangoDB you also have a RAFT based consensus protocol which holds the state of the cluster. My team mate wrote a nice article about our approach. You might want to have a look: https://www.arangodb.com/2017/01/reaching-harnessing-consens.... In single instance you have full transactional guarantees with multi collection and multi document transactions. In cluster mode we provide single document transactions. More guarantees will follow.

Sounds like something ArangoDB could be a good solution for. Full disclosure I'm from ArangoDB team and happy to help. If you like just drop me a line to jan.stuecke (at) arangodb.com

We had to implement some preparations for the new storage engine in 3.1 which included changes in the WriteAheadLog. E.g. this consumed additional RAM. With 3.2 the memory needs are much lower as we put in some additional improvements.

We are on our way! Plan to release RocksDB implementation with a next alpha end of this month...

You could also have a look at ArangoDB. Open-source with Apache2, Cpp-based and some neat features like Foxx framework. It's open-source with Apache2 license and I have to say their support is pretty impressive. Worth giving it a spin.