ArangoDB at NoSQL Matters Berlin, Buzzwords, or Euruko | 2012
Just a quick note: We are on the road… you can meet us in person at the following conferences:
(more…)
JSON Parser for mruby: Class Definitions | ArangoDB Blog 2012
MRuby is progressing quite rapidly, it is now possible to implement a real REPL, see github. So, it is time to continue my efforts to integrate MRuby into ArangoDB. ArangoDB currently uses JavaScript to implement transactions and enrich the database with small Actionlets, i. e. functions that take a HTTP request and produce a HTTP response. Additionally, there is a shell, which allows you to administrate the server. (more…)
AvocadoDB Becomes ArangoDB | ArangoDB Blog 2012
Hi folks,
to avoid legal issues with some other Avocado lovers we have to change the name of our database. We want to stick to Avocados and selected a variety from Mexico/Guatemala called “Arango”.
(more…)
Talk: Using mruby with AvocadoDB | ArangoDB Blog 2012
Frank has given a short lightning talk on using mruby in ArangoDB (at this time still called AvocadoDB) at the Cologne Ruby user group.
(more…)
Preliminary Performance Tests: mruby & V8 | ArangoDB Blog 2012
I’m still investigating the possibility to use mruby as embedded language for AvocadoDB, see me last post. I managed to create an interactive shell to play with mruby. Now am trying to do some performance tests.
(more…)
Towards an Interactive mruby Shell | ArangoDB Blog 2012
In my last post I investigated the possibility of using mruby as embedded language for AvocadoDB. As the first results look quite promising I decided to write a small interactive mruby shell. There is no better way to explore a new toy than to play with it.
(more…)
Using mruby as Alternative: Server-Side | ArangoDB Blog 2012
Introduction
One of the design goals of AvocadoDB is:
Use AvocadoDB as an application server and fuse your application and database together for maximal throughput (more…)
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…)
Tutorial for AvocadoDB PHP API Published | ArangoDB Blog 2012
Hey there, short notice: Jan has written a tutorial on how to use the PHP API for AvocadoDB (note: this is “just” the API for the REST interface, it does not cover yet the upcoming query language). You can find both the
PHP API and the tutorial on Github. We are making progress with other languages as well… but that’s something for another blog post (cliffhanger 😉 ).
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).