IT'S 2017, AND
I STILL WANT TO SELL YOU
A GRAPH DATABASE

A CONFESSION

I DON'T REALLY WANT TO
SELL YOU A GRAPH DATABASE

I WANT TO SELL YOU THE
IDEA OF A GRAPH DATABASE

WHY?

A LANGUAGE
THAT DOESN'T AFFECT THE WAY YOU
THINK ABOUT PROGRAMMING
IS NOT WORTH KNOWING.
Alan Perlis, emphasis mine.

A DATABASE
THAT DOESN'T AFFECT THE WAY YOU
THINK ABOUT DATA MODELLING
IS NOT WORTH KNOWING.
Alan Perlis, paraphrased

I WANT YOU TO MAKE AN
INFORMED DECISION

A QUICK STORY
BUT BEFORE THAT,

WE SPENT ONE YEAR BUILDING
A PRODUCT USING NEO4J

WE SPENT ONE YEAR BUILDING
A PRODUCT USERS PAY FOR

WE SPENT ONE YEAR BUILDING
A PRODUCT USERS LOVE

AND NOW WE'RE REWRITING
IT IN POSTGRES

WE CONCLUDED THAT BOTH
DECISIONS WERE CORRECT

USING NEO4J THEN, WAS
CORRECT

USING POSTGRES NOW, IS
CORRECT

THE FUN IS IN THE DETAILS
NATURALLY,

1. SEMANTICS
2. TOOLING
3. OPS

MODELLING AND QUERYING DATA
AS A GRAPH
SEMANTICS

DOES IT MAKE YOUR BUSINESS
LOGIC ANY SIMPLER OR BETTER?

TURNS OUT, IT DOES

EXAMPLE: SYMMETRICAL
RELATIONSHIPS
GRAPH SEMANTICS

REPRESENTING MARRIAGES

SAY, A PERSON IS MARRIED
TO ANOTHER PERSON

BY DEFINITION, THAT PERSON
IS MARRIED TO THIS PERSON

THE TRADITIONAL WAY TO SOLVE
THIS WOULD BE A JOIN TABLE

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
class Person < ActiveRecord::Base
has_many :marriages
has_many :spouses,
through: :marriages, source: :spouse
end
class Marriage < ActiveRecord::Base
belongs_to :person
belongs_to :spouse,
foreign_key: :spouse_id, class_name: "Person"
end

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
SELECT * FROM
marriages m
WHERE
m.person_id = 42
OR m.spouse_id = 42

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
if m.person_id == person.id
Person.find(m.person_id)
else
Person.find(m.spouse_id)
end

AWKWARD!

BUT HEY, THIS IS POSTGRES.
WE CAN DO BETTER!

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
class Marriage < ActiveRecord::Base
belongs_to :person
belongs_to :spouse, foreign_key: :spouse_id, class_name: "Person"
after_create do
inverse.first_or_create
end
after_destroy do
inverse.first.try(:destroy)
end
def inverse
Marriage.where(person: spouse, spouse: person)
end
end

THIS IS GOOD,
AND IT WORKS

BUT…

EXTRANEOUS COMPLEXITY
IN MAINTAINING EVEN ROWS

EXTRANEOUS COMPLEXITY
IN ADDING FEATURES

EXTRANEOUS COMPLEXITY
LIKE MULTIPLE SPOUSES

EXTRANEOUS COMPLEXITY
LIKE PAST SPOUSES

COMPARE THAT TO NEO4J:

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
class Person
include Neo4j::ActiveNode
# (Person)-[:MARRIES]->(Person)
has_many :both, :spouses,
type: "MARRIES", model_class: "Person"
# (Person)-[:IS_MARRIED_TO]->(Person)
has_one :both, :current_spouse,
type: "IS_MARRIED_TO", model_class: "Person"
end

SIMPLE, DECLARATIVE,
DATABASE RELIANT

