Scale Your Mission-Critical Applications With Neo4j Fabric and Clustering Architecture

© 2022 Neo4j, Inc. All rights reserved.
1
As an organisation's data continues to grow, graph practitioners have to design solutions that
enable effective business decisions to be made from multiple business graphs, or from within a
single graph that may be growing rapidly to many terabytes of data.
This session is for you if you are concerned with operational issues like minimising the number
of clusters, horizontal scale and elasticity, sharding very large data sets to improve
manageability and querying multiple business graphs in real-time.
Against the backdrop of two financial uses cases we will explore how Clustering and Fabric in
Neo4j 5 - currently available as a Tech Preview in Neo4j 4.4 - can help you make business
decisions in real-time across different business graphs (federated queries) and make multi-
terabyte datasets more manageable (sharding) within a highly scalable and elastic clustering
architecture.
This session contains forward looking statements wrt to Fabric (not available as a tech
preview), and behaviour of clustering in Neo4j 5 (released as a tech preview in Neo4j 4.4)
Session description please ensure website has been updated with this copy

Scale Your Mission-Critical
Applications With Neo4j
Clustering and Fabric
Stu Moore,
Product Manager
@stum00re

3
Session overview
How Neo4j scales with your business needs
Horizontal scale out for the cluster
How it works (under the hood)
Operating
Neo4j at
scale with
Clustering
in Neo4j 5

4
Session overview
What is Fabric?
Why you need it?
How to design for it, including sharding strategies
Operating
Neo4j at
scale with
Fabric in
Neo4j 5

5
Session overview
Clustering and Fabric with Federation
Clustering and Fabric with Sharding
Two
financial
fraud use
cases for
Fabric

Neo4j 5 Clustering
What is it?
● Databases are replicated to a subset of servers within a cluster.
● The cluster decides which databases are allocated to servers.
● The allocation may change as servers are added and removed over time.
Benefits:
● Manage fewer clusters - horizontal scaling of clusters resources to accommodate
more databases, larger databases & more concurrent users.
● Elasticity - horizontally scale cluster to manage peaks in demand / new databases.
● Reduce blast radius* - distribute databases over more servers.
How:
● Two new components 1) the Allocator and the 2) Topology Graph

Neo4j 5 Clusters
Server
5
Server
1
Server
4
Server
3
Server
6
ALL servers are created equal
A database copy can be Primary or a Secondary
Use the Secondary for reads, backups
Server
2
Deprecated terms
Core or Primary Server
Read Replica or Secondary Server

Example
Server
5
Server
1
Server
4
Server
3
Server
6
Server
2
CREATE DATABASE knowledge OPTIONS
{primaries:3, secondaries:1}
Note the command is illustrative

Example
Server
5
Server
1
Server
4
Server
3
Server
6
Server
2
knowledge
P
P
P
S
One Primary database is the Leader

CREATE DATABASE product OPTIONS
{primaries:3}
Example
Server
5
Server
1
Server
4
Server
3
Server
6
Server
2
knowledge
P
P
S
P

CREATE DATABASE product OPTIONS
{primaries:3}
Example
Server
5
Server
1
Server
4
Server
3
Server
6
Server
2
knowledge
P
P
P
product
P
P
P
System database exists everywhere.
S

12
5 databases, replicated 3 times across 4 servers
DB01
DB05
DB03
DB04
DB01
DB02
DB03
DB05
DB01
DB02
DB03
DB04
DB05
DB02
DB04

13
Scale out to 5 servers to meet surge in demand
DB01
DB05
DB03
DB02
DB03
DB01
DB02
DB03
DB04
DB05
DB02
DB04
DB01
DB04
DB05
● Handle more
throughput, or
disk utilization
● Reduce
impact of
server failure

14
Scale out with additional servers to add more databases
DB01
DB05
DB03
DB02
DB03
DB01
DB02
DB03
DB04
DB05
DB02
DB04
DB01
DB04
DB05
DB06 DB06 DB06
DB07 DB07 DB07

