fceller's comments

Thanks a lot for the suggestion. We have used http://pgtune.leopard.in.ua I have appended the resulting config.

The result is that the default config is already very good for our benchmark. There is no visible difference between the old and new config when running the benchmark. We will publish an update to the blog post and show the numbers using the tuned config.

best Frank

DBVersion: 10 Linux, Type: "Mixed type of Applications" 122GB RAM 25 Connections SSD Storage

=>

max_connections = 25 shared_buffers = 31232MB effective_cache_size = 93696MB work_mem = 639631kB maintenance_work_mem = 2GB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100 random_page_cost = 1.1

Hi, it's Frank from ArangoDB. We have now included the starter in the package. It is now possible to start a cluster with a single command line. For example, to start a test cluster on a single machine, "arangodb --starter.local" is all you need to type. Starting on 3 machines requires a "arangodb" on the first machine and "arangodb --dataDir=./dbX --join serverX1" on the others.

You can active the dev mode for a Foxx app. This way any change will be directly visible without the need of replace.

We are closely monitoring the development. Not being a Java database, we cannot run Java queries natively. Tinkerpop3 has added some hooks for non-Java, but it would still very hard to get the speed of AQL. But I hope that Tinkerpop will open up to non-Java even more.

You can use the Foxx framework to create a REST api that suits your needs. There is also a community project for an ORM, see https://github.com/arangodb/arangojs/issues/215

However, in general it is more flexible and safer to use Foxx, because it allows you to fine tune complexes queries and supports transactions.

yes, using 1000 shards would work. Eventually, we will also support splitting shards.

Hi, I'm Frank from ArangoDB. You should create a number of shards that is much higher than your initial number of servers. ArangoDB can cope with multiple shards per server. This way, you can easily redistribute shards when adding new servers.

We are evaluating various possibilities, how to implement streaming queries in an efficient and scalable way. For instance, are restrictions to the general AQL necessary for such queries to be able to scale? Stay tuned.

That is one of the reason, why I renamed it the LINENOISE NG. The interface is compatible with the original LINENOISE, but it works on linux, Mac and Windows and it supports UTF-8.

Another reason is Windows. Even READLINE breaks when used on Windows with UTF-8 characters.

Or maybe meant as a pun?

I would love to see contributions improving LINENOISE NG in this direction.

+1

There are even a lot of other OPEN SOURCE projects with licenses (Apache, BSD) which cannot use readline because of their restricted GPL (instead of LGPL).

Why? I assume there are good reasons for not being GPL. Redis for example is BSD. But it cannot use readline because of it is not LGPL.

No, it has a fixed key binding.

Yes, it is a shame that there are so many programs out there, that do not provide good line support because of the GPL issue.

I'm Frank, CTO of ArangoDB. As such I'm totally biased :-)

You should also have a look at www.arangodb.com

Hi, this Frank from ArangoDB again. We've not added absolute times because it strongly depends of your machines, network. For the setup we have used, the baseline (ArangoDB) is as follows: shortest path 0.5 sec, neighbors 0.15 sec, single read 26 sec, single write 27 sec, aggregations 1.4 sec, memory 12.5 GByte. Therefore a 16 GByte machine should have been enough. But we did not know beforehand, therefore we selected the biggest machine from GCE available to us (thanks to Google for giving us credits to use the machines for free).

I agree never trust a benchmark. It really all depends on your use case. If you have ideas for improvements, we would love to hear about them. Also if you have any idea how to improve the mongodb or neo4j queries, please check-out github and let us know.

Basically for me, it has two aspects: first the storage engine is designed to handle all models natively. second you have a common query language which is supported by the database storage engine.

There are different approaches, which are used in other products and which can also work well. For example, you can restrict the database engine to a pure key/value store and add different personalities to it. Or you have a client which implements a common query language for different products.

Hi amirouche, I'm Frank, CTO of ArangoDB. Claudius benchmark looked at queries occurring a typical social network project. The tests shows that wiredtiger is indeed a bit faster for reads and writes. The neighbors of neighbors is typically a question you would ask a graph database, not a a document store. Therefore, you would set-up two databases and ask MongoDB the document questions and Neo4J the graph questions. If you use a native multi-model approach, you only need to setup, maintain one database. The response times for example for reads and shortest paths are comparable to the specialized solutions.

For the technical difference at storage level: graphs and documents model are in my opinion a perfect match, because a vertex (and an edge for that matter) can be stored as ordinary documents. This allows you to use any document query you have in a document (give me all users, which live in Denver) and start graph queries from the vertices found in this manner (give me their 1 and 2 level friends).