Taking graph applications to production

Description

Over the past decade, Denise Gosnell has helped build some of the largest production applications of graph databases around the world. From those experiences, she’s collected a set of common areas in which teams frequently misstep when getting started with graph technology. It also happens that those themes parallel the experience of playing one of her favorite games, SimCity 2000. Denise walks you through a few of these topics.

Know the rules.
The introduction of graph data into your application introduces a new paradigm of data modeling: relationship-first design instead of entity-first design. The transition to relationship-first design principles introduces a new set of rules to consider for understanding your application’s performance, just like learning the rules of building a successful metropolis in SimCity. In this section, you’ll dive into the computational overhead introduced into your system from the branching factor and selectivity of your graph traversals.

Things can quickly become catastrophic.
Relationship-first data modeling can create a sleeping time bomb in your graph data: namely, supernodes. Just like in SimCity, high volumes of progress without proper planning will eventually introduce a catastrophe. To plan for this, you will need to track, mitigate, and eliminate the potential for supernodes within your applications. In this section, Denise introduces supernodes and presents tangible plans for avoiding the disasters which they can create.

You’re going to make mistakes.
Just like the learning process for understanding the tools and rules for building a successful city, you’ll inevitably make some mistakes when starting down the path of integrating graph technology into your stack. These common mistakes often start out as red herrings that are misinterpreted as graph problems. In this section, you’ll explore three use cases that are frequently misinterpreted as graph problems and learn techniques for avoiding these traps.