Database Allocator
CREATE DATABASE causes the Allocator to run auto
strategies to pick the servers based on constraints.
The Allocator then updates the Topology.
If the Allocator cannot find a way to satisfy the
constraints declared in a database’s TOPOLOGY, it will
fail the transaction
The Allocator is responsible for re-assigning
databases when servers are added/removed.
Cypher DDL
Reconciler
Topology
Graph
Allocator

16
Allocator Strategy Complete same as Neo4j 4.4
DB01
DB02
DB03
DB04
DB01
DB02
DB03
DB04
DB01
DB02
DB03
DB04
DB01
DB02
DB03
DB04
A copy of each database
on every server

17
Allocator Strategy EqualNumbers
DB01
DB05
DB03
DB04
DB01
DB02
DB03
DB05
DB01
DB02
DB03
DB04
DB05
DB02
DB04
3 copies of each database
with an equal number of
databases on each server

18
Allocator Strategy OptimalDiskUtilization
DB01
DB02
DB01 DB01
DB02
DB02

19
Allocator Strategy OptimalDiskUtilization
DB01
DB03 DB02
DB01 DB01
DB02
DB03
DB02
DB03
Balance data usage &
minimise data transfer

20
Allocator can use labels to make decisions
DB02
DB02 DB02
DB01
E.g. size: small, medium, large
region: us-east, us-west
type: primary, secondary
small large large large

The Topology
A graph, that describes the servers and databases in the cluster, stored in the
system database
Periodically updated to reflect instances joining or leaving in discovery

Routing Client Requests
Server
5
Server
1
Server
4
Server
3
Server
6
Server
2
knowledge
P
P
P
product
P
P
P
S
:use DATABASE knowledge
:use DATABASE product
Server Side Routing on by default
Discovery service aware of the role each
database is providing

23
Operations
- Temporary unavailability does not affect normal ops
- Crashing / separated or shutdown servers remain in the Topology
- The Allocator will use any servers available in the graph
- DBAs must manually remove servers from the Topology
- DEALLOCATE can safely remove database/ server without reducing FT
- Servers that are being removed will gradually stop hosting databases
- Servers can only be removed when they don't host a database

24
Fabric in Neo4j 5
The foundation of Fabric is the Cluster

25
Session overview
What is Fabric?
Why you need it?
How to design for it, including sharding strategies
Financial Fraud use cases for Fabric & Clustering
- Federation
- Sharding
Operating
Neo4j at
scale with
Fabric in
Neo4j 5

26
Why Fabric? A way to…
Unlock more business value
• Query across multiple graphs -> FEDERATION
Operate at scale
• Virtually unlimited horizontal scale
• Increase performance without vertical scale
• Improved operations
◦ Manage smaller data sets
◦ Backup / restore
• SHARD TB data into 100s GB
Hybrid Cloud queries
• From Neo4j query across Aura & Neo4j*
What is it?
• Execute queries
in parallel across
databases
• Chain queries for
sophisticated
real-time analysis
• Query a
database
composed of
other databases

shard02
27
cards
shard01
"Fabric" Database
loans
shard03
Compose a graph from databases within & across clusters
Cluster01
Cluster02

shard02
28
cards
shard01
"Fabric" Database
loans
shard03
Compose a graph from databases across a larger cluster
Cluster01

When planning horizontal scale-out it is important to pick an
appropriate strategy for splitting your data.
As ever, the right choice depends on your domain.
Sharding by geographical location
● Good for: Social networks, sensor networks etc…
● Drawback: Relationships across geographical boundaries
may lead to data duplication
● Recommend: Many smaller regions as shards.
○ Collocating shards is easier than re-sharding
29
Design
Effective Sharding Strategies

Sharding by logical domain entity (e.g. Customer/Patient Id)
● Good for: SaaS, Multi-tenant applications etc…
● Drawback: Not every domain has a natural entity to shard on
● Note: If your shard entities are connected by relationships
and often queried together, they may not be a good fit.
30
Design

