Dhruba Borthakur discusses the different types of data used by Facebook and how they are stored, including graph data, semi-OLTP data, immutable data for pictures, and Hadoop/Hive for analytics.
Peter Bell introduces 4 NoSQL categories –Key-Value, Document, Column, Graph - and explains how one can use Spring Data to work with such data stores.
Jim Webber talks about the data of these days, how integrated data looks, how to model it using actual data stores and the implications of this modeling.
Ian Robinson introduces Neo4J, a graph database, discussing how it can be used to store and work with data associated with Doctor Who.
Justin Dearing presents a brief introduction to MongoDB, and focuses on interacting with it in Mono via the official 10gen driver. Techniques for handling business logic in application code, such as LINQ are discussed. This is a very code centric talk.
Michael Hunger discusses graph databases and the need for them in the larger context of NoSQL data stores, introducing Spring Data, Neo4j, and Spring Data Neo4j.
Rick Bullotta and Emil Eifrem discuss how to use graph databases to model the real world, people, systems and things, talking advantage of the relationships between various data elements.
Borislav Iordanov presents the architecture of HyperGraphDB, a special type of store based on hypergraphs – graphs with edges pointing to an arbitrary number of nodes and to other edges, comparing it with other graphs databases and its relationship to other NoSQL stores.
Emil Eifrem overviews the trends leading to NOSQL (Not Only SQL), and the four emerging NOSQL solutions: key-value stores, plus column, document and graph databases. He also explains the internals of a graph database and an example of using Neo4j - a graph database - in production.
This presentation covers the definition of a graph database (information structured as mathematical graphs with nodes, relationships and properties) and their advantages when dealing with data that is difficult to fit in static tables, is rapidly evolving, or that has a lot of optional attributes. The flexibility of graph databases better support agile development and schema evolution.