GRAPH SEMANTICS
SYMMETRICAL RELATIONSHIPS: MARRIAGES
class Person
include Neo4j::ActiveNode
# (Person)-[:MARRIES]->(Person)
has_many :both, :spouses,
type: "MARRIES", model_class: "Person"
# (Person)-[:IS_MARRIED_TO]->(Person)
has_one :both, :current_spouse,
type: "IS_MARRIED_TO", model_class: "Person"
end

AD-HOC POINTERS
GRAPH SEMANTICS

GRAPH SEMANTICS
AD-HOC POINTERS
# (Author)-[:HAS_WRITTEN]->(Book)
has_many :out, :books,
type: "HAS_WRITTEN", model_class: "Book"
# (Author)-[:IS_WRITING]->(Book)
has_one :out, :current_book,
type: "IS_WRITING", model_class: "Book"

GRAPH SEMANTICS
AD-HOC POINTERS
# (Student)-[:HAS_ATTEMPTED]->(Assignment)
has_many :out, :assignments,
type: "HAS_ATTEMPTED", model_class: "Assignment"
# (Student)-[:HAS_BEST]->(Assignment)
has_one :out, :best_submission,
type: "HAS_BEST", model_class: "Assignment"

GRAPH SEMANTICS
AD-HOC POINTERS
# (Dentist)-[:TREATS]->(Patient)
has_many :out, :patients,
type: "TREATS", model_class: "Person"
# (Dentist)<-[:TEACHES_RUBY]-(Patient)
has_one :in, :ruby_teacher,
type: "TEACHES_RUBY", model_class: "Person"

GRAPH SEMANTICS
AD-HOC POINTERS
# (Person)-[:HAS]->(MoveScore)
has_many :out, :move_scores,
type: "HAS", model_class: "MoveScore"
# (Person)-[:HAS_CURRENT]->(MoveScore)
has_one :out, :current_move_score,
type: "HAS_CURRENT", model_class: "MoveScore"
# (Person)-[:HAS_PREFERRED]->(*)
has_one :out, :preferred_move_score,
type: "HAS_PREFERRED", model_class: false

WHY IS THIS USEFUL?

GRAPH SEMANTICS
AD-HOC POINTERS
MATCH
(realtor:Person)<-[:CONTACT_OF]-(contact:Person)<-
[:CONTACT_INFOS]-(email:EmailContactInfo)
WHERE
(contact.rapportive_enqueued IS NULL)
AND NOT ((contact)<-[:SOCIAL_PROFILES]-
(:SocialProfile {type: 'linked_in'}))
RETURN
DISTINCT(contact) as contact, realtor.user_id as
user_id, collect(email) as emails

GRAPH SEMANTICS
AD-HOC POINTERS
MATCH
(realtor:Person)<-[:CONTACT_OF]-(contact:Person)<-
[:CONTACT_INFOS]-(email:EmailContactInfo)
WHERE
(contact.rapportive_enqueued IS NULL)
AND NOT ((contact)<-[:SOCIAL_PROFILES]-
(:SocialProfile {type: 'linked_in'}))
RETURN
DISTINCT(contact) as contact, realtor.user_id as
user_id, collect(email) as emails

GRAPH SEMANTICS
AD-HOC POINTERS
MATCH
(node)<-[edge]-(node)<-[edge]-(node)
WHERE
(conditional)
AND NOT ((node)<-[]-(node))
RETURN
stuff

WRITE QUERIES ABOUT
GRAPH, USING A GRAPH!

GRAPH SEMANTICS
AD-HOC POINTERS
# (Person)-[:HAS]->(MoveScore)
has_many :out, :move_scores,
type: "HAS", model_class: "MoveScore"
# (Person)-[:HAS_CURRENT]->(MoveScore)
has_one :out, :current_move_score,
type: "HAS_CURRENT", model_class: "MoveScore"
# (Person)-[:HAS_PREFERRED]->(*)
has_one :out, :preferred_move_score,
type: "HAS_PREFERRED", model_class: false

