database look like? Is it already out there? ! ‣ Second Generation NoSQL DB ‣ Unique feature set ‣ Solves some problems of other NoSQL DBs ‣ Greenfield project ‣ Experienced team building NoSQL DBs for more than 10 years 3
model database ‣ Convenient querying ‣ Extendable through JS & MRuby ‣ High performance & space efficiency ‣ Easy to use ‣ Started in Sep 2011 ‣ Current Version: 1.4
(identifiers) ‣ Treat data as opaque (data has no structure) ‣ Can implement scaling and partitioning easily due to simplistic data model ‣ Key-value can be seen as a special case of documents. For many applications this is sufficient, but not for all cases. ! ArangoDB ‣ It‘s currently supported as a key-value document. ‣ In the near future it supports special key-value collection. ‣ One of the optimization will be the elimination of JSON in this case, so the value need not be parsed. ‣ Sharding capabilities of Key-Value Collections will differ from Document Collections
still has a unique key) ‣ Allow to save documents with logical similarity in „collections“ ‣ Treat data records as attribute-structured documents (data is no longer opaque) ‣ Often allows querying and indexing document attributes ! ArangoDB ‣ It supports both. A database can contain collections from different types. ‣ For efficient memory handling we have an automatic schema recognition. ‣ It has different ways to retrieve data. CRUD via RESTful Interface, QueryByExample, JS for graph traversals and AQL.
ArangoDB ‣ Supports Property Graphs ‣ Vertices and edges are documents ‣ Query them using geo-index, full-text, SQL-like queries ‣ Edges are directed relations between vertices ‣ Custom traversals and built-in graph algorithms Graph Store
a document by its unique id / key: GET /_api/document/users/12345 ‣ Query by providing an example document: PUT /_api/simple/by-example { "name": "Jan", "age": 38 } ‣ Query via AQL: FOR user IN users FILTER user.active == true RETURN { name: user.name } ‣ Graph Traversals und JS for your own traversals ‣ JS Actions for “intelligent” DB request
language” ‣ Limited ‣ Hard to read & write for more complex queries ‣ Complex queries, joins and transactions not possible ‣ CouchDB uses Map/Reduces ‣ It‘s not a relational algebra, and therefore hard to generate ‣ Not easy to learn ‣ Complex queries, joins and transactions not possible
LET userRelations = ( FOR p IN PATHS( users, relations, "OUTBOUND" ) FILTER p._from == u._id RETURN p ) RETURN { "user" : u, "relations" : userRelations }
Multi Collection Transactions ‣ Building small and efficient Apps - Foxx App Framework ‣ Individually Graph Traversals ‣ Cascading deletes/updates ‣ Assign permissions to actions ‣ Aggregate data from multiple queries into a single response ‣ Carry out data-intensive operations ‣ Help to create efficient Push Services - in the near Future ! ‣ Currently supported ‣ Javascript (Google V8) ‣ Mruby (experimental, not fully integrated yet)
answer arbitrary HTTP requests directly ‣ You can write your own JavaScript functions (“actions”) that will be executed server-side ‣ Includes a permission system ! ➡ You can use it as a database or as a combined database/app server
database directly? ‣ It would only need an API. ‣ What if we could define this API in JavaScript? ! ! ! ! ! ! ‣ ArangoDB Foxx is streamlined for API creation – not a jack of all trades ‣ It is designed for front end developers: Use JavaScript, which you already know (without running into callback hell)
still not free and data volume is growing fast. Requests volumes are also growing. So performance and space efficiency are key features of a multi-purpose database. ! ‣ ArangoDB supports automatic schema recognition, so it is one of the most space efficient document stores. ‣ It offers a performance oriented architecture with a C database core, a C++ communication layer, JS and C++ for additional functionalities. ‣ Performance critical points can be transformed to C oder C++. ‣ Although ArangoDB has a wide range of functions, such as MVCC real ACID, schema recognition, etc., it can compete with popular stores documents.
of salt ‣ Performance is very dependent on a lot of factors including the specific task at hand ‣ This is just to give you a glimpse at the performance ‣ Always do your own performance tests (and if you do, report back to us :) ) ‣ But now: Let‘s see some numbers
Simple Queries for simple queries, AQL for complex queries ‣ Simplify your setup: ArangoDB only – no Application Server etc. – on a single server is sufficient for some use cases ‣ You need graph queries or key value storage? You don't need to add another component to the mix. ‣ No external dependencies like the JVM – just install ArangoDB ‣ HTTP interface – use your load balancer