FOSDEM is an absolutely open and free conference in Brussels, Belgium. The conference offers an impressive amount of developer rooms discussing a broad range of technical topics, including NoSQL and graphs.
After a funny and productive ArangoDB hackathon weekend Frank and I arrived at FOSDEM on Sunday noon. We were looking forward to the talks in the graph devroom, but unfortunately for us it was not possible to enter the room (it was overfull, indicating a great quality of talks).
At the next speakers change Frank and I managed to slip into the room and could enjoy two inspiring talks by Neo4J.
Afterwards it was my turn to present the graph visualization interface in ArangoDB in a still crowded room (slides).
After my presentation, we handed out all our ArangoDB t-shirts to our fans.
All together it was a great experience and a really huge amount of people visiting the same conference which impressed me a lot.
Thanks for the team at the Graph Processing devroom for giving me the opportunity to speak and for organizing such a great devroom.
We will meet again next year.
The ArangoDB team traveled to Barcelona for the “NoSQL matters” – weekend. Day one was packed with a lot of NoSQL-trainings and Jan introduced the NoSQL landscape by explaining how to model your data in a non-relational world. Following the wish of many participants Jan had to repeat the morning session about the new and exciting possibilities of NoSQL in the afternoon.
After an inspiring key-note by Nathan Marz, three tracks full of NoSQL, BigData and Searching explained the latest trends.
Lucas talked about ArangoDB in general, Foxx and the advantages of multi-models. He explained “why relations — especially properties graphs — matter even in a NoSQL database” by Sarahs Mei’s example of social networks.
After his talk, we had a lot of interesting and inspiring discussions at the ArangoDB booth in the entry hall.
NoSQL matters was a great experience for us, which gave the ArangoDB team the opportunity to meet a lot of interesting people to exchange and to develop new ideas.
Last week Jan (core member of ArangoDB and the brain behind AQL and many other parts) was invited by “mobile.cologne” – a user group here in Cologne dealing with mobile development.
In this talk Jan gives a general overview on nosql databases and the different flavors. He explains how to query a nosql database and he evaluates how a nosql database can be used in a mobile app.
Warning: The talk is in German. If you want to hear it in English, let us know in the comments. 🙂
“NoSQL meets mobile.cologne” by Jan Steemann.
To easily conduct bulk insert benchmarks with different NoSQL databases, we wrapped a small benchmark tool in PHP. The tool can be used to measure the time it takes to bulk upload data into MongoDB, CouchDB, and ArangoDB using the databases’ bulk documents APIs.
In the relational world, PL/SQL is used to store business/application logic inside the relational database. The same movement is currently happening in the NoSQL. Redis for example uses LUA script in its newest version (2.6), to allow developers to tweak Redis. There a lot of use-cases for a programming language in document-stores. Programming languages are used in various document stores like ArangoDB, CouchDB, MongoDB, or VoltDB. In my opinion in the following use-cases a suitable language like Ruby will be most handy.
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.
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).
Are you a Python expert and want to contribute to an open source project? We need your help writing an API for Python for a new nosql database!
AvocadoDB is a rather new open source project – a fancy nosql database with a couple of interesting features:
- Schema-free schemata
- Usable as application server
- Flexible data modeling (key value pairs, document store, graph database)
- Free index choice
- Configurable durability
- Support for modern storage hardware like SSD and large caches
You'll find more information on AvocadoDB here.
AvocadoDB is 100% open source using the Apache Licence 2.0.
Work in progress: general API and APIs for Ruby & PHP
Part of what we are currently doing is working on the APIs. AvocadoDB itself will provide
- a REST interface
- a query by example API
- a query language for more complex queries
Good news for the Ruby community: Thanx to @tisba, @moonbeamlabs and @a2800276, AvocadoDB will get a nice Ruby API and integration into Rails. Jan is implementing the PHP Api.
Unfortunately we are no Python experts. Therefore we need the help of the community to support Python properly. We are looking for someone willing and able to develop a Python driver for AvocadoDB. It would be awesome to provide a document object manager like mongoEngine for Django as well (we would love to hear your thoughts on this – do you suggest anything else for Python?).
We have already compiled an „over the wire spec“ which describes the REST interface (attention: it’s work in progress and a few details will change in the next days).
Sounds all interesting? Join the team!
Do you want to become part of this project? Telling us how a proper implementation for Python should look like? Implementing? Great! :-) We would love to hear from you:
email: hackers AT avocadodb.org
P.S. Are you a Java/Lua/C#/Whatever guy and would like AvocadoDB to support your language as well? YES! Ruby, Python and PHP is a good start, but we want to provide other languages as well, of course. So: Contact us as well! :-)
Before we started programming the new open source NoSQL database, we reflected which design objectives to achieve or to drop. This article summarizes our considerations.
In a nutshell:
- Schema-free schemas with shapes: Inherent structures at hand are automatically recognized and subsequently optimized.
- Querying: ArangoDB is able to accomplish complex operations on the provided data (query-by-example and query-language).
- Mostly memory/durability: ArangoDB is memory-based including frequent file system synchronizing.
- AppendOnly/MVCC: Updates generate new versions of a document; automatic garbage collection.
- ArangoDB is multi-threaded.
- No indices on file: Only raw data is written on hard disk.
- ArangoDB supports single nodes and small, homogenous clusters with zero administration.
Get the latest tutorials,
blog posts and news:
Thanks for subscribing! Please check your email for further instructions.