GRAPH SEMANTICS
AD-HOC POINTERS
# (Person)-[:HAS]->(MoveScore)
has_many :out, :move_scores,
type: "HAS", model_class: "MoveScore"
# (Person)-[:HAS_CURRENT]->(MoveScore)
has_one :out, :current_move_score,
type: "HAS_CURRENT", model_class: "MoveScore"
# (Person)-[:HAS_PREFERRED]->(*)
has_one :out, :preferred_move_score,
type: "HAS_PREFERRED", model_class: false

GRAPH SEMANTICS
AD-HOC POINTERS
# (Person)-[:HAS]->(MoveScore)
has_many :out, :move_scores,
type: "HAS", model_class: "MoveScore"
# (Person)-[:HAS_CURRENT]->(MoveScore)
has_one :out, :current_move_score,
type: "HAS_CURRENT", model_class: "MoveScore"
# (Person)-[:HAS_PREFERRED]->(*)
has_one :out, :preferred_move_score,
type: "HAS_PREFERRED", model_class: false

GRAPH SEMANTICS
AD-HOC POINTERS, POLYMORPHIC
# Post, Article, Status
has_many :comments, as: :commentable
# Comment
belongs_to :commentable, polymorphic: true

GOOD LUCK, WRITING
A JOIN QUERY AGAINST THAT!

LABELS: POLYMORPHISM,
MIXINS, & COMPOSITION
GRAPH SEMANTICS

EACH NODE IN A GRAPH
IS IDENTIFIED BY A LABEL

EACH EDGE IN A GRAPH
IS IDENTIFIED BY A LABEL

ANY NODE IN A GRAPH
CAN ANY NUMBER OF LABELS

ANY EDGE IN A GRAPH
CAN ANY NUMBER OF LABELS

LET'S EQUATE A LABEL
TO A CLASS

EXAMPLE:
EMAIL, PHONE, CONTACT INFO

EMAIL IS A CONTACT INFO

PHONE IS A CONTACT INFO

SO,
SHARED BEHAVIOUR

BUT,
DIFFERENT CONSTRAINTS

THIS IS CURRENTLY NOT
POSSIBLE IN POSTGRES

WELL, NOT WITHOUT A LOT
OF ADDITIONAL COMPLEXITY

EXAMPLE: SIX DEGREES
OF KEVIN BACON
GRAPH SEMANTICS

GOOGLE FOR YOUR FAVOURITE
ACTOR'S BACON NUMBER

GRAPH SEMANTICS
EXAMPLE: SIX DEGREES OF KEVIN BACON
(Actor)
-[:HAS_WORKED_WITH]->(Actor)
-[:HAS_WORKED_WITH]->(Actor)
-[:HAS_WORKED_WITH]->(Actor)
-[:HAS_WORKED_WITH]->(Actor)
-[:HAS_WORKED_WITH]->(Actor)

GRAPH SEMANTICS
EXAMPLE: SIX DEGREES OF KEVIN BACON
Answer to this question
has been left to the reader
as an exercise.

GRAPH SEMANTICS
CYPHER THE QUERY LANGUAGE
MATCH
(you {name:"You"})
MATCH
(expert)
-[:WORKED_WITH]->
(db:Database {name:"Neo4j"})
MATCH
path = shortestPath(
(you)-[:FRIEND*..5]-(expert))
RETURN db,expert,path

PLENTY OF MORE EXAMPLES, AND
GREAT DOCS ON THE OFFICIAL SITE

LIBRARIES, ADAPTERS, DEV TOOLS,
ADMIN TOOLS ETC.
TOOLING

FIRST QUESTION THAT COMES
TO THE MIND: ACTIVE RECORD?

YES AND NO.
RUBY GEM "NEO4J" AVAILABLE

NO: NOT QUITE AS FULLY
FEATURED AS ACTIVE RECORD

