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
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.
“By developers for developers” has been our internal motto since the first lines of ArangoDB code. Building an open-source project at such level of complexity and at a market competitive standard, undoubtedly puts a lot of pressure and almost solely relies on the support and trust of the community.
Every victory counts, be it small appreciation or big success – it’s what gives us inspiration and keeps us going forward. A while ago we’ve been having one of those rainy gray days here in Cologne. Receiving over 10 stars put a smile on faces of our whole team, motivating us to hack harder, brainstorm, bug fix, build, release…
Tuesday, May 16th (6PM CEST/12PM ET/ 9AM PT) – Join the webinar here.
This webinar gives a general overview of the multi-model database movement, in particular we will discuss its main advantages and technological benefits from an architect and devops perspective.
Since the first relational databases were invented the needs of companies and the technological possibilities have changed completely. Luca Olivari (recently announced President of ArangoDB) will deep dive into current trends in the database world, how native multi-model databases help companies of all sizes, and walk you through use cases where ArangoDB is beneficial. He will share decades of experience in the field and views on ever-changing needs of developers, companies and customers in the modern times. Read more
Claudius Weinberger, CEO ArangoDB
TL;DR Native multi-model databases combine different data models like documents or graphs in one tool and even allow to mix them in a single query. How can this concept compete with a pure document store like MongoDB or a graph database like Neo4j? I myself and a lot of folks in the community asked that question.
So here are some benchmark results: 100k reads → competitive; 100k writes → competitive; friends-of-friends → superior; shortest-path → superior; aggregation → superior.
Here is a slideshare and recording of my talk about multi-model databases, presented in Santa Clara earlier this month.
Abstract: Recently a new breed of “multi-model” databases has emerged. They are a document store, a graph database and a key/value store combined in one program. Therefore they are able to cover a lot of use cases which otherwise would need multiple different database systems. This approach promises a boost to the idea of “polyglot persistence“, which has become very popular in recent years although it creates some friction in the form of data conversion and synchronisation between different systems. This is, because with a multi-model database one can enjoy the benefits of polyglot persistence without the disadvantages.
In this talk I will explain the motivation behind the multi-model approach, discuss its advantages and limitations, and will then risk to make some predictions about the NoSQL database market in five years time. (more…)
If you are interested in NoSQL and come from France, the NoSQL matters conference in Paris is your place to go. ArangoDB contributes with a workshop and a talk and is a silver sponsor of the conference as well. You can meet our team at the exhibition space and ask your ArangoDB questions in person.
Tickets are available for both days, starting at €299 for the conference pass.
Anyway, come and meet us at the historical Tapis Rouge venue in the heart of Paris city!
Building Single Page Applications with Angular.JS and Foxx
Workshop on March, 26th
In this training session we will build a simple single page application. Showing you how to use Angular.JS and what is a good way to define your model using Foxx.
Polyglot Persistence & Multi-Model NoSQL Databases
Talk on March, 27th (10 am)
In many modern applications the database side is realized using polyglot persistence – store each data format (graphs, documents, etc.) in an appropriate separate database. This approach yields several benefits, databases are optimized for their specific duty, however there are also drawbacks:
- keep all databases in sync
- queries might require data from several databases
- experts needed for all used systems
A multi-model database is not restricted to one data format, but can cope with several of them. In this talk i will present how a multi-model database can be used in a polyglot persistence setup and how it will reduce the effort drastically.
MongoDB is a document DB whereas ArangoDB is a multi-model DB supporting documents, graphs and key/values within a single database. When it comes to data modeling and data querying, they pursue somewhat different approaches.
In a Nutshell: In MongoDB, data modeling is “aggregate-oriented”, avoiding relations and joins. On the other side, everybody has probably used relational databases which organize the data in tables with relations and try to avoid as much redundancy as possible. Both approaches have their pros and cons. ArangoDB is somewhat in-between: You can both model and query your data in a “relational way” but also in an “aggregate-oriented way”, depending on your use case. ArangoDB offers joins, nesting of sub-documents and multi-collection graphs. (more…)
CAP & Google Spanner: the survival of eventual consistency – A response to Dave Rosenthal’s article on Gigaom –
In Next gen NoSQL: The demise of eventual consistency a recent post on Gigaom FoundationDB founder Dave Rosenthal proclaims the demise of eventual consistency. He argues that Google Spanner “demonstrates the falsity of a trade-off between strong consistency and high availability”. In this article I show that Google Spanner does not disprove CAP, but rather chooses one of many possible compromises between total consistency and total availability. For organizations with a less potent infrastructure than Google other compromises might be more suitable, and therefore eventual consistency is still a very good idea, even for future generations of nosql databases.
Get the latest tutorials,
blog posts and news:
Thanks for subscribing! Please check your email for further instructions.