GraphDB™ Clusters for Everyone

GraphDB Clusters for EveryoneOctober 8th 2015

GraphDB Clusters for Everyone #18/Oct/15

• Information management company providing text analysis, data management and state-of-the-art semantic technology

• 70 software developers in Sofia, Bulgaria• Presence in London and New York• Clients include BBC, FT, AstraZeneca, DoD, Wiley & Sons• Over 400 person-years in R&D to create a one-stop shop for:

– Content enrichment– Data management – Graph database engine

Ontotext


Ontotext and BBC

GraphDB Clusters for Everyone

Profile• Mass media broadcaster founded in 1922• 23,000 employees and over 5 billion

pounds in annual revenue.

Goals• Create a dynamic semantic publishing

platform that assembled web pages on-the-fly using a variety of data sources

• Deliver highly relevant data to web site visitors with sub-second response

Challenges• BBC journalists author and publish content

which is then statistically rendered. The costs and time to do this were high.

• Diverse content was difficult to navigate, content re-use was not flexible

• User experience needed to be improved with relevant content

"The goal is to be able to more easily and accurately aggregate content, find it and share it across many sources. From these simple relationships and building blocks you can dynamically build up incredibly rich sites and navigation on any platform." John O’Donovan Chief Technical Architect

#38/Oct/15


Clients

Technology Portfolio


• GraphDB Lite: in-memory, fast, free to use • GraphDB Standard: file-based, highly optimized

– Efficient retraction of inferred statements– Comprehensive query optimization– Includes Graph DB Workbench – console for configuration, monitoring

and exploration of datasets– Plug-in architecture, RDF Rank, Geo-spatial index

• GraphDB Enterprise: HA cluster– Resilience and high query-answering bandwidth– Includes GraphDB Connectors to FTS and NoSQL engines

GraphDB Editions


Cluster Nodes

• Master nodes– Coordinate all read and write operations– Synchronize worker nodes– Requires limited resources

• Worker nodes– Store all information– Execute all read operations– Requires capacity planning

8/Oct/15GraphDB Clusters for Everyone #7

Cluster Structure #1

Worker #2Worker #1

Master #1

Worker #3


• Share-nothing architecture• Very fast graph queries• Data failover/redundancy• Horizontal read scalability• Vertical write

scalability


Worker #2Worker #1

Master #1

Worker #3

write



scalability


Worker #2Worker #1

Master #1

Worker #3



scalability


Worker #2Worker #1

Master #1

Worker #3

I keep only a log of the

recent transactions

I keep a copy of the full repository

data 8/Oct/15GraphDB Clusters for Everyone #11


scalability



scalability Worker #2Worker #1

Master #1

Worker #3

readI choose a worker



Worker #2Worker #1

Master #1

Worker #3

read

I execute the query



scalability

Strict vs Eventual Consistency

Worker #2Worker #1

Master #1

Worker #3

read

I execute the query


• Eventual consistency• Strict consistency• Balance between strong and

eventual consistency


Worker #2Worker #1

Master #1

Worker #3

read

I execute the query


• Eventual consistency• Strict consistency• Balance between strong and



Worker #2Worker #1

Master #1

Worker #3

read

I execute the query


Execute the query on the latest worker

data• Eventual consistency• Strict consistency• Balance between strong and


All consistency models are supported

Common Cluster Operations

• Master transaction log• Worker replication• Cluster backup • Master peering• Split brain


Master transaction log

Master #1

Worker #1

Transaction Log

1write

Worker #2

Write operation8/Oct/15GraphDB Clusters for Everyone #18


Master #1

Worker #1

Worker #2Transaction Log

1write

1

Write operation

1

I will test the write

first



Master #1

Worker #1

Transaction Log

1write

1

1ok

Worker #2

Write operation

I confirm the

update



Master #1

Worker #1

Transaction Log

1write

1

1

ok

Worker #2

Write operation

The write is confirmed


Worker #2


Master #1

Worker #1

Transaction Log

1

1synchronize

1

Write operation

Propagate the write to

all other workers


Worker #2


Master #1

Worker #1

Transaction Log

1

1

1

2write

Rollback write operation8/Oct/15GraphDB Clusters for Everyone #23

Worker #2


Master #1

Worker #1

Transaction Log

1

1

1

2write

2

Rollback write operation

2


Worker #2


Master #1

Worker #1

Transaction Log

1

1

1

2write

error

2


The update is

invalid


Worker #2


Master #1

Worker #1

Transaction Log

1

1

1

2write

2

error


I mark the write as invalid


Worker #2


Master #1

Worker #1

Transaction Log

1

New worker node add operation

Worker #3

23

1234

1234


Worker #2


Master #1

Worker #1

Transaction Log

1


Worker #3

23

1234

1234

add

A new worker is

added


Worker #2


Master #1

Worker #1

Transaction Log

1


Worker #3

23

1234

1234synchronize

1

I have all updates from the

start


Worker #2


Master #1

Worker #1

Transaction Log

1


Worker #3

23

1234

1234synchronize

I have all updates from the

start


1234

4

Master transaction log cleanup