YES: OFFERS THAT WELL FAMILIAR
API WE'VE SEEN EARLIER

TOOLING
NEO4J.RB API
# (Person)-[:HAS]->(MoveScore)
has_many :out, :move_scores,
type: "HAS", model_class: "MoveScore"
# (Person)-[:HAS_CURRENT]->(MoveScore)
has_one :out, :current_move_score,
type: "HAS_CURRENT", model_class: "MoveScore"
# (Person)-[:HAS_PREFERRED]->(*)
has_one :out, :preferred_move_score,
type: "HAS_PREFERRED", model_class: false

YES: OFFERS ALL THE TOOLS
YOU ARE ACQUAINTED WITH

TOOLING
NEO4J.RB API: ALL YOUR FAMILIAR TOOLS
▸ Properties
▸ Indexes / Constraints
▸ Callbacks
▸ Validation
▸ Associations

OF COURSE,
THERE ARE CAVEATS

NEO4J DOESN'T MAINTAIN
TYPES OF PROPERTIES

AND SO NEO4J.RB HAS TO

ADDITIONAL COGNITIVE
OVERLOAD WHEN QUERYING

TOOLING
NEO4J: NO TYPES
# This is a sorted collection
[2, 3, 5, 7, 11]
# And so is this
["11", "2", "3", "5", "7"]

NEO4J DOESN'T ALLOW
COMPOSITE INDEXES

NEO4J DID NOT SUPPORT
A BINARY PROTOCOL

IT WAS ALL REST BASED

I SAID WAS, BECAUSE THIS IS
BEING ADDRESSED NOW

A BINARY PROTOCOL IS OUT,
BUT NOT PRODUCTION READY

YOU CAN ALWAYS USE THE
JDBC CONNECTOR, FROM JAVA

IT DOESN'T SUFFER FROM
ANY OF THESE ISSUES

WHAT ISSUES, YOU SAID?

TOOLING
NEO4J: ALL REST, NO BINARY
Neo4j::Session::CypherError
# 1. Unable to load RELATIONSHIP with id
<some-id>
# 2. LockClient[80] can't wait on resource
# 3. Expected a numeric value for empty
iterator, but got null

TOOLING
NEO4J: ALL REST, NO BINARY
Faraday::ConnectionFailed
# 1. too many connection resets
# 2. connection refused to: <ip-address>
# 3. Failed to open TCP connection to
# 4. execution expired

TOOLING
NEO4J: ALL REST, NO BINARY
Neo4j::ActiveRel::Persistence::RelCreateFaile
dError
# 1. Cannot create rel with unpersisted,
invalid to_node

FAR TOO MANY TIMES TO
COUNT

THESE ERRORS WERE OUR
PRIMARY REASON FOR SWITCHING

THEY CRIPPLED OUR SCALE, AND
LIMITED OUR CONCURRENCY

DEAL BREAKER!

THERE ARE PLENTY MORE
THINGS I WANT TO TALK ABOUT

MONITORING, BACKUPS, DEPLOYMENTS,
PERFORMANCE TUNING, ETC
OPS

BUT I WILL STOP HERE.

CONCLUSION

POWERFUL QUERYING,
EXCELLENT PERFORMANCE,
BEAUTIFUL API,
GREAT SEMANTICS

A NATURAL CHOICE FOR
BUILDING APPLICATIONS
WITH RELATIONSHIP
FOCUSSED DATA

BUT…

THE RUBY ECOSYSTEM
AND TOOLING LEAVES A
LOT TO BE DESIRED

SPECIALLY WHEN YOU ARE
DEALING WITH HIGH
PERFORMANCE AND HIGH
CONCURRENCY

THANK YOU!
THIS IS IT.

SWANAND PAGNIS
PRINCIPAL ENGINEER, FIRST.IO
@_SWANAND ON TWITTER
WHO AM I?

QUESTIONS?
IF TIME PERMITS…