More than two years ago, we compared the bulk insert performance of ArangoDB, CouchDB and MongoDB in a blog post.

The original blog post dates back to the times of ArangoDB 1.1-alpha. We have been asked several times to re-run the tests with the current versions of the databases. So here we go.

Test setup

We have again used the PHP bulk insert benchmark tool to generate results for MongoDB, CouchDB, and ArangoDB. The benchmark tool uses the HTTP bulk documents APIs for CouchDB and ArangoDB, and the binary protocol for MongoDB (as MongoDB does not have an HTTP bulk API). The benchmark tool was..

With ArangoDB 2.3 now getting into the beta stage, it’s time to spread the word about new features and improvements.

Measuring ArangoDB insert performance

ArangoDB offers a few APIs to insert documents. First, there is an HTTP API for bulk document imports. This API was already covered in another post. In general, the bulk import API should always be used when the task is to create many documents into a collection at once, as fast as possible. This works well if the documents are known in advance, e.g. when importing data from a file.

The folks over at MongoDB have an article on their site on Comparing MongoDB and CouchDB.They write:

“We are getting a lot of questions “how are mongo db and couch different?” It’s a good question: both are document-oriented databases with schemaless JSON-style object data storage. Both products have their place — we are big believers that databases are specializing and “one size fits all” no longer applies.”

The same applies to ArangoDB, we meet a lot of people especially developers using MongoDB who are interested in ArangoDB and ask us how it is different than other popular nosql..

ArangoDB 1.1 will come with a new API for batch requests. This batch request API allows clients to send multiple requests to the ArangoDB server inside one multipart HTTP request. The server will then decompose the multipart request into the individual parts and process them as if they were sent individually. The communication layer can sustain up-to 800.000 requests/second – but absolute numbers strongly depend on the number of cores, the type of the requests, network connections and other factors. More important are the relative numbers: Depending on your use-case you can reduce..

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.

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.

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.