Slides: Is multi-model the future of NoSQL?

00Future-of-nosql, PresentationTags: ,

Here is a slideshare and recording of my talk about multi-model databases, presented in Santa Clara earlier this month.

Abstract: Recently a new breed of “multi-model” databases has emerged. They are a document store, a graph database and a key/value store combined in one program. Therefore they are able to cover a lot of use cases which otherwise would need multiple different database systems. This approach promises a boost to the idea of “polyglot persistence“, which has become very popular in recent years although it creates some friction in the form of data conversion and synchronisation between different systems. This is, because with a multi-model database one can enjoy the benefits of polyglot persistence without the disadvantages.

In this talk I will explain the motivation behind the multi-model approach, discuss its advantages and limitations, and will then risk to make some predictions about the NoSQL database market in five years time. More info

Graphs in data modeling 

00Future-of-nosql, GraphsTags:

Max wrote an inspiring article about graphs in data modeling on Medium, packed with his own thoughts – “to sort out some things in my brain” (Max).

He asks and answers the question: Are graphs and graph databases useful in data modeling, and if so, for what and under which circumstances?

In his article, he goes all the way down from the theoretical approach of what is a graph? towards storing a graph in different storage models (RDBMS, document store and graph databases) to querying a graph and finally to his personal conclusion. More info

CAP & Google Spanner: the survival of eventual consistency – A response to Dave Rosenthal’s article on Gigaom –

06Future-of-nosqlTags: ,

In Next gen NoSQL: The demise of eventual consistency a recent post on Gigaom FoundationDB founder Dave Rosenthal proclaims the demise of eventual consistency. He argues that Google Spanner “demonstrates the falsity of a trade-off between strong consistency and high availability”. In this article I show that Google Spanner does not disprove CAP, but rather chooses one of many possible compromises between total consistency and total availability. For organizations with a less potent infrastructure than Google other compromises might be more suitable, and therefore eventual consistency is still a very good idea, even for future generations of nosql databases.

More info

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