At ArangoDB we’ve got many requests for running our database on Kubernetes. This makes complete sense since Kubernetes is a highly popular system for deploying, scaling and managing containerized applications.
Running any stateful application on Kubernetes is a bit more involved than running a stateless application, because of the storage requirements and potentially other requirements such as static network addresses. Running a database on Kubernetes combines all the challenges of running a stateful application, combined with a quest for optimal performance.
This article explains what is needed to run ArangoDB on Kubernetes and what we’re doing to make it a lot easier. Read more
Cluster Administration course will take you all the way from concept and anatomy of the ArangoDB cluster to maintenance, resilience and troubleshooting of your distributed environment.
When data size or workload makes purchasing of a single database server prohibitive one needs to rethink the system architecture and consider to cluster a farm of more affordable machines. While ArangoDB clusters bring additional added value like seamless runtime scaling and thin provisioning, their management can look testy and challenging. Read more
Active failover: basic setup
Historically, ArangoDB-PHP has been able to connect to a single ArangoDB endpoint, i.e. one combination of IP address and port number.
To connect to an ArangoDB server that is running on localhost or on a remote server, simply set the
OPTION_ENDPOINT item in the
ConnectionOptions and connect: Read more
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
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.
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
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
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 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), OrienDB and Neo4j.