Sharding by time window
● Good for: Analytics, event based systems etc…
● Drawback: High potential for workload skew.
● Note: Ensure writes won’t exceed the limits of a single shard.
31
Design

Security
● RBAC is supported
● ACCESS and READ privileges* required by the user
Write Transactions
● Select the best shard strategy
● May only write to a single database at a time
● Not an issue for Federated use case
Operational
● Best Practice: Scale out your cluster
● Minimise number of clusters e.g patch overhead
● Deploy Ops Manager if you manage multiple clusters
32
Design
Operational

33
Toolkits and Libraries
Iterating /Redesign - neo4j-admin copy
● To subdivide an existing shard
● Or change shard strategy
● Requires downtime
APOC
● Is database centric
● No concept of database id + node id
Visualization - Bloom (& Linkurious etc)
● Fabric database is composed of references
● Doesn't store data
● When you run a query write results to another database
● Visualize what is there
GDS
● Cypher projections do currently run on Fabric queries
● Pull results to a local database
Design

34
Investigating Fraud @ Trinity
Bank
A real use case with a simulated bank

Fraud rings and synthetic identities
Structuring: evading financial reporting
Round-tripping
Transaction Laundering
Cash-intensive businesses
Trade-based laundering:
Shell companies and trusts
Bank capture
35
Types include
Globally
$4tn.
of Fraud
Per Year

36
Stolen Identity Rings - when multiple core PII
elements like First Name, Last Name, Date
of Birth and SSN appear with multiple phone
numbers, addresses and emails.
The fraudster uses the stolen information with multiple
contact elements to submit numerous high velocity
of applications and varying contact
information.

37
Synthetic Identity Rings - when there is
evidence of PII tumbling, a mix and match of the
core PII elements.
The contact information is likely to be reused
with the different identities, as opposed to
consistent identity information with multiple contact
information like in the stolen identity fraud rings

38
A common method is structuring transactions
with a group of accomplices aka smurfs.
For example, a person might have $50,000 to send
abroad, this would trigger a Currency Transaction Report.
In order to avoid a CTR, that person could have
ten accomplices make transfers of $5,000 each.
https://www.investopedia.com/terms/s/smurf.asp

39
Do Trinity need Fabric?

40
Representative model
Model is NOT complete

Brief for
Fraud
Rings
Spot stolen & synthetic identities
In high velocity of applications
Across multiple banking systems
Varying contact information
41
Detecting fraudulent applications

42
Stolen Identity Applications
Credit Card Application
Loan Application

43
Can Fabric detect Fraud Rings?

44
Is Abigail Hansen genuinely the same identity in
each system?
The Fraud Ring Detection has to compare the
identity information, how similar are the identities?
While NI / SSN is a unique identifier we can't
assume it is the same identity

45
Personal
Loans
Credit
Card
Mortgage
Business
Loans
Fabric - Federation - Parallel Queries
Fraud Ring
Detection
Business Loan
Application
writes to
Business Loan
Application
needs Fraud
Detection
FEDERATION
= Combined value
of any number of
business systems

46
Personal
Loans
Credit
Card
Mortgage
Business
Loans
Fabric - Federation
Business Loan
Application
needs Fraud
Detection
Queries in Parallel
Operational Stores
<500GB
Writes to a single
database at a time
Can use GDS & Bloom
on each graph
Can create a new
fraud database with
results and use GDS

47
Federation for Fraud Rings

48
Can Fabric detect smurfs?

49
Can Fabric detect smurfs?
A use case for SHARDING not a Smurf

50
Evading financial reporting
Triggering Currency Transaction Report
- 6 month horizon
Look for people with accomplices
- e.g making transfers of $5,000 each
Trinity generate ~100GB of tx data/month
Would like a future proof architecture
• Ability to scale out to 12m fraud analysis
• Or, cope if monthly transactions double
Brief for
smurfing

