As promised in one of the previous posts, here are some performance results that show the effect of different journal sizes for insert, update, delete, and get operations in ArangoDB.

Why journal size could matter

The journal file sizes determine how large a single datafile in ArangoDB is. The smaller that parameter is, the more datafiles need to be created, initially prefilled, closed, compacted etc.. These operations do have some overhead per file, and they occur more often the more datafiles are being used.

We are on the road again and are invited to give a talk at the “nosql matters”  in Barcelona. This is a one day conference in an amazing looking venue (UNESCO world heritage).

In the last couple of posts, we have been looking at ArangoDB’s insert performance when using individual document insert, delete, and update operations. This time we’ll be looking at batched inserts. To have some reference, we’ll compare the results of ArangoDB to what can be achieved with CouchDB and MongoDB.

To easily conduct bulk insert benchmarks with different NoSQL databases, we wrapped a small benchmark tool in PHP. The tool can be used to measure the time it takes to bulk upload data into MongoDB, CouchDB, and ArangoDB using the databases’ bulk documents APIs.The tool can also measure datafile sizes after the bulk load. The tool will upload documents to the databases in chunks, without concurrency (remember, this is PHP). It will report the total time needed, plus the amount of time needed for the database operations only (some of the total time might be spent in data generation etc., this..

In a comment to the last post, there was a request to conduct some benchmarks with a mixed workload that does not test insert/delete/update/get operations in isolation but when they work together.

We just came back from FroSCon, a large, international open source conference near Bonn, Germany. Jan Steemann, one of the core developers of ArangoDB, had a talk on modelling data in a schema-free world. Jan was given the largest room in the conference for this talk, fortunately a lot of people showed up and even stayed ;-).

You can find Jan’s presentation below.

A side-effect of measuring the impact of different journal sizes was that we generated some performance test results for CouchDB, too. They weren’t included in the previous post because it was about journal sizes in ArangoDB, but now we think it’s time to share them.

Test setup

The test setup and server specification is the one described in the previous post. In fact, this is the same test but now also including data for CouchDB.

A while ago we wrote some blog article that explained how ArangoDB uses disk space. That article compared the disk usage of ArangoDB, CouchDB, and MongoDB for loading some particular datasets. In this post, we’ll show in more detail the disk usage of ArangoDB for insert, update, and delete operations. We’ll also compare it to CouchDB for reference.

Note: Our new official nodejs driver is arangojs. You also can look at this blogpost about the new driver.

We got a note from Anders Elo from Sweden. He told us that he has released a ArangoDB client for node.js. Awesome! 🙂 You can find it on Github under the URL https://github.com/kaerus/arango-client. To install locally

In the previous post we published some performance results for ArangoDB’s HTTP and networking layer in comparison to that of some popular web servers. We did that benchmark to assess the general performance (and overhead) of the network and HTTP layer in ArangoDB.

Using ArangoDB as an application server

While HTTP is a good and (relatively) portable mechanism of shipping data between clients and servers, it is only a transport protocol. People will likely be using ArangoDB not only because it supports HTTP, but primarily because it is a database and an application server.In this post, we’ll..