Data Modeling: MongoDB vs ArangoDB | ArangoDB Blog
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…)
First Beta of ArangoDB 2.3: Explore New Features | ArangoDB Blog
This version is deprecated. Download the new version of ArangoDB
We are proud to present ArangoDB 2.3. The first beta version is now available for download from our web-site or you can use “brew install –unstable arangodb” under Mac OS X. You can also look into the nightly documentation for more information.
Please note that the main feature of this release contains a complete rewrite of the query engine, allowing much more optimizations than before – especially in the cluster case. It would be very helpful for us, if you could test this query engine as much as possible. If you find any unexpected behavior, please let us know.
The data-files can be upgraded from 2.x to 2.3. You should, however, backup the database directory beforehand, as this is a beta-release.
Features and improvements
The following list shows in detail which features have been added or improved in ArangoDB 2.3. ArangoDB 2.3 also contains several bug-fixes that are not listed here.
Elegant NoSQL Database Querying Methods | ArangoDB 2012
Having a long history with relational databases and having worked for a lot of years with SQL some people find it a bit inconvenient querying nosql databases e.g. via REST. Others have rather complex data models and need nevertheless an elegant and convenient way for querying. And we all love clean and simple interfaces.
ArangoDB comes with a couple of options for querying the data, among offer it implements the "ArangoDB Query Language" (AQL).
AQL is a declarative query language for simple and also very complex queries. Unless like in other nosql databases you can also query across collections, aggregate results, do some geo location stuff and even iterate over graphs.
So if you like the comfort of SQL but also the freedom of a schema free database, AQL is for you.
If you are interested in learning more about the concepts of ArangoDB checkout Jan's talk and slides.
But let's stop beating around the bush and rather have a look at specific examples.
Find the 5 regions in state CA with the most inhabitants:
FOR u IN users /* iterate over all documents in collection 'users' */
FILTER u.contact.address.state == "CA" /* filter on state attribute */
COLLECT region = u.contact.region INTO group /* group by region attribute */
SORT LENGTH(group) DESC /* sort by number of matches found, descending */
LIMIT 0, 5 /* get top 5 */
RETURN { "region" : region, "count" : LENGTH(group) } /* return a projection */
Find the other top 5 hobbies of male users that also like running
FOR likes IN ( /* iterate over result of subquery */
FOR u IN users /* iterate over all users */
FILTER u.gender == "male" && "running" IN u.likes /* filter on gender & likes contains "running" */
FOR value IN u.likes /* iterate over user's individual like values */
FILTER value != "running" /* filter out "running" here */
RETURN value
)
COLLECT what = likes INTO group /* group by like name */
SORT LENGTH(group) DESC /* sort by number of matches found, descending */
LIMIT 0, 5 /* get top 5 */
RETURN { "what" : what, "count" : LENGTH(group) } /* return a projection */
Find the 10 nearest larger airports around Cologne
FOR a IN NEAR(airports, 50.67, 6.9, 200, "distance") /* iterate over proximity search result */
FILTER a.type == "large_airport" /* filter on airport type */
SORT a.distance ASC /* sort by distance, ascending */
LIMIT 0, 10 /* get top 10 */
RETURN { "name" : a.name, "code" : a.iata_code, "country" : a.iso_country, "city" : a.municipality, "distance" : CONCAT(TO_STRING(CEIL(a.distance/1000)), ' km') }
Find some users with their friends.
FOR u IN users /* iterate over all users */
FILTER u.gender == "female" /* filter on gender */
FILTER u.contact.address.state == "CA" /* filter on state */
LIMIT 0, 5 /* limit the result */
FOR fr IN (FOR f IN friendships /* iterate over friends */
FILTER f.user == u._id /* of current user */
RETURN f.friends /* to get the list of friend ids */
)
LET friendnames = (
FOR f IN fr /* loop over list of friend ids */
FOR u2 IN users /* join with users collection again */
FILTER u2._id == f /* restrict on user with friend id */
RETURN u2.name /* return friend name */
)
RETURN { "user" : u.name, "friends" : friendnames } /* return some merged data */
RFC: The AvocadoDB Query Language | ArangoDB Blog 2012
The REST API for AvocadoDB is already available and stable and people are writing APIs using it. Awesome. As AvocacoDB offers more complex data structures like graphs and lists REST is not enough. We implemented a first version of a query language some time ago which is very similar to SQL and UNQL.
(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
- 2
- 3
Get the latest tutorials,
blog posts and news:
Thanks for subscribing! Please check your email for further instructions.