RocksDB Archives - ArangoDB

Sign up for ArangoGraph Insights Platform

Before signing up, please accept our terms & conditions and privacy policy.

What to expect after you signup
You can try out ArangoDB Cloud FREE for 14 days. No credit card required and you are not obligated to keep using ArangoDB Cloud.

At the end of your free trial, enter your credit card details to continue using ArangoDB Cloud.

If you decide that ArangoDB Cloud is not (yet) for you, you can simply leave and come back later.

ACCEPT

Upcoming ArangoDB 3.7 and Storage Engines

10GeneralTags: ,

Estimated reading time: 4 minutes

TL;DR

ArangoDB has supported two storage engines for a while: RocksDB and MMFiles. While ArangoDB started out with just the MMFiles storage engine in its early days, RocksDB became the default storage engine in the 3.4 release. Due to its drawbacks ArangoDB 3.6 deprecated the old MMFiles storage engine and with the upcoming 3.7 release we plan to fully remove support. This blog post will provide the background of why storage engines matter, why we chose to deprecate the MMFiles storage engine, and what you should be aware of when migrating from MMFiles to the RocksDB storage engine. Read more

ArangoDB 3.4 GA
Full-text Search, GeoJSON, Streaming & More

00General, ReleasesTags: , , , ,

The ability to see your data from various perspectives is the idea of a multi-model database. Having the freedom to combine these perspectives into a single query is the idea behind native multi-model in ArangoDB. Extending this freedom is the main thought behind the release of ArangoDB 3.4.

We’re always excited to put a new version of ArangoDB out there, but this time it’s something special. This new release includes two huge features: a C++ based full-text search and ranking engine called ArangoSearch; and largely extended capabilities for geospatial queries by integrating Google™ S2 Geometry Library and GeoJSON.  Read more

Speeding Up Dump & Restore

00GeneralTags: ,

Many ArangoDB users rely on our arangodump and arangorestore tools as an integral part of their backup and recovery procedures. As such, we want to make the use of these tools, especially arangodump, as fast as possible. We’ve been working hard toward this goal in preparation for the upcoming 3.4 release.

We’ve made a number of low-level server-side changes to significantly reduce overhead and improve throughput. Additionally, we’ve put some work into rewriting much of the code for the client tools to allow dumping and restoring collections in parallel, using a number of worker threads specified by --threads n. Read more

Index types and how indexes are used in ArangoDB: Part II

00GeneralTags: , ,

In the first part of this article we dived deep into what indexes are currently available in ArangoDB (3.2 and 3.3), also briefly looking at what improvements are coming with ArangoDB 3.4. Read Part I here.

In this Part II, we are going to focus on how to actually add indexes to a data model and speed up specific queries.

Adding indexes to the data model

The goal of adding an extra index to the data model is to speed up a certain query or even multiple queries.

One of the first things that should be done during development of AQL queries should be to review the output of the explain command. A query can be explained using ArangoDB’s WEB UI or from the ArangoShell. In the ArangoShell it is as simple as db._explain(query), where query is the AQL query string. To explain a query which also has bind parameters, they need to be passed separately into the command, e.g. db._explain(query, bindParameters).
Read more

How We Wronged Neo4j & PostgreSQL: Update of ArangoDB Benchmark 2018

00GeneralTags: , ,

Recently, we published the latest findings of our Performance Benchmark 2018 including Neo4j, PostgGreSQL, MongoDB, OrientDB and, of course, ArangoDB. We tested bread & butter tasks in a client/server setup for all databases like single read/write and aggregation, but also things like shortest path queries which are a speciality for graph databases. Our goal was and is to demonstrate that a native multi-model database like ArangoDB can at least compete with the leading single model databases on their home turf.

Traditionally, we are transparent with our benchmarks, learned plenty from community feedback and want to keep it that way. Unfortunately, we did something wrong in our latest version and this update will explain what happened and how we fixed it. Read more

Index types and how indexes are used in ArangoDB: Part I

00GeneralTags: , ,

As in other database systems, indexes can be used in ArangoDB to speed up data retrieval queries, sometimes by many orders of magnitude. Getting the indexes set up the right way is essential for good query performance, so this is an important topic that affects most ArangoDB installations.

This is Part I of how indexes are used by ArangoDB where we discuss what types of indexes are available in the database. In Part II, we will dig deeper into how to actually add indexes to a data model and speed up specific queries. Read Part II here. Read more

NoSQL Performance Benchmark 2018 – MongoDB, PostgreSQL, OrientDB, Neo4j and ArangoDB

010GeneralTags: , ,

ArangoDB, as a native multi-model database, competes with many single-model storage technologies. When we started the ArangoDB project, one of the key design goals was and still is to at least be competitive with the leading single-model vendors on their home turf. Only then does a native multi-model database make sense. To prove that we are meeting our goals and are competitive, we run and publish occasionally an update to the benchmark series. This time we included MongoDB, PostgreSQL (tabular & JSONB), OrientDB and Neo4j.
Read more