DC/OS: Modernizing Distributed Database Management
The mission of ArangoDB is to simplify the complexity of data work. ArangoDB is a distributed native multi-model NoSQL database that supports JSON documents, graphs and key-value pairs in one database engine with one query language. The cluster management is based on Apache Mesos, a battle-hardened technology. With the launch of DC/OS by a community of more than 50 companies all ArangoDB users can easily scale. Read more
Index Free Adjacency or Hybrid Indexes for Graph Databases
Some graph database vendors propagandize index-free adjacency for the implementation of graph models. There has been some discussion on Wikipedia about what makes a database a graph database. These vendors tried to push the definition of index-free adjacency as foundation of graph databases, but were stopped by the community.
Read more
Benchmark: PostgreSQL, MongoDB, Neo4j, OrientDB and ArangoDB
In this blog post – which is a roundup of the performance blog series – I want to complete the picture of our NoSQL performance test and include some of the supportive feedback from the community. First of all, thanks for all your comments, contributions and suggestions to improve this open source NoSQL performance test (Github). This blog post describes a complete overhaul of the test with no need to read all the previous articles to get the picture – have a look at the appendix below to get all the details on hard- and software, the dataset and tests, used in this NoSQL performance comparison. Read more
Multi-Model Benchmark: Round 1 Results | ArangoDB Blog
It’s time for another update of my NoSQL performance blog series. This hopefully concludes the first part of this series with the initial databases ArangoDB, MongoDB, Neo4J and OrientDB and I can now start to check out other databases. I’m getting a lot of requests to test others as well and I’ll try to add them as soon as possible. Pull requests to my repository are also more than welcome. Remember it is all open-source.
The first set of benchmarks was started as a proof that multi-model can compete with specialized solutions and I started with the corresponding top dogs (Neo4J and MongoDB) for graphs and documents. After the first blog post, we were asked by the community to include OrientDB as the other multi-model database, too, which makes sense and therefore I expanded the initial lineup.
Concluding the tests did take a bit longer than expected, because vendors took up the challenge and improved their products with impressive results – as we asked them to do. Still, for each iteration we needed some time to run all tests, see below. However, on the upside, everyone can benefit from the improvements, which is an awesome by-product of the benchmark tests. (more…)
Performance Comparison: ArangoDB vs MongoDB, Neo4j, OrientDB
My recent blog post “Native multi-model can compete” has sparked considerable interest on HN and other channels. As expected, the community has immediately suggested improvements to the published code base and I have already published updated results several times (special thanks go to Hans-Peter Grahsl, Aseem Kishore, Chris Vest and Michael Hunger).
Please note: An update is available (June ’15) and a new performance test with PostgreSQL added.
Here are the latest figures and diagrams:
The aim of the exercise was to show that a multi-model database can successfully compete with special players on their own turf with respect to performance and memory consumption. Therefore it is not surprising that quite a few interested readers have asked, whether I could include OrientDB, the other prominent native multi-model database.
Multi-Model Benchmark: Assessing ArangoDB’s Versatility
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.
Feel free to comment, join the discussion on HN and contribute – it’s all on Github.
ArangoDB in San Francisco: Exciting Developments & Events
Join parts of the ArangoDB team in San Francisco. Max and Claudius are visiting the Bay Area from mid-February till end of March. Starting with the StrataConf in San Jose, Feb 17–20, 2015 Max and Claudius want to meet people, start cooperations, visit meetups and tell people in the Bay Area about ArangoDB.
If you know any hackerspaces we definitely should go, drop us a line and we will try to be there. We would be happy to see some of you guys in person and to respond to every question you may have about ArangoDB.
Elasticsearch Plugin: ArangoDB Integration | ArangoDB ’13
ArangoDB River Plugin for ElasticSearch
ArangoDB offers now a plugin for automated data transfer from ArangoDB into ElasticSearch.
If you want to benefit from ElasticSearch’s full text search capabilities for your ArangoDB document data, the easiest way to do so is to use this new plugin.
Implementing the push approach, otherwise, would make it necessary to write your own indexer, using your favorite programming language.
The ArangoDB river plugin software is an initial alpha version and licensed under the Apache 2 license.
(more…)
Is UNQL Dead? Future of NoSQL Query Languages | ArangoDB Blog 2012
UNQL started with quite some hype last year. However, after some burst of activity the project came to a hold. So it seems, that – at least as a project – UNQL has been a failure. IMHO one of the major issues with the current UNQL is, that it tries to cover everything in NoSQL, from key-value stores to document-stores to graph-database. Basically you end up with greatest common divisor – namely key-value access. But with graph structures and also document-structures you really want to supports joins, paths or some sort of sub-structures.
Apart from all the technical and theoretical benefits of SQL and what advantages the underlying theory has to offer, the major plus from an users point of view is that it is readable. You simple can see an SQL statement – be it in C, Java, Ruby – and understand what is going on. It is declarative, not imperative. With other imperative solution, like a fluent interface or a map-reduce, you need to understand the underlying syntax or language. With SQL you only need to understand English – at least most of the time.
And here I think is where UNQL is totally right. We need something similar for the NoSQL world. But it should not try to be a “fits all situation”. It should be a fit for 80% of the problems. For simple key-values stores a fluent-interface is indeed enough. For very complex graph traversals a traversal program must be written. For very complex map-reduces you might need to write a program – but check out Google’s talk (www.nosql-matters.org/program) about NoNoSQL. There they describe why they are developing a SQL-like interface for Map/Reduce.
In my experience most of the time you have a set of collections holding different “types” of documents with some relations between them. One of the biggest advantages of document stores or graph databases is that you can have lists and sub-objects. The problem with SQL is, that it has no good way to deal with these structures. So I believe UNQL would be quite successful if it would concentrate on these strong advantages of NoSQL, instead of trying to unify everything – especially after hear Jan’s talk about a document query language at the NoSQL Cologne UG (an English version is also available).
- « Previous
- 1
- …
- 3
- 4
- 5
Get the latest tutorials,
blog posts and news: