2018 has been a fantastic year for the ArangoDB project. The community has welcomed many new members, customers, supporters and friends. Together we’ve reached new “heights” – accomplished goals, shipped a big brand-new release and improved ArangoDB on all fronts. Read more
It has been a few months since we first released the Kubernetes operator for ArangoDB and started to brag about it. Since then, quite a few things have happened.
For example, we have done a lot of testing, fixed bugs, and by now the operator is declared to be production ready for three popular public Kubernetes offerings, namely Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) and Pivotal Kubernetes Service (PKS) (see here for the current state of affairs). Read more
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
For ArangoDB 3.4 we already added 100,000 lines of code, happily deleted 50,000 lines and changed over 13,000 files until today. We merged countless PRs, invested months of problem solving, hacking, testing, hacking and testing again and are super excited to share the feature complete RC1 of ArangoDB 3.4 with you today. Read more
Firstly, a huge thank you to all our customers that took the time to review ArangoDB for the Gartner Peer Insights “Voice of the Customer”: Operational Database Management Systems Market report. Without your help and assistance, the continued improvements and enhancements we make to our software wouldn’t be possible. Read more
Graph databases are often used to analyze relations within highly interconnected datasets. Social networks, recommendation engines, corporate hierarchies, fraud detection or querying a bill of materials are common use cases. But these datasets change over time and you as a developer or data scientist may want to time travel and analyze these changes.
While ArangoDB may not come with built-in support for managing the revision history of graph data, we’ll show in this article how to manage it in a performant manner for some general classes of graphs. Best of all, this won’t require any groundbreaking new ideas. We’ll simply borrow a few tools and tricks from the persistent data structure literature and adapt them for good performance within ArangoDB. We hope that this will help enable new ways to use everyone’s favorite avocado-fueled datastore, and power some useful applications. Read more
Many ArangoDB users rely on our
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
Our recent release 3.3.9 includes several performance optimizations for data retrieval cases. Benefits can be expected for both storage engines, MMFiles and RocksDB, AQL batch lookup queries, and cluster AQL queries.
MMFiles index batch lookups
For the MMFiles engine, an optimization has been made for retrieving multiple documents from an index (hash index, skiplist index or persistent index) in a batch.