• Masters keep only limited transactions• LogMaxSize controls the maximum number of

stored transactions in the log• LogMaxDepth controls the maximum time in

minutes to keep transactions in the log

Transaction Log

12344in out


Worker node replication

Master #1

Worker #1

Transaction Log

New worker node add operation #2

Worker #3

1234

6789

56789

Worker #2

123456789



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

Worker #2

123456789

add

A new worker is

added



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

Worker #2

123456789

replication

off

I have only the recent

transactions



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

Worker #2

123456789

replication

off

123

Awrite



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

Worker #2

123456789

replication

off

123

Awrite

A

45

I have still workers to

use



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

Worker #2

123456789

replication

off

123

Awrite

A

A

45

write

6



Master #1

Worker #1

Transaction Log


1234

6789

56789

Worker #2

123456789

synchronize

A

A

Worker #3

123456789

Replication is over; go

back to normal



Master #1

Worker #1

Transaction Log


1234

6789

56789

Worker #2

123456789

synchronize

A

A

Worker #3

123456789

A

A


Worker node replication #2

Master #1

Worker #1

Transaction Log


Worker #2

1234

6789

56789


Worker node replication #2

Master #1

Worker #1

Transaction Log


Worker #2

1234

6789

56789

add

A new worker is

added



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

replication

off

I have only the recent

transactions



Master #1

Worker #1

Transaction Log


Worker #3

1234

6789

56789

replication

off

No workers available in maintenanc

e modeA

write


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

Select an up to date worker


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

off


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

copy

6

7


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

6

7

Backup

12

copy


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

6

7

Backup

123

8write

copy


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

6

7

Backup

123

8write

copy

8

45


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

12345

backup

6

7

Backup

123

8write

copy

8

8

45


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

123456

7

Backup

123

synchronize

8

8

745

67 8


Cluster Backup

Master #1

Worker #1

Transaction Log

1234

67

567

Worker #2

123456

Worker #3

123456

7

Backup

123

8

8

745

67 8

8


Master peering (1)

#53

• Seamless Hot Standby failover– In case of a single master failure– GraphDB-Enterprise should failover to the 2nd master without any

transaction loss, errors or exceptions – In a completely self managed way– Support for several geographically distributed data centers

• Persistent asynchronous transactions – GraphDB-Enterprise is always R/W– No Tx loss even in case of restart/failure– Accepted Tx can be asynchronously made eventually persistent– All accepted transactions are recoverable after a server restart/failure

GraphDB Clusters for Everyone 8/Oct/15

Master peering (2)

#54

• Client Failover Utility– Failover to the GraphDB master in case of a master failure– Asynchronous and synchronous transactions are supported. The

synchronous transactions wait until the update is executed on the server and check if it is successful.

– Persists the submitted transaction locally to avoid the case of a possible master failure

GraphDB Clusters for Everyone 8/Oct/15

Master peering

Master #1

Transaction Log

Master #2

Transaction Log

peer

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Client Failover Utility

Client Failover Utility

Master peering

Master #1

Transaction Log

Master #2

Transaction Log

1234

5678

write write

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Master peering

Master #1

Transaction Log

Master #2

Transaction Log

1234

5678

write write

1234 5678


e mode

Let’s synchronize

first

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Master peering

Master #1

Transaction Log

Master #2

Transaction Log

1234

5678

write write

1526


e mode

Our queues are sorted and ready to apply

374815263748

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


• Partition tolerance– consistency or availability

• HA cluster continues to operate after partition (AP)– Allow each master to receive updates– Backup before split brain– Smart merge by using the backup after split brain recovery

Split Brain


Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


M2 is dead or network

is down

M1 is dead or network

is down

Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Let’s wait X seconds to come back

Let’s wait wait X

seconds to come back

Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Split BrainSplit Brain

Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


34

write

56

write

• Order of the writes is important• Updates should be magically integrated

Split Brain


Master #1

Transaction Log

Master #2

Transaction Log

1234 1256

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6

Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


Split Brain;Backup a worker

Split Brain;Backup a worker

Worker Backup

12

Worker Backup

12

Split Brain

Master #1

Transaction Log

Master #2

Transaction Log

12 12

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6


34

write

56

writeWait until the backup

is doneWait until

the backup is done

Worker Backup

12

Worker Backup

12

Split Brain


Master #1

Transaction Log

Master #2

Transaction Log

1234 1256

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6

Worker Backup

Worker Backup

12 12

Split Brain


Master #1

Transaction Log

Master #2

Transaction Log

1234 1256

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6

Worker Backup

Worker Backup

12 12

M2 is back M1 is back

• Start from the pre split brain backup• Synchronize all updates and reapply them

Split Brain


Master #1

Transaction Log

Master #2

Transaction Log

1234 1256

Worker #2

Worker #1

Worker #3

Worker #5

Worker #4

Worker #6

Worker Backup

Worker Backup

12 12

• GraphDB is the leading graph and RDF database• For any further requests please contact us:

[email protected]

Thank you!


GraphDB™ Clusters for Everyone

Software

Transcript of GraphDB™ Clusters for Everyone