How to model customer surveys in a graph database

00Foxx, General, GraphsTags: , ,

Use-Case

The graph database use-case we are stepping through in this post is the following: In our web application we have several places where a user is led through a survey, where she decides on details for one of our products. Some of the options within the survey depend on previous decisions and some are independent.

Examples:

  • Configure a new car
  • Configure a new laptop
  • Book extras with your flight (meal, reserve seat etc.)
  • Configure a new complete kitchen
  • Collect customer feedback via logic-jump surveys

Read more

ArangoDB 3.1 Enterprise Edition – A Solid Ground to Scale with Graphs

00General, ReleasesTags: , , , ,

In addition to our community version of ArangoDB 3.1 we are excited to release our first Enterprise Edition today. The Enterprise Editions of ArangoDB focuses on enterprise-scale problems and provides useful features to meet the requirements of enterprise customers. You can download a free evaluation-only version here: Download Enterprise Edition. ArangoDB Enterprise Edition also comes with the Enterprise subscription, including comprehensive support SLA.

This first ArangoDB Enterprise Edition includes three major features:

  • SmartGraphs: Scale with graphs to a cluster and stay performant. With SmartGraphs you can use the “smartness” of your application layer to shard your graph efficiently to your machines and let traversals run locally
  • Encryption Control: Choose your level of SSL encryption
  • Auditing: Keep a detailed log of all the important things that happened in ArangoDB

Read more

ArangoDB 2.8 w/ AQL Graph Traversals, Array Indexes, Aggregation

04ReleasesTags: ,

We welcome 2016 with our first big news yet – the release of ArangoDB 2.8!

Now you can use new AQL keywords to traverse a graph even more convenient – a big deal for those who like to get the maximum out of their connected data. ArangoDB is getting faster with every iteration, in this release we have implemented several AQL functions and arithmetic operations in super-fast C++ code, optimizer rules and indexing improved further to help you getting things done faster. Download ArangoDB 2.8 here. Read more

Is UNQL Dead?

04Architecture, Query LanguageTags: ,
Note: We changed the name of the database in May 2012. AvocadoDB is now called ArangoDB.

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).

Do you like ArangoDB?
icon-githubStar this project on GitHub.
Star ArangoDB on GitHub