51
1.2TB+ of
transactions
on 3x
servers
0.6TB of
transactions
on 3x
servers
Option 1: Scale up a cluster to 3x 1TB+ machines overtime

52
Challenges with very large data sets?
Design for
Operations
Sizing for now vs later
Resizing later
Full backup now vs
later
Archive mntly / qtr / yr
Design for Runtime
Fitting data into RAM
Startup / cache warm
up time
0.5TB+
• The case for
distributed data
management
• Horizontal vs
vertical scale

53
Option 2: 5 shards, replicated 3x across 4 servers
Sh01
Sh05
Sh03
Sh04
Sh01
Sh02
Sh03
Sh05
Sh01
Sh02
Sh03
Sh04
Sh05
Sh02
Sh04

Sh01
Sh04
Sh05
54
Scale out with additional servers to meet Tx growth
Sh01
Sh05
Sh03
Sh02
Sh03
Sh01
Sh02
Sh03
Sh04
Sh05
Sh02
Sh04

55
Scale out with Primary servers to add more shards
DB01
DB05
DB03
DB02
DB03
DB01
DB02
DB03
DB04
DB05
DB02
DB04
DB01
DB04
DB05
DB06 DB06 DB06
DB07 DB07 DB07

56

57
What is the operational unit?
Transaction processing, backup and restore

58

59
Customer
Account
Database
OLTP Writes
High Performance
100/200GB
June
DB202206

60
Customer
Account
Database
Mar
DB202203
Apr
DB202204
May
DB202205
June
DB202206
Fabric - parallel cross shard queries
SMURF
Detection
100->200GB
Sharding
= Query across a
distributed graph

61
Customer
Account
Database
Mar
DB202203
Apr
DB202204
Fabric
OLTP High
Performance
Writes
Current
(ALIAS)
June
DB202206
May
DB202205
Swaps shards with REMOTE ALIAS

62
Customer
Account
Database
Apr
DB202204
May
DB202205
Fabric
Transaction
Writes
June
DB202206
Account
Updates
Fabric security
RAM required across
each shard <200GB
Parallel queries
Writing to a single
shard at a time
Can pull results to
another database and
use GDS & Bloom
Mar
DB202203

63
Sharding for smurfs

Recap
64
Why
ms response times for multi-TB queries
● Unlimited horizontal scale
Combined value of multiple business graphs
● Federated query
Hybrid cloud queries
● Query databases anywhere*
Operational
● Manage TB data stores
● Reduce RTO for multi-TB graphs

Recap
65
What's coming in Neo4j 5
Horizontal and elastic scale
● Manage fewer clusters
● Database allocation rules
Fabric is fault tolerant
● Runs in the Cluster
Can compose Fabric with Cypher
● Within and across clusters
● Application agnostic changes REMOTE ALIAS
And don't forget, you can manage with Ops Manager

66
Check out these other great sessions
1 2
Monitoring and
Administration
with Neo4j Ops
Manager
Fun with Fabric
in 15
3 4
Inside scoop on
Neo4j: Meet the
Builders
Operating Neo4j in
a Multi-Zone
Kubernetes
Cluster

67
https://image2graph.herokuapp.com/

68
Thank you!
Contact us at
sales@neo4j.com
@stum00re

shard02
69
cards
shard01
"Fabric" Database
loans
shard03
Compose a graph from databases within & across clusters
Cluster01 Cluster02

shard03
70
cards
shard01 shard02
"Fabric" Database
loans
Compose a graph from databases within larger clusters
Cluster01

Scale Your Mission-Critical Applications With Neo4j Fabric and Clustering Architecture

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Scale Your Mission-Critical Applications With Neo4j Fabric and Clustering Architecture

Similar a Scale Your Mission-Critical Applications With Neo4j Fabric and Clustering Architecture (20)

Más de Neo4j

Más de Neo4j (20)

Último

Último (20)

Scale Your Mission-Critical Applications With Neo4j Fabric and Clustering Architecture

